How SSL/TLS Certificates Actually Work: Public Key Cryptography Explained
Every HTTPS connection you make uses SSL/TLS under the hood — but most people, including many developers, treat it as a black box. Understanding how certificates actually work helps you make better decisions about certificate types, key sizes, and monitoring. This article explains public key cryptography and the TLS handshake in plain language.
The Problem SSL/TLS Solves
When you connect to a website, your browser and the server need to communicate privately — but the internet is a public network. Any router between you and the server could theoretically read or modify your traffic. Two problems need solving:
Problem 1: Eavesdropping
Anyone on the network path can read your passwords, session tokens, and data if the connection is unencrypted.
Problem 2: Impersonation
How do you know you're talking to google.com and not an attacker pretending to be Google?
SSL/TLS solves both: encryption prevents eavesdropping, and certificates prove identity.
Symmetric vs Asymmetric Encryption
Symmetric encryption uses the same key to encrypt and decrypt. It's fast, but creates a problem: how do you securely share that key with the server across an untrusted network?
Asymmetric (public key) encryption uses a key pair: a public key and a private key. Data encrypted with the public key can only be decrypted by the private key, and vice versa. The public key is safe to share with anyone — it is literally public.
TLS uses asymmetric cryptography to securely establish a shared symmetric key. Once that's done, all subsequent communication uses the fast symmetric key. This is why TLS performance impact is minimal after the initial handshake.
The TLS 1.3 Handshake, Step by Step
Client Hello
Your browser sends a ClientHello message listing: TLS versions it supports, cipher suites it supports, a random number (client_random), and key share data for the chosen key exchange algorithm (usually X25519).
Server Hello
The server responds with: its chosen cipher suite and TLS version, its own random number (server_random), and its key share. At this point, both sides can compute the shared session key — independently, without transmitting it.
Server Certificate
The server sends its certificate — which contains its public key, the domain name it's issued for, expiry date, and the CA's digital signature. The browser verifies the signature using the CA's public key from its trust store.
Certificate Verification
The browser walks the certificate chain: your cert → intermediate CA → root CA. It checks: is the domain name correct? Is the certificate expired? Is the CA trusted? Is the certificate revoked (via OCSP)?
Handshake Complete
Both sides have computed the same symmetric session key (via ECDHE key agreement). They exchange a Finished message to confirm the handshake was not tampered with. Encrypted data transfer begins.
What's Inside an SSL Certificate?
You can inspect any certificate with OpenSSL or our SSL checker tool. Key fields include:
# View a certificate in detail openssl s_client -connect yourdomain.com:443 </dev/null 2>/dev/null | \ openssl x509 -noout -text # Key fields in the output: # Subject: CN=yourdomain.com (who the cert is issued to) # Issuer: CN=R11, O=Let's Encrypt (who signed the cert) # Validity: # Not Before: Jan 1 00:00:00 2026 GMT # Not After : Apr 1 00:00:00 2026 GMT # Subject Alternative Name: DNS:yourdomain.com, DNS:www.yourdomain.com # Public Key Algorithm: id-ecPublicKey (curve P-256)
Key Sizes and Algorithm Choices
| Algorithm | Key Size | Security Level | Performance |
|---|---|---|---|
| RSA | 2048 / 4096 bit | Good / Strong | Slower handshake |
| ECDSA P-256 | 256 bit | Excellent | Fast — recommended |
| ECDSA P-384 | 384 bit | Very Strong | Slightly slower than P-256 |
| RSA 1024 | 1024 bit | Broken — avoid | Rejected by browsers |
Let's Encrypt now defaults to ECDSA P-256 for new certificates. If your server still generates RSA keys, update your Certbot/ACME configuration to request ECDSA for better performance.
Certificate Revocation: OCSP and CRL
If a private key is compromised, the CA can revoke the certificate before it expires. Browsers check revocation via two mechanisms:
OCSP (Online Certificate Status Protocol)
Browser queries the CA in real-time. Adds latency. OCSP Stapling (server caches the response) solves this — enable it in your server config.
CRL (Certificate Revocation List)
A published list of revoked certificate serial numbers. Can be large and slow to download. Less commonly used for real-time checks.
Inspect your certificate's full technical details
Our SSL checker shows your certificate's algorithm, key size, SANs, chain details, and OCSP status — no command-line required.
Inspect your certificate →