You use digital certificates every day and everywhere. We are going to talk about the trust behind the padlock icon that you see near the website link when you visit a website (a TRUSTED one).
How do two total strangers on the internet establish trust? How does your browser actually know that the server on the other end is who it claims to be? In this case, encryption is not enough because it solves only one problem: confidentiality! It does not provide authentication!
Why Don't We Send Naked Public Keys?
Let's imagine a world without digital certificates. You want to receive a secure message from a friend, so you send them your raw Public Key over the internet. In this case, a classic Man-in-the-Middle attack may happen:
- You send your raw public key to your friend.
- The attacker intercepts it, discards it, and sends their own public key to your friend.
- Your friend encrypts their message with the attacker's key, thinking it's yours.
- The attacker decrypts it, reads it, re-encrypts it with your real public key, and forwards it.
- Neither you nor your friend notices anything is wrong.
So we need to prove our identity when we send the public key. This proof is a Digital Certificate!
What Is a Digital Certificate? (X.509 format)
A digital certificate is proof of Identity. It contains :
- Your identity (name, domain name, organization)
- Your public key
- A digital signature from a trusted authority that vouches for both
The standard format that is used over the internet is X.509. When you visit https://google.com, your browser looks at the certificate. If it is valid, then the encrypted conversation begins.
X.509 Structure:
- Version
- Serial Number
- Signature Algorithm Identifier
- Issuer Name
- Validity Period
- Subject Name
- Public key
- Issuer Unique ID
- Subject Unique ID
- Extensions
Note: The 'Issuer Unique ID' and 'Subject Unique ID' fields listed above belong to older X.509 versions. In today's modern internet (X.509 v3), these fields are considered deprecated. Instead, modern certificates use the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) values located under the Extensions section.
Certificate Authorities: The Notaries of the Internet:
We trust the Digital Certificate only when we see the digital signature of a trusted Certificate Authority (CA).
Your browser and OS have a list of default Root CAs (like DigiCert, GlobalSign, Let's Encrypt, and Sectigo) called Certificate Store.
If a website's certificate is signed by one of the CAs (Directly or through a chain) in the Certificate store of the OS or browser, your browser automatically trusts it, and you enter the website.
There are two primary types of certificate stores on Windows:
- Local Machine Certificate Store: This store contains certificates that are accessible to all users on the computer.
- Current User Certificate Store: This store contains certificates that are accessible only to the current user.
A CA is an organization that: 1. Verifies that you are who you claim to be. 2. Signs your certificate with their private key. 3. Takes responsibility for that claim.
A CA signature just tells us that this key belongs to the owner of this website. It doesn't mean that the owner is trustworthy or honest!
The Chain of Trust (What is Root CA?)
In practice, Root CAs don't directly sign website certificates. They sign Intermediate CAs, which sign website certificates. This creates a chain of trust:
Root CA (DigiCert) signs the Intermediate CA (DigiCert TLS RSA SHA256 2020 CA1). Intermediate CA signs the Website Certificate (google.com).
Why this layered structure? Root CA private keys are extremely sensitive. Keeping them offline in hardware security modules (HSMs) and rarely using them reduces the attack surface dramatically. Intermediate CAs handle the day-to-day signing.
Your browser verifies the entire chain, all the way back to a Root CA it recognizes. If any link is broken or untrusted, the connection fails.
Private Certifications:
Until now, we have been talking about public certifications that make you trustworthy in terms of identity. But sometimes you don't need to be trustworthy on the public internet.
If you want to establish this trust within a private network, you need a Private Certification. Private certifications are used inside organizations. A hospital, a bank, or a government agency might run its own CA (using tools like Windows Certificate Services or OpenCA). In this case, certificates cost nothing and can be issued automatically, but they are meaningless to anyone outside the organization whose devices don't have the internal CA in their trust store.
SANs and Wildcard Certificates:
A company may have so many subdomains like vpn.company.com, mail.company.com, etc. Purchasing and managing certificates for all of these subdomains separately is an absolute pain!
Subject Alternative Name (SAN):
The Subject Alternative Name (SAN) is an extension to the X.509 specification that allows a single SSL certificate to protect multiple hostnames. It's like a list!
For example:
Subject: company.com
Your list:
- ✅ www.company.com
- ✅ vpn.company.com
- ✅ mail.company.com
- ✅ cmp.net
- ✅ mail.cmp.com
It's like a list where we can add anything we want to it and use a single certificate for all of them!
Google uses SAN to cover android.com, youtube.com, goo.gl, google.com, etc., with one single certificate.
Wildcard Certificate:
Wildcard certificates secure only one domain and its subdomains. The "*" (asterisk) in DNS is a wildcard. It matches any single label. A certificate issued for *.company.com covers:
- ✅ www.company.com
- ✅ vpn.company.com
- ✅ mail.company.com
- ❌ company.com (the bare domain itself is not covered, but many CAs automatically include the bare domain company.com itself in the SAN when you buy a wildcard certificate)
- ❌ sub.mail.company.com (Wildcards just cover 1 subdomain depth)
The wildcard must be on the left because certificates are for domains not paths.
Certificate Revocation:
We know that certificates have an expiration date, but what if we want to invalidate them before expiration? for example, if the private key is stolen, or if the organization no longer exists.
Certificate Revocation List (CRL):
CAs maintain CRLs. These lists always change and get updated. They contain a list of all revoked certificates of that CA. Your browser can download this file and check whether the certificate is on the list (it is revoked) or not.
See also: Heartbleed vulnerability (CVE-2014-0160), a flaw in OpenSSL that allowed attackers to read server memory, potentially exposing private keys. This resesulted in a massive, simultaneous revocation event across a significant portion of the internet . Millions of certificates added to CRLs within days.
Online Certificate Status Protocol (OCSP):
Instead of downloading the entire CRL, the browser sends a real-time query to an OCSP Responder to ask whether this certificate is valid. But this may not scale well, as the OCSP Responder may need to respond to millions of users.
Some servers use OCSP stapling to pre-fetch this response and include it with the SSL/TLS handshake, eliminating the extra round trip. In this case, the validation information is stamped with the signature of the CA.