SSL Certificates - For The Rest Of Us

The internet is insecure by default. Attackers can intercept and modify traffic, so we need a way to secure communication and verify the server’s identity.

Encryption ensures data privacy, but without verification, hackers could impersonate a legitimate website, intercepting traffic while still using encryption. This is why SSL combines encryption with authentication.

The lock icon in the address bar of browsers not only means that the communication between your browser and the website is encrypted, it also confirms the identity of the website owner.

Throughout this article, the terms client and browser are used interchangeably, as are server and website. They refer to the same concepts in the context of SSL/TLS communication.

In HTTPS, before any HTTP exchange, your browser and the server perform an SSL handshake, where:

The server presents its SSL certificate.
The browser validates the certificate.
If valid, the browser proceeds with the HTTP handshake.

The SSL handshake involves multiple steps, but this post focuses on certificate validation, the key process that ensures you’re talking to the right server. Beyond certificate validation, the SSL/TLS handshake also negotiates cipher suites and exchanges session keys.

SSL Setup

Let’s say you create a website,abc.com. To make it accessible, you:

Host the website on a server.
Create a DNS A record pointing abc.com to the server’s IP.

Your website is now available at http://abc.com. To secure it with HTTPS, you need an SSL certificate from a certificate authority (CA) like Let’s Encrypt, Comodo, Digicert, GoDaddy, etc.

A certificate is a document that states that a domain name (abc.com in our example) is owned by you or your organization. A certificate authority (CA) is a trusted entity that issues these certificates.

When a browser connects to https://abc.com, it requests the certificate from the server to verify the website’s identity.

The CA verifies your domain ownership and provides a certificate that includes your public key. Now that we have an SSL certificate, let’s see how it actually works to secure communication using public-key cryptography.

Quick Refresher On Public Key Cryptography

Public key cryptography, also referred to as asymmetric cryptography is a system that uses pairs of keys: a public and a private key. Securing the keys only requires keeping the private key private, the public key can be openly distributed without compromising security.

Your public key can encrypt data, and your private key can decrypt it, and vice versa. You keep the private key secure in your server while the public key can be shared with anyone who wants to send you encrypted data (like browsers).

Receiving the data

When someone needs to send you data securely, they encrypt the data using your public key and send it to you. You then decrypt the data using your private key. Only you can read the data because only you have the private key.

SSL relies on public-key cryptography for secure authentication and key exchange to establish a shared secret key between the client and the server. This shared secret key is then used to encrypt the communication thereafter. This is because public-key cryptography is slow and computationally expensive, so it’s only used to establish a secure channel.

To prove authenticity

A more common use of private key encryption is digital signatures, which prove the authenticity of a message. Instead of encrypting an entire message, a private key is used to sign a hashed version of it, allowing recipients to verify its source using the public key.

Digital Signature

A digital signature is essentially an encrypted hash of data, primarily used to verify data integrity. If the hash extracted from the signature matches the expected hash of the original data, the integrity is intact (as shown on the left). However, if the hashes don’t match (as seen on the right), it indicates that the data has been altered.

In the case of SSL certificates, the digital signature is created by hashing all certificate fields and then encrypting the hash using the CA’s private key.

To verify the certificate, the client or browser:

Decrypts the signature using the CA’s public key.
Computes the hash of the certificate fields.
Compares the extracted hash with the computed hash. If they match, the certificate is valid.

When you request a certificate from a CA, you share your public key with them. The public key becomes part of the final certificate that you receive.

When the browser reads your certificate, it will have access to the public key and thus it can communicate with your server securely by encrypting data using that public key.

The CA verifies this information and issues a certificate, which contains your website’s public key and relevant details like allowed domain names. The CA signs the certificate using its private key and adds the signature to the certificate, allowing browsers to verify its authenticity using the CA’s public key.

The certificate you receive from the CA has the following components:

The domain name (abc.com).
Your public key.
The issuer (CA) name.
The expiration date.
A digital signature from the CA.

Certificate Chain & Hierarchy

Most certificates aren’t signed directly by a Root CA. Instead, a chain of trust is established where Root CAs have intermediate CAs that sign the certificates. A Root CA can have many intermediates and an intermediate can further have many intermediates. This forms a chain of certificates.

This structure enhances security, if an intermediate CA is compromised, only its certificates are affected, not the entire Root CA.

How Certificate Chains Work:

Leaf Certificate (Website’s Certificate) → Signed by an Intermediate CA.
Intermediate CA Certificate → Signed by a Root CA.
Root CA Certificate → Pre-installed in browsers for trust verification.

For a browser or client to validate a website’s certificate, it must have access to the entire certificate chain up to the Root CA. This is why when a website obtains an SSL certificate from a CA, it also receives a chain of certificates leading up to the last intermediate CA. The Root CA certificate is pre-installed in the client’s trust store instead of being sent by the server. This prevents attackers from forging fake root certificates and tricking users into trusting malicious websites.

Technically, the main difference between a Root CA and an intermediate CA is that the Root CA is self-signed, while the intermediate CA is signed by a Root CA or another intermediate CA. From an operational perspective though, the Root CA is more secure and is only used to sign Intermediate CAs.

A self-signed certificate is a certificate that is signed by its own private key instead of another CA’s private key. This is typically used for Root CAs.

Example of a Root CA Certificate

Subject: CN=Example Root CA
Issuer: CN=Example Root CA   # Self-signed
X509v3 Basic Constraints: critical
    CA:TRUE
X509v3 Key Usage:
    Certificate Sign, CRL Sign

Example of an Intermediate Certificate

Subject: CN=Example Intermediate CA
Issuer: CN=Example Root CA   # Signed by Root CA
X509v3 Basic Constraints: critical
    CA:TRUE
X509v3 Key Usage:
    Certificate Sign, CRL Sign

Example of a Leaf Certificate

X509v3 Basic Constraints:
    CA:FALSE
X509v3 Key Usage:
    Digital Signature, Key Encipherment

Real certificates are encoded using the .pem format with base64 encoding. Here’s what a certificate (certificate chain) looks like.

While these certificates are encoded in PEM/Base64 format, their contents can be understood as follows:

The Issuer field specifies which CA signed the certificate. It could be an intermediate CA or the Root CA.
You can also notice that the public key is part of the certificate.
The leaf certiticate for this website only allows the domains www.example.com, example.com and *.example.com. If you try to use any other domain that doesn’t match any of this, the certificate validation will fail.
The Subject field indicates the entity to which the certificate belongs (e.g., a website) or, in the case of a CA certificate, the name of the CA.

When a browser or client receives a certificate, it follows this validation process:

Verify the leaf certificate – The browser decrypts the signature on the leaf certificate using the intermediate CA’s public key. If the extracted hash matches the computed hash of the certificate’s contents, the signature is valid.
Verify the intermediate CA’s certificate – The browser decrypts the signature on the intermediate CA’s certificate using the Root CA’s public key. If the signature is valid, trust is extended to the intermediate CA.
Check the Root CA’s certificate – The Root CA’s certificate is already trusted because it is pre-installed in the browser or operating system. If all signatures are valid and the certificate chain leads to a trusted Root CA, the website’s SSL certificate is considered trusted.

Trust Store and Root CA Certificates

One crucial point is that the Root CA certificate is not sent by the server. Instead, it is already pre-installed in the client’s trust store (a list of trusted Root CAs maintained by browsers and operating systems). If a Root CA is missing from this trust store, the certificate chain will be considered untrusted, even if all signatures are technically valid.

On Linux systems, the trusted root certificates are typically managed using the ca-certificates package. This package contains a collection of Root CA certificates that are recognized as trusted by the system.

Certificate Revocation

Certificates have an expiration date (typically 1–2 years), but sometimes they need to be revoked early (e.g., if the private key is compromised).

Revoked certificates are checked via:

Certificate Revocation Lists (CRLs): A CA-published list of invalid certificates.
Online Certificate Status Protocol (OCSP): A real-time revocation check.

Corporate Certificates and Private CAs

If you work in a corporate environment, you’ve probably had to install or update your company’s certificate at some point. This is because when you access https://mycorp-private.com, its certificate is signed by a private Root CA that’s only trusted within your organization. Since this Root CA isn’t publicly recognized, you need to manually install it on your system. Once installed, all connections to https://mycorp-private.com can be securely encrypted with SSL.

This differs from public websites like https://google.com, where certificates are signed by widely trusted Root CAs that are already present in your system or browser.

Self-Signed Certificates

A self-signed certificate is one that is signed using its own private key rather than being issued by a Certificate Authority (CA). These are commonly used to create Root CAs. Generating a self-signed certificate is straightforward and can be done with the following command:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Self-signed certificates are not suitable for public websites because browsers do not trust them, as they lack validation from a recognized CA. However, they are useful for testing and development environments.

Conclusion

SSL does more than encrypt data it proves you’re talking to the right website. The certificate chain, digital signatures, and trust stores all work together to keep the internet secure. Next time you see that lock icon in your browser, you’ll know the complex system behind it. Stay curious, and stay secure!