SSL/TLS Certificates Explained
An SSL/TLS certificate proves a server's identity and enables encrypted connections. This guide covers certificate types, how chains of trust work, how certificates are issued and renewed, and how to inspect and debug certificate problems.
Quick Answer
An SSL/TLS certificate is an X.509 document containing a server's public key, the domain name(s) it covers, an expiry date, and a digital signature from a Certificate Authority (CA). When a browser connects to an HTTPS server, it uses the certificate to verify it is talking to the correct server and to establish an encrypted session. “SSL” is the colloquial term — the actual protocol is TLS.
TL;DR
- →A certificate contains a public key + domain name(s) + expiry + CA signature. It proves server identity.
- →DV certificates verify domain control only. OV and EV certificates additionally verify the organisation's legal identity.
- →Let's Encrypt issues free, trusted DV certificates valid for 90 days with automated renewal via the ACME protocol.
- →A certificate chain connects your leaf certificate to a root CA via intermediate certificates. Serve the full chain.
- →Subject Alternative Names (SANs) list the domains a certificate covers. Wildcards (*.example.com) cover one level of subdomain.
- →Common problems: expired certificates, incomplete chains, hostname mismatches, and self-signed certificates in production.
- →Use the SSL Certificate Validator to inspect a live cert; use the Decoder to inspect a PEM block before deployment.
What Is an SSL/TLS Certificate?
An SSL/TLS certificate is an X.509 document that serves two purposes during a TLS connection:
- Authentication — it proves that the server you are connecting to is who it claims to be, because the certificate was signed by a Certificate Authority (CA) your browser trusts.
- Key exchange — it carries the server's public key, which is used during the TLS handshake to establish a shared session key for encrypting the connection.
Every certificate contains:
- Subject — the entity the certificate belongs to (Common Name, Organisation, Country)
- Subject Alternative Names (SANs) — the domain name(s) the certificate covers
- Public key — RSA or ECDSA, used during key exchange
- Validity period — Not Before and Not After dates
- Issuer — the CA that signed the certificate
- Signature — the CA's digital signature proving the certificate was not tampered with
- Serial number — a unique identifier for the certificate within the issuing CA
Certificates are encoded in PEM format (Base64-encoded DER between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----). The SSL Certificate Decoder on this site reads any PEM certificate and displays all fields in a structured, human-readable layout.
Certificate Types: DV, OV, and EV
Certificate types differ in how much identity verification the CA performs before issuing the certificate. They do not differ in encryption strength.
The CA verifies only that the requester controls the domain (via an HTTP challenge or DNS TXT record). No company information is validated.
Issued in minutes. Let's Encrypt, ZeroSSL, and most commercial CAs offer DV certificates. Sufficient for most websites and APIs.
The CA verifies domain control plus the legal identity of the organisation. The organisation name appears in the certificate's Subject fields.
Takes days (manual verification). Provides assurance that a legal entity was vetted. Useful for B2B services and enterprise contexts.
The most rigorous vetting — CA verifies legal identity, physical address, operational existence, and more. EV certificates have strict CA/Browser Forum requirements.
Major browsers removed the EV green address bar in 2019 (Chrome, Safari, Firefox). EV provides stronger identity assurance but has less visual difference to end users today.
| Aspect | DV | OV | EV |
|---|---|---|---|
| Identity verified | Domain only | Domain + organisation | Domain + full legal entity |
| Issuance time | Seconds to minutes | Days | Days to weeks |
| Cost | Free (Let's Encrypt) | Paid | Paid (higher) |
| Organisation in cert | No | Yes | Yes |
| Encryption strength | Identical | Identical | Identical |
| Use case | Most sites, APIs, internal services | B2B, enterprise portals | Financial, legal, high-assurance sites |
Certificate Chains and the Trust Model
No browser directly trusts the certificate on your server. Instead, trust flows through a chain:
When a client connects, the server must send the full chain: the leaf certificate plus all intermediate certificates (but not the root, which the client already has). If any intermediate is missing, the client cannot build the trust chain and will reject the connection.
The SSL Certificate Validator on this site fetches and verifies the full chain for any live hostname, showing which intermediates are served and whether the chain is complete.
How Certificates Are Issued: CAs, Let's Encrypt, and ACME
Before a CA issues a certificate, it must verify that you control the domain. There are two standard ACME challenge types:
HTTP-01 Challenge
The CA provides a token that must be served at a known URL path on your domain (/.well-known/acme-challenge/TOKEN). The CA fetches it over HTTP to verify control. Simple to automate on any web server.
DNS-01 Challenge
The CA requires a TXT record to be added to your DNS zone (_acme-challenge.yourdomain.com). Supports wildcard certificates (HTTP-01 does not). Requires DNS API access for full automation.
Let's Encrypt is a non-profit CA operated by the Internet Security Research Group (ISRG). It is trusted by all major browsers and issues DV certificates for free via the ACME protocol. Certificates expire after 90 days and should be renewed automatically using an ACME client:
- Certbot — the official Let's Encrypt client, works with Apache and Nginx
- Caddy — web server that auto-provisions Let's Encrypt certificates with zero configuration
- acme.sh — pure shell script client, popular for custom setups
- Traefik — reverse proxy with built-in ACME support for container environments
For a broader explanation of how TLS uses certificates during the handshake, see the What Is TLS? guide.
Subject Alternative Names and Wildcard Certificates
Modern browsers validate a certificate by checking the Subject Alternative Names (SAN) extension — not the older Common Name (CN) field. A certificate must list every domain it should be valid for in the SAN extension.
A single certificate can cover multiple domains (a multi-domain or SAN certificate). Let's Encrypt allows up to 100 SANs per certificate.
Wildcard certificates use an asterisk to cover all direct subdomains of a domain:
Wildcard coverage examples
*.example.com covers: www.example.com, api.example.com, app.example.com
*.example.com does NOT cover: example.com, sub.api.example.com
To cover both example.com and *.example.com, include both as SAN entries.
Wildcard certificates require the DNS-01 ACME challenge (HTTP-01 cannot prove control of *.example.com). Use the SSL Certificate Decoder to view the SAN list for any certificate.
Common Certificate Problems
✗ Certificate expired
The most common and preventable error. Set up automated renewal with Certbot or Caddy. Monitor expiry dates (alert at 30 days) — the SSL Certificate Validator shows exact days remaining for any live hostname.
✗ Hostname mismatch
The domain in the URL does not match any SAN entry in the certificate. Common cause: serving an old certificate after adding a new subdomain, or accessing a server via IP address instead of hostname. Inspect the SAN list with the SSL Certificate Decoder.
✗ Incomplete certificate chain
The server serves only the leaf certificate without the intermediate(s). Mobile browsers and some TLS clients cannot complete the chain and reject the connection. Configure your web server to serve the full chain file (certificate + intermediates, not the root).
✗ Self-signed certificate in production
Browsers display an "invalid certificate" or "not trusted" warning. Clients like curl will refuse to connect. Replace with a CA-signed certificate — Let's Encrypt provides trusted certificates for free with automated renewal.
✗ Private key and certificate mismatch
After generating a new certificate or key, verify they are a matched pair before deploying. A mismatched key causes TLS handshake failures. The SSL Certificate Decoder can check whether a PEM certificate and private key belong to the same keypair.
✗ Certificate not yet valid
The Not Before date is in the future — the certificate was issued but the server clock is ahead of it, or the certificate was incorrectly date-stamped. Check server NTP synchronisation and the certificate's validity window.
Try the Tools
All tools run entirely in your browser. No data is uploaded. Browse all DevOps tools →
SSL Certificate Validator
Fetch and inspect the live certificate chain for any hostname — expiry, SANs, issuer, and cipher suite. Useful for confirming that a renewal has propagated.
Open SSL Validator →SSL Certificate Decoder
Paste a PEM certificate block and decode all fields: subject, issuer, SANs, validity, key type, fingerprints, and more. Check cert-key match before deploying.
Open SSL Decoder →