SSL/TLS Certificates — What Those Fields and Expiry Dates Actually Mean

At some point you have stared at the little padlock in the browser, clicked “View Certificate,” and been confronted with a wall of fields that look important but explain nothing: “Subject Alternative Names,” “OCSP,” “SHA-256 with RSA Encryption.” You close the dialog. The cert is green. That is enough.

Until it expires. At midnight on a Friday. In production.

This article walks through what is actually inside a TLS certificate — field by field — so the next time you have to troubleshoot one, you know what you are reading.

A Certificate Is Just a Signed Document

Strip away the ceremony and a TLS certificate is a text document containing some facts — who owns this domain, what public key they use, when this document expires — that has been cryptographically signed by a certificate authority (CA). The CA’s signature is what makes browsers trust it. Everything else is annotation.

The underlying format is called X.509. It was defined in 1988, revised several times, and is now specified in RFC 5280. That’s why browser cert details dialogs look like they were designed by the kind of people who consider 1988 a recent vintage.

The Key Fields, Explained

Here is an annotated breakdown of the fields you will see in a real certificate. The raw PEM data below is representative (not a live cert):

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

Common Name (CN)

The original field for specifying which domain the cert covers. You will still see it populated — CN = example.com — but browsers have mostly stopped relying on it. Since 2000, the Subject Alternative Names extension is the authoritative field for domain matching. The CN is essentially legacy at this point; if SAN exists, browsers use SAN only.

Subject Alternative Names (SAN)

This is the real list of domains the cert secures. A single cert can cover dozens of names — wildcard entries (*.example.com), exact names, even IP addresses. Multi-domain certs (sometimes called SANs certs or UCC certs) are standard practice. The CA issues against this list, and browsers match the hostname you’re visiting against it.

One thing wildcards cannot do: cover sub-subdomains. *.example.com covers app.example.com but not api.v2.example.com. A lot of people find this out the hard way.

Validity Period

Two timestamps: Not Before e Not After. The cert is invalid outside that window — before the start date, after the expiry. Both are UTC.

Maximum cert lifetimes have been shrinking steadily. In 2015 the maximum was 3 years. In 2018 it dropped to 2 years. In 2020, Apple unilaterally started rejecting certs longer than 398 days (roughly 13 months), forcing browser vendors and CAs to follow. As of 2026, the CA/Browser Forum has ratified a roadmap to reduce this to 47 days by 2027.

The argument for shorter lifetimes is sound: if a private key is compromised, a short-lived cert limits the blast radius. The operational reality is that shorter lifetimes put more pressure on your renewal automation being correct. Let’s Encrypt’s 90-day certs were controversial in 2015 for the same reason; now they are considered best practice and automated renewal is expected.

Issuer and the Chain of Trust

O Emissor field names the entity that signed the cert. For most public sites this is an intermediate CA (like Let’s Encrypt’s R11), not a root CA. Root CAs sign intermediate CA certs; intermediate CAs sign end-entity certs (the ones your server presents). This chain exists because root CA private keys are kept offline in air-gapped HSMs, and you cannot expose one to sign millions of domain certs per year.

When a browser validates your cert, it walks up the chain: your cert → intermediate → root. If the root is in the browser’s trust store, the chain validates. If any cert in the chain is missing, expired, or signed with a revoked key, validation fails.

This is why the most common TLS misconfiguration is forgetting to serve the intermediate certificate alongside your leaf cert. Your browser might cache the intermediate and seem fine, while other clients — curl, mobile apps, servers making outbound API calls — fail because they have no path to the root.

Signature Algorithm

Two things bundled into one field: the hash function used to digest the cert’s data, and the key algorithm used to sign that digest. sha256WithRSAEncryption means SHA-256 hash, RSA signature. ecdsa-with-SHA256 means SHA-256 hash, ECDSA signature.

SHA-1 signatures were deprecated by browsers in 2017 and now cause hard failures. MD5 signatures were deprecated earlier and are effectively extinct. If you are running anything that issues SHA-1 certs internally, update your CA configuration before a browser update does it for you.

ECDSA (usually P-256 or P-384) produces smaller keys and signatures than RSA for equivalent security. A 256-bit EC key is roughly equivalent to a 3072-bit RSA key. The tradeoff: RSA is more universally compatible with very old clients; ECDSA is faster and lighter. Modern deployments often configure both and let TLS negotiation pick.

Key Usage and Extended Key Usage

Key Usage is a bitmask specifying what the key is allowed to do: sign data, encrypt data, sign other certificates (CA only). Extended Key Usage refines this for specific protocols: TLS Web Server Authentication is what allows the cert to be used for HTTPS. TLS Web Client Authentication is for mTLS client certs. Code Signing is for software signing certs.

If you try to use a cert for a purpose outside its declared Key Usage, modern TLS implementations will refuse it. You cannot take a code-signing cert and use it on a web server, even if the domain matches.

Basic Constraints: CA:FALSE

This field specifies whether the cert can be used to sign other certs. CA:FALSE means it cannot — it’s a leaf (end-entity) cert. CA:TRUE means it’s a CA cert, allowed to sign other certs in the chain.

O pathLenConstraint that sometimes appears alongside this tells you how many intermediate CAs below this one are allowed. Root CAs often set this to limit chain depth.

OCSP and Revocation

The OCSP (Online Certificate Status Protocol) URL in the cert tells clients where to check if the cert has been revoked before it expired. Revocation happens when a private key is compromised or the cert was issued in error.

In practice, browser OCSP checking has a complicated history. Chrome stopped doing live OCSP checks years ago in favor of CRLSets (a pre-fetched list of revoked high-value certs). Firefox still does OCSP but defaults to soft-fail, meaning if the OCSP server is unreachable, the cert is treated as valid. The net effect: for most certificates, revocation in the wild is somewhat theoretical. This is one of the arguments for short-lived certs — at 47 days, revocation matters less because the cert expires soon anyway.

Why Certs Expire

Expiry is not bureaucratic friction. It is the mechanism that limits how long a compromised credential remains valid. The alternative — permanent credentials — is how you end up with SHA-1 certs and decade-old CA keys floating around in production, which is largely where the industry was in 2010.

The tradeoff is operational: shorter lifetimes require reliable automation. If your renewal depends on a sysadmin’s calendar reminder, you will expire in production eventually. The right answer is automated renewal via ACME (the Let’s Encrypt protocol) or your CA’s API, with monitoring that alerts several weeks before expiry rather than the night it dies.

How to Read a Certificate Without the Command Line

The standard way to inspect a cert is openssl x509 -in cert.pem -text -noout, which produces output formatted for people who find RFC 5280 light reading. If you want the same information in a format that does not require memorizing openssl flags, the Decodificador de Certificados SSL/TLS e Analisador de Certificados X.509 on iotools.cloud both take a PEM-encoded cert and return every field labeled and organized — useful when you’re debugging a chain issue at midnight and openssl’s wall of text is not helping.

Você também pode gostar