SSL/TLS Certificates: Complete Guide for Web Administrators

HTTPS is no longer optional. Google Chrome marks all HTTP sites as "Not Secure" in the address bar. Google's search algorithm gives a ranking boost to HTTPS sites. Payment Card Industry (PCI DSS) standards mandate TLS for any site handling cardholder data. And fundamentally, without TLS, every piece of data your visitors send — passwords, form submissions, personal information — travels the internet in plaintext, readable by anyone on the same network.

SSL (Secure Sockets Layer) is the predecessor protocol; it has been deprecated since 2015 and is disabled on all modern systems. The current standard is TLS (Transport Layer Security). Despite this, the industry still colloquially calls certificates "SSL certificates." When someone says "SSL," they mean TLS.

An SSL/TLS certificate does two things: it authenticates your server (proves you are who you claim to be) and it enables encryption of all data in transit. Without the certificate, the encryption cannot be established because there is no trusted way to exchange the session keys.

Every HTTPS connection begins with a TLS handshake — a brief negotiation that establishes trust and generates the session encryption keys. Understanding this process helps you diagnose connection failures and configure your server correctly.

TLS 1.3 Handshake (Simplified)

1. Client Hello: The browser sends the TLS version it supports, a list of cipher suites, and a random nonce.
2. Server Hello: The server selects a cipher suite, sends its certificate, and provides its key share for key derivation.
3. Certificate Verification: The browser verifies the certificate is signed by a trusted CA, the domain matches, and it hasn't expired or been revoked.
4. Key Derivation: Both sides independently compute the same session key using their exchanged key shares (ECDHE). No key is ever transmitted.
5. Finished: Both sides send a Finished message encrypted with the new session key, confirming the handshake succeeded. Encrypted data transfer begins.

TLS 1.3 vs TLS 1.2: Why the Version Matters

Cipher suites define the algorithms used for key exchange, authentication, bulk encryption, and message authentication. Modern servers should only support ECDHE key exchange (for forward secrecy), AES-GCM or ChaCha20-Poly1305 for encryption, and SHA-256 or SHA-384 for HMAC. Disable cipher suites using RC4, DES, 3DES, MD5, or RSA key exchange (non-ephemeral).

Not all SSL certificates are created equal. They differ in how rigorously the Certificate Authority verifies the applicant's identity, how quickly they're issued, and what information they contain.

Wildcard Certificates

A wildcard certificate (e.g., *.yourdomain.com) secures all first-level subdomains under a domain with a single certificate. It covers mail.yourdomain.com, app.yourdomain.com, api.yourdomain.com, etc., but does not cover yourdomain.com itself (you need a SAN entry for the apex) or second-level subdomains like dev.api.yourdomain.com. Wildcards are issued at DV or OV level.

Multi-Domain Certificates (SAN/UCC)

Subject Alternative Names (SANs) allow a single certificate to cover multiple distinct domains: yourdomain.com, www.yourdomain.com, yourdomain.net, and partner-site.com all in one certificate. This is operationally simpler than managing multiple certificates, but be aware: if the private key for a SAN certificate is compromised, all domains on that certificate are affected.

A Certificate Authority (CA) is an organization that has been granted trust by browser and OS vendors to issue certificates. The trust model is hierarchical: browsers ship with a bundle of Root CA certificates pre-installed. Root CAs sign intermediate CA certificates, and intermediates sign your server's end-entity certificate.

Root CA private keys are kept offline in HSMs in physically secured facilities. All day-to-day signing is done by intermediate CAs. When you install a certificate, you must also install the intermediate CA certificates that bridge the trust from your certificate back to the root. This is called the certificate chain. A broken chain (missing intermediate) is one of the most common causes of SSL errors on mobile devices and curl.

Let's Encrypt: Free DV Certificates

Let's Encrypt, operated by the Internet Security Research Group (ISRG), has issued over 4 billion certificates since its 2015 launch. It uses the ACME protocol to automate domain validation and certificate issuance. Certificates are valid for 90 days — short enough to limit exposure from compromised keys, but Certbot and other ACME clients handle automatic renewal transparently. There is no cost. Let's Encrypt is trusted by all major browsers.

Commercial CAs

DigiCert, Sectigo (formerly Comodo), GlobalSign, and Entrust are the major commercial CAs. Use them when you need OV or EV validation, dedicated support, warranty coverage, or specialized certificate types like code-signing or S/MIME email certificates. Prices range from ~$50/year for basic OV to several hundred dollars for EV multi-domain certificates.

Using Certbot (Let's Encrypt) — Recommended

Certbot is the official ACME client for Let's Encrypt. It can obtain and install certificates automatically:

Manual Apache Configuration

If you're installing a commercial certificate manually:

Manual Nginx Configuration

Chain order matters: In Nginx, ssl_certificate should point to a file that contains your certificate first, followed by the intermediates. In Apache, use SSLCertificateChainFile separately or concatenate the chain into SSLCertificateFile. Incorrect chain order causes SSL errors specifically on clients that don't cache intermediate certificates (often mobile devices).

An expired certificate causes your site to become completely inaccessible — browsers show a full-screen warning that most users will not bypass. Certificate expiry is still one of the most common causes of unplanned outages, even at large organizations.

Automating Renewal with Certbot and Systemd

Certbot on modern Debian/Ubuntu systems automatically installs a systemd timer:

Certbot renews certificates when they are within 30 days of expiry. Since Let's Encrypt certificates are valid for 90 days, renewal typically happens around day 60, giving you a comfortable buffer.

Monitoring Strategies

• External monitoring: Use a monitoring service to check your certificate from outside your network daily. Get alerts at 30 days, 14 days, and 7 days before expiry.
• CA email notifications: Most commercial CAs send expiry reminder emails. Make sure the certificate contact email address is a monitored inbox, not a personal email that may change.
• Inventory management: Maintain a spreadsheet or CMDB entry for every certificate in your organization, including domain, CA, expiry date, renewal owner, and server location. Certificate proliferation — especially after cloud migrations — makes ad-hoc tracking unreliable.
• Certificate Transparency logs: All publicly-trusted certificates are logged to CT logs. Monitor these logs for your domains using crt.sh or a dedicated CT monitoring tool to detect unauthorized certificates issued for your domains.

Check your certificate's current validity and expiration date instantly with the EP Cybertools SSL Checker.

Today's TLS relies on RSA and Elliptic Curve Diffie-Hellman (ECDH) for key exchange. Both are vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. While a cryptographically relevant quantum computer (CRQC) does not yet exist, the "harvest now, decrypt later" threat is real: adversaries are collecting encrypted traffic today with the intent to decrypt it when quantum computers become available.

Google Chrome, Cloudflare, and AWS have already deployed hybrid key exchange in TLS — combining classical ECDH with ML-KEM (formerly Kyber), one of NIST's newly standardized post-quantum algorithms. This hybrid approach ensures security against both classical and quantum attacks without sacrificing compatibility.

As a web administrator, monitor your CDN and server software vendors for TLS updates that incorporate post-quantum key exchange. Check your current TLS configuration against post-quantum readiness with the EP Cybertools SSL Checker and explore our dedicated Post-Quantum Cryptography guide for a deeper dive.