How SSL Certificates Work: A Practical Guide

SSL certificates are the foundation of web security, yet most developers treat them as a black box. Understanding how certificates work — from the cryptographic principles to the trust chain — helps you troubleshoot errors, choose the right certificate type, and configure your server correctly.

Public Key Cryptography Basics

SSL certificates are built on asymmetric cryptography. You have a key pair: a public key (shared freely) and a private key (kept secret on the server). Data encrypted with the public key can only be decrypted with the private key, and vice versa. During the TLS handshake, the server’s public key helps establish a secure channel for exchanging symmetric session keys.

What a Certificate Contains

An X.509 certificate contains the domain name (or names) it’s valid for, the public key, the issuing Certificate Authority, validity dates, and a digital signature from the CA. The CA’s signature is what browsers use to verify the certificate is legitimate and hasn’t been forged.

The Certificate Trust Chain

Browsers don’t trust certificates directly — they trust Certificate Authorities. The trust chain works like this: your server certificate is signed by an intermediate CA, which is signed by a root CA. Browsers ship with a pre-installed list of trusted root CAs. As long as the chain from your certificate to a trusted root is valid, the browser accepts it.

Certificate Validation Levels

DV (Domain Validated) certificates verify that you control the domain. They’re fast to issue (minutes) and free via Let’s Encrypt. OV (Organization Validated) certificates verify the domain and the organization’s legal identity. EV (Extended Validation) certificates involve the most thorough vetting and previously showed a green address bar, though modern browsers have de-emphasized the visual distinction. For most sites, DV is sufficient.

Wildcard and SAN Certificates

A wildcard certificate (*.example.com) covers all subdomains at one level. A SAN (Subject Alternative Name) certificate covers multiple specific domains in a single certificate. Let’s Encrypt supports both, and SAN certificates are the modern preferred approach for multi-domain coverage.

Common Certificate Errors

• Certificate expired — Renew before expiry; automate with Certbot
• Hostname mismatch — The domain in the cert doesn’t match the URL
• Incomplete chain — Intermediate certificate missing from server config
• Self-signed — Not trusted by browsers; only for development/internal use

Decode a certificate? Use the Base64 Decoder on devutilitypro.com to inspect PEM-encoded certificate data and verify your cert contents.