A digital certificate is primarily an identity-to-public-key binding.
The certificate contains a public key and identifying information. A certificate authority (CA) digitally signs the certificate so relying parties can verify that binding through a trusted certificate chain.
Fast rule: A certificate helps answer “Whose public key is this?” It does not contain the subject's private key, guarantee that the subject is honest, or prove that the endpoint can never be compromised.
1. What a certificate proves
When a certificate validates successfully, the useful conclusion is limited:
A trusted certificate chain supports the binding between the listed identity and the public key in the certificate, subject to the certificate's scope, validity, and status checks.
That is powerful, but it is not unlimited assurance.
A certificate does not automatically prove:
- the website's business practices are safe
- the server is free of malware
- the software behind the service has no vulnerabilities
- the organization will behave ethically
- the subject's private key has never been stolen
The certificate is part of an authentication and trust system. It is not a blanket security rating.
2. What a certificate contains
An X.509 public-key certificate commonly includes:
- subject identity information
- subject public key
- issuer
- serial number
- validity period
- signature algorithm
- key-usage or extended-key-usage constraints
- subject alternative names
- the issuer's digital signature over the certificate data
The subject's private key is not in the certificate.
Subject alternative name
Modern certificates commonly use the Subject Alternative Name (SAN) extension to list the DNS names or other identities for which the certificate is valid.
If the requested hostname is not covered by the certificate, the identity check should fail even if the certificate was signed by a trusted CA.
Key usage matters
A certificate can restrict how its public key is intended to be used. A key meant for signing is not automatically appropriate for every encryption or authentication purpose.
Security+ questions may test whether a certificate's purpose matches the operation being attempted.
3. Chain of trust
Certificates are normally validated through a chain:
- Leaf/end-entity certificate belongs to the server, user, device, or code signer.
- One or more intermediate CAs may issue certificates beneath the root.
- A root CA is trusted through the operating system, browser, enterprise trust store, or other configured trust mechanism.
The root certificate is normally self-signed. Its trust comes from being deliberately placed in the trust store, not from the fact that it signed itself.
Why intermediates exist
A root CA can remain heavily protected while intermediate CAs perform day-to-day issuance. If an intermediate is compromised or must be replaced, the organization can respond without necessarily replacing the root trust anchor.
Missing intermediate
A leaf certificate can be perfectly valid but still fail validation if the relying party cannot build the necessary chain to a trusted root.
That is a chain-building problem, not automatically proof that the leaf certificate's public key is wrong.
4. Validation checks
A relying party should evaluate several things, not just the issuer name.
Typical checks include:
- Can a chain be built to a trusted root?
- Are the signatures in the chain valid?
- Is the current time within the certificate's validity period?
- Does the certificate cover the expected hostname or identity?
- Is the certificate permitted for the intended use?
- Has the certificate been revoked, when revocation information is available and required?
A failure in any important check can break trust in the connection.
Expired certificate
Expiration means the certificate is outside its allowed validity period. It does not necessarily mean the key was compromised.
Name mismatch
A name mismatch means the identity requested by the client is not covered by the certificate. The certificate might be otherwise valid for a different hostname.
Untrusted issuer
A certificate may be correctly formed and correctly signed but still untrusted because the client does not trust the issuing chain.
5. Revocation
Sometimes a certificate should no longer be trusted before its scheduled expiration.
Reasons can include:
- private-key compromise
- CA compromise
- incorrect issuance
- change in authorization or ownership
- replacement of a certificate for operational reasons
Two common mechanisms are:
Certificate Revocation List (CRL)
A CRL is a signed list published by a CA containing revoked certificate identifiers.
Clients obtain the list and check whether a certificate appears on it.
Online Certificate Status Protocol (OCSP)
OCSP allows a client or intermediary to request certificate-status information from an OCSP responder.
A response can indicate status such as good, revoked, or unknown.
OCSP stapling
With stapling, the server obtains a signed OCSP response and sends it to the client during the TLS handshake. This can reduce direct client queries to the CA's responder.
6. Certificate roles
The same certificate framework can support different purposes.
| Certificate role | Typical purpose |
|---|---|
| TLS server certificate | Authenticate a server identity and support secure session establishment |
| Client certificate | Authenticate a user or device to a service |
| Code-signing certificate | Bind a signing key to a software publisher |
| Email certificate | Support signing and/or encryption for email, depending on key usage |
| CA certificate | Allow a CA key to validate certificates beneath it |
Read the scenario carefully. A certificate that is valid for one purpose is not necessarily valid for every purpose.
7. Common exam traps
Trap: “HTTPS means the website is safe”
HTTPS can provide encrypted transport and server authentication when certificate validation succeeds. It does not certify the site's content or business practices.
Trap: “The certificate contains the private key”
It contains the public key. The private key is stored separately and protected by its owner.
Trap: “Self-signed means encrypted traffic is impossible”
A self-signed certificate can still participate in encryption. The trust problem is whether the client has an independent reason to trust that certificate.
Trap: confusing expiration with revocation
Expiration is scheduled. Revocation invalidates a certificate before its normal expiration.
Trap: ignoring the hostname
A trusted CA signature alone does not make a certificate valid for every DNS name.
8. Rapid review grid
| Clue | Best interpretation |
|---|---|
| “Binds identity to a public key” | Digital certificate |
| “Who signed the certificate?” | Issuing CA |
| “Where is the subject's private key?” | Not in the certificate |
| “Trusted anchor” | Root CA in a trust store |
| “Daily issuance beneath protected root” | Intermediate CA |
| “Certificate passed its end date” | Expired |
| “Certificate should stop being trusted early” | Revocation |
| “Published signed list of revoked certificates” | CRL |
| “Online status query” | OCSP |
| “Server sends recent OCSP proof to client” | OCSP stapling |
| “Certificate valid, wrong site name” | Identity/name mismatch |