What a certificate says

A key needs a name

When Alex types portal.harborclinic.example into a browser, the browser has never met the clinic's server. The server can prove that it holds a private key by answering a challenge, as Secrets and key pairs described. But any server can hold some private key. What the browser needs to know is whether this key belongs to the name Alex asked for.

A certificate answers that question with a signed statement. It says, in effect: this public key belongs to this name, for these purposes, during this period. The statement is signed by an issuer, a certificate authority (CA). If the browser trusts the CA and the signature is valid, it can connect the server's key to the clinic's hostname without having met the clinic before.

Certificates, the authorities that issue them, and the rules and systems that manage them make up public key infrastructure (PKI). This lesson reads a single certificate. The next ones follow the chain of issuers behind it, the checks a client performs, and the certificate's life from request to revocation.

Inside a certificate

Certificates on the web use a standard format called X.509. They are stored in a compact binary encoding, but tools can decode them into readable text. Here is a simplified, fictional decoding of the clinic portal's certificate:

Certificate:
    Version: 3
    Serial Number: 04:9f:2c:81:5e:d3:7a:10:b6
    Signature Algorithm: ecdsa-with-SHA256
    Issuer: O=Example Trust Services, CN=Example TLS Issuing CA 2
    Validity
        Not Before: Sep  1 00:00:00 2026 GMT
        Not After : Nov 29 23:59:59 2026 GMT
    Subject: CN=portal.harborclinic.example
    Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
        Public-Key: (256 bit), curve P-256
    X509v3 extensions:
        Subject Alternative Name:
            DNS:portal.harborclinic.example, DNS:login.harborclinic.example
        Key Usage: critical
            Digital Signature
        Extended Key Usage:
            TLS Web Server Authentication
        Basic Constraints: critical
            CA:FALSE
        Authority Information Access:
            CA Issuers - URI:http://ca.example/issuing-ca-2.crt
    Signature Value:
        30:45:02:21:00:c7:1e:...

Reading from the top, the serial number identifies this certificate among everything its CA has issued, which matters when the CA later needs to say that a particular certificate is no longer trusted. The issuer names the CA that signed it. The validity period gives the first and last moments at which it should be accepted.

The subject names who the certificate is about, and the subject public key is the clinic's public key. This is the binding the whole certificate exists to make. The matching private key never appears in the certificate; it stays on the clinic's server or in its key hardware.

At the bottom, the signature is the CA's signature over everything above it. Changing any field, such as adding a hostname or extending the expiry, would make that signature fail.

Names and permitted uses

Browsers match the hostname against the subject alternative name (SAN) extension, not the subject's common name (CN), which is kept mostly for display and older software. This certificate lists two names, so the clinic can use it for both the portal and its sign-in service. It does not cover www.harborclinic.example, even though that shares a parent domain.

A wildcard name such as *.harborclinic.example would match any single label in that position, so it would cover portal.harborclinic.example but not a.portal.harborclinic.example or harborclinic.example itself. Wildcards reduce the number of certificates to manage, at the cost of spreading one private key across every service that uses them.

The key usage and extended key usage extensions limit what the key may be used for. This one allows digital signatures for authenticating a TLS server. The same format serves many other purposes: certificates can identify TLS clients, sign software, protect email, or identify a person on a smart card. The permitted uses keep a certificate issued for one purpose from being accepted for another.

The basic constraints extension says CA:FALSE. The clinic may use this certificate to identify its server, but it may not act as a certificate authority and sign certificates for other names. The CA certificates in the next lesson carry CA:TRUE.

What a certificate does not say

Most certificates on the web are domain validated. Before issuing one, the CA checked that the requester controlled the domain name, and nothing more. The certificate says that its key belongs to whoever controlled portal.harborclinic.example when it was issued. It does not say that the clinic is licensed, honest, or the clinic Alex meant to visit. A phishing site at a look-alike address can obtain a perfectly valid certificate for its own name. Some certificate types also record a validated organization name, but a browser's padlock does not tell people which kind they are looking at.

A certificate is also public. The server sends it to every visitor, and anyone can copy it. Possessing the certificate proves nothing; the server must also prove it holds the matching private key during the connection. That is why an attacker who copies the clinic's certificate still cannot impersonate the portal, while an attacker who steals the private key can.

Finally, the certificate is only as trustworthy as the CA that signed it. Certificate authorities and chains follows that trust from the clinic's certificate back to its source.