SSL/TLS Certificates: Everything Developers Need to Know

What TLS Certificates Do

A TLS certificate (often called an “SSL certificate” for historical reasons) serves two purposes: it proves the identity of a server to the client, and it enables encrypted communication between them. Without a valid certificate, a browser has no way to verify that it is talking to the real example.com and not an impersonator.

TLS certificates are issued by Certificate Authorities (CAs) -- trusted organizations that verify the identity of the certificate requester before issuing a certificate. Browsers and operating systems ship with a list of trusted root CAs, forming the foundation of the web's public key infrastructure (PKI).

Certificate Types: DV, OV, and EV

Certificates differ in how rigorously the CA verifies the requester's identity:

Domain Validated (DV)

DV certificates verify only that you control the domain. The CA confirms this via a DNS challenge, an HTTP challenge, or email to the domain's administrative contact. DV certificates are issued automatically in seconds and are free from providers like Let's Encrypt.

Use when: You need encryption and basic identity verification. This covers the vast majority of web applications.

Organization Validated (OV)

OV certificates include manual verification of the requesting organization's legal identity. The CA confirms the organization exists, is in good standing, and has authorized the certificate request. The organization name appears in the certificate's subject field.

Use when: Your organization needs to display its verified identity in the certificate for compliance or trust reasons.

Extended Validation (EV)

EV certificates require the most thorough vetting: the CA verifies the organization's legal existence, physical address, operational status, and the authority of the person requesting the certificate. Historically, browsers displayed a green bar with the organization name for EV certificates, but most browsers have removed this visual distinction.

Use when: Financial institutions, government sites, or other high-trust contexts where the extended verification is required by regulation or internal policy.

Certificate Chains

TLS certificates form a chain of trust from the leaf certificate (your site's certificate) up to a root CA certificate that the browser trusts:

Root CA Certificate          (trusted by browser/OS)
  |
  +-- Intermediate CA Certificate
        |
        +-- Leaf Certificate    (your site's certificate)

• Root certificate: A self-signed certificate belonging to a root CA. These are pre-installed in browsers and operating systems.
• Intermediate certificate: Signed by the root CA (or another intermediate). CAs use intermediates to issue leaf certificates because if an intermediate is compromised, only it needs to be revoked -- not the root.
• Leaf certificate: Your site's certificate, signed by an intermediate. This is what your web server serves.

Your server must send the complete chain (leaf + intermediates, but not the root). If an intermediate is missing, some browsers will fail to verify the certificate even though others manage to fetch the missing intermediate on their own.

The TLS Handshake

Before encrypted communication begins, the client and server perform a TLS handshake. In TLS 1.3 (the current version), this takes just one round trip:

1. Client Hello: The client sends supported cipher suites, TLS versions, and a random value. In TLS 1.3, it also includes a key share (eliminating a round trip).
2. Server Hello: The server selects the cipher suite and TLS version, sends its own random value and key share, and sends its certificate chain.
3. Certificate Verification: The client validates the certificate chain against its trusted root store, checks the certificate is not expired or revoked, and verifies the domain matches.
4. Finished: Both sides derive the session keys and begin encrypted communication.

TLS 1.2 requires two round trips for the handshake. TLS 1.3 reduces this to one, and supports 0-RTT resumption for subsequent connections (with some security trade-offs).

Certificate Lifecycle

Issuance

You generate a private key and a Certificate Signing Request (CSR) on your server. The CSR contains your public key and the domain name. You submit the CSR to a CA, which verifies your identity and issues a signed certificate.

Renewal

Certificates have a limited validity period. Let's Encrypt certificates are valid for 90 days; commercial certificates typically for 1 year (reduced from 2 years in 2020). Automate renewal with tools like certbot or your hosting provider's built-in certificate management.

Revocation

If a private key is compromised, the certificate must be revoked. Two mechanisms exist: CRL (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol). OCSP Stapling is the modern approach, where the server includes a fresh OCSP response in the TLS handshake so the client does not need to contact the CA.

Common Issues

Certificate Expiration

The single most common TLS issue. An expired certificate causes browsers to display a full-page warning that most users cannot bypass. Monitor expiration dates and automate renewal.

Incomplete Certificate Chain

If your server does not send the intermediate certificates, some clients will fail to verify the chain. Test with tools that do not perform intermediate fetching (unlike most desktop browsers, which do).

Domain Mismatch

The certificate must cover the exact domain being accessed. A certificate for example.com will not work for www.example.com unless the Subject Alternative Names (SAN) field includes both, or a wildcard certificate (*.example.com) is used.

Mixed Content

If your page loads over HTTPS but includes resources (scripts, images, stylesheets) over HTTP, browsers will either block those resources or show a “Not Secure” warning. Use protocol-relative URLs or always use HTTPS for all resources.

TLS Protocol Versions

As of 2025, only TLS 1.2 and TLS 1.3 are considered secure. TLS 1.0 and 1.1 have been deprecated by all major browsers. SSL 3.0 has been deprecated since 2015 due to the POODLE vulnerability. Your server should support TLS 1.3 (preferred) and TLS 1.2 (for compatibility), and disable all older protocols.

Inspect Your Certificate

Use our Domain Intelligence Dashboard to inspect any domain's SSL certificate in detail. The SSL panel shows the certificate grade, validity period, issuer, subject alternative names, protocol version, and the complete certificate chain with expiry information for each link.