An SSL certificate is more than a padlock indicator — it is the cornerstone of a sophisticated cryptographic system called Public Key Infrastructure (PKI). Understanding how certificates work helps you make better decisions about HTTPS configuration, troubleshoot connection errors, and appreciate why modern web security is as robust as it is.
Public Key Infrastructure (PKI)
PKI is the framework of policies, processes, hardware, software, and standards that manage digital certificates and public-private key pairs. In the context of the web, PKI enables a browser in any country to trust a certificate issued by a CA it has never directly interacted with — because the browser trusts a root certificate embedded in its operating system, and that root underpins a chain of trust down to the certificate on your server.
PKI depends on asymmetric cryptography — a system that uses mathematically linked key pairs where what one key encrypts, only the other can decrypt.
Asymmetric vs. Symmetric Encryption
SSL/TLS uses both encryption types, each for a different purpose:
- Asymmetric encryption uses a public key and a private key. The public key is embedded in the SSL certificate and shared openly. The private key is kept secret on the server. Data encrypted with the public key can only be decrypted with the private key. This is computationally expensive, so it is used only during the handshake to securely exchange a shared secret.
- Symmetric encryption uses a single shared secret key for both encrypting and decrypting data. It is far faster than asymmetric encryption. Once the TLS handshake is complete and both sides have agreed on a shared session key, all subsequent application data is encrypted symmetrically.
The TLS Handshake Overview
Before any application data is exchanged, the browser and server perform a TLS handshake — a negotiation protocol that establishes trust, agrees on cipher settings, and derives session keys. The handshake is where the SSL certificate is presented and verified.
In TLS 1.2, the handshake requires two round trips before the first byte of application data can flow. In TLS 1.3, it was redesigned to require only one round trip — with an optional zero-round-trip (0-RTT) mode for repeat connections.
# TLS 1.2 Handshake (simplified)
Client → Server: ClientHello (TLS version, cipher suites, random nonce)
Server → Client: ServerHello (chosen cipher, random nonce)
+ Certificate (server's SSL certificate)
+ ServerKeyExchange (if needed for key exchange)
+ ServerHelloDone
Client → Server: ClientKeyExchange (encrypted pre-master secret)
+ ChangeCipherSpec
+ Finished (encrypted with session key)
Server → Client: ChangeCipherSpec
+ Finished (encrypted with session key)
--- Encrypted application data flows ---Certificate Verification During the Handshake
When the server sends its certificate, the browser performs several checks before proceeding:
- Chain validation — the browser verifies that the certificate was signed by a trusted CA, tracing the chain from the leaf certificate up through intermediate CAs to a trusted root.
- Expiry check — the browser confirms the current date is between the certificate's Not Before and Not After dates.
- Name check — the browser verifies that the domain in the address bar matches the Common Name or a Subject Alternative Name in the certificate.
- Revocation check — the browser checks whether the certificate has been revoked using OCSP or a cached CRL (Certificate Revocation List).
If any check fails, the browser aborts the handshake and displays an error to the user. You can verify these details for any domain using the ShowDNS SSL Checker.
The Certificate Chain of Trust
Browsers do not directly trust every SSL certificate in the world — that would be unmanageable. Instead, they trust a small set of root certificates pre-installed in the operating system or browser. The chain of trust works as follows:
- A Root CA (e.g. DigiCert Global Root G2) has its public key embedded in browsers and operating systems.
- The Root CA signs an Intermediate CA certificate, delegating the authority to issue leaf certificates.
- The Intermediate CA signs the leaf certificate installed on your web server.
Using intermediate CAs is a security practice: the root certificate is kept offline in a highly secure facility. If an intermediate CA is compromised, it can be revoked without invalidating the root. The server must send the full chain (leaf + all intermediates) so the browser can build and verify it.
# View the full certificate chain
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null
# Verify the chain is complete and valid
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted intermediate.pem leaf.pem
# Check which root CA anchors the chain
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuerOCSP Stapling
OCSP (Online Certificate Status Protocol) is the mechanism browsers use to check whether a certificate has been revoked. In basic OCSP, the browser contacts the CA's OCSP responder for every new connection — adding latency and a privacy concern (the CA learns which sites you visit).
OCSP Stapling solves this by having the server periodically fetch a signed OCSP response from the CA and "staple" it to the TLS handshake. The browser receives the revocation status directly from the server without making an additional request to the CA. This improves performance, enhances privacy, and is recommended practice for all production servers.
Certificate Transparency Logs
Certificate Transparency (CT) is a public auditing framework introduced to detect misissued certificates. CAs are required to log every certificate they issue to public, append-only CT logs. Browsers enforce this — a certificate not logged in CT logs will be rejected.
CT logs allow domain owners, security researchers, and automated monitoring tools to detect unexpected certificates issued for their domains. If an attacker obtained a certificate for your domain from a rogue CA, CT logs would make it publicly visible. You can monitor CT logs for your domain using services like crt.sh.
Forward Secrecy
Forward secrecy (also called Perfect Forward Secrecy, PFS) ensures that session keys cannot be recovered even if the server's private key is later compromised. It is achieved through ephemeral key exchange algorithms such as ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) where a new, temporary key pair is generated for each session and discarded afterward.
TLS 1.3 mandates forward secrecy for all connections, removing cipher suites that do not provide it. In TLS 1.2, forward secrecy requires explicitly selecting ECDHE or DHE cipher suites in the server configuration.
Frequently Asked Questions
What is the difference between a public key and a private key?
The public key is embedded in the SSL certificate and shared openly with anyone who connects to your server. The private key is a secret file stored securely on your server and never shared. They are mathematically linked: data encrypted with the public key can only be decrypted by the corresponding private key. Compromise of the private key means an attacker could impersonate your server, which is why private keys must be protected carefully.
How does the browser know which CAs to trust?
Operating systems and browsers ship with a pre-installed root store — a collection of trusted root CA certificates. Microsoft, Apple, Mozilla, and Google each maintain their own root programmes with strict requirements for inclusion. A CA must pass regular audits to remain in these stores. When a certificate chains up to a root in the browser's store, it is automatically trusted.
What happens if a certificate is revoked?
When a certificate is revoked — typically because the private key was compromised — the CA publishes its serial number in a Certificate Revocation List (CRL) and marks it as revoked in its OCSP responder. Browsers that check revocation status will refuse to accept the revoked certificate and display an error. Revocation is why monitoring your certificate and rekeying it if your private key is ever exposed is critical.
Does HTTPS slow down websites?
The TLS handshake adds a small amount of latency — typically 10–50 ms for TLS 1.2, and less for TLS 1.3 with its one-round-trip handshake. Once the session is established, the symmetric encryption used for data transfer is extremely fast and has negligible performance impact on modern hardware. The performance benefits of HTTP/2 (which requires HTTPS in practice) often more than compensate for the handshake overhead.
What is a session ticket and how does it speed up TLS?
A session ticket is an encrypted token the server issues at the end of a TLS session. On a subsequent connection, the client presents the ticket, and the server can resume the session without a full handshake — saving a round trip. TLS 1.3 introduces a similar mechanism called pre-shared keys (PSK) for session resumption and optional 0-RTT data.