SSL/TLS Certificates Explained: What Developers Need to Know

What SSL/TLS actually does

When a user visits your website over HTTPS, their browser and your server establish an encrypted connection. SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are the protocols that make this work.

The certificate serves two purposes:

1. Authentication: It proves to the browser that it's talking to the real server for your domain, not an impostor intercepting traffic.
2. Key exchange: It initiates the cryptographic handshake that establishes the encrypted session.

A certificate is issued by a Certificate Authority (CA) — a trusted third party (like Let's Encrypt, DigiCert, or Sectigo) that verifies you control the domain before signing your certificate. Browsers ship with a list of trusted CAs. If your certificate is signed by a trusted CA and hasn't expired, the browser shows the padlock. If not, it shows a security warning.

---

Certificate types: DV, OV, and EV

Certificates come in three validation levels, each reflecting how thoroughly the CA verified your identity:

For most developers and SaaS products, a DV certificate from Let's Encrypt is perfectly sufficient. It provides the same encryption as an EV cert — the difference is only in how much the CA verified your organization's legal identity, not in cryptographic strength.

---

Wildcard certificates and SANs

A standard certificate covers a single domain (e.g., example.com) and optionally its www subdomain. For organizations with many subdomains, there are two options:

Wildcard certificates cover all subdomains at one level: *.example.com covers app.example.com, api.example.com, status.example.com, etc. They don't cover the root domain (example.com itself) and they don't cover nested subdomains like app.api.example.com.

SAN (Subject Alternative Name) certificates explicitly list multiple domains and subdomains. They're more flexible but require listing every domain at issuance. Let's Encrypt supports up to 100 SANs per certificate.

---

Certificate expiry: the silent killer

Certificates expire. Before 2020, certificates could be issued with 2-year validity. Today, the maximum is 398 days. In 2026, there's an active push to reduce this to 90 days (Let's Encrypt already issues 90-day certificates), and eventually much shorter.

When a certificate expires, browsers show a full-page security warning. Users can't bypass it easily on mobile. For most users, this means your site is effectively unavailable — even if the server is running perfectly.

How certificate expiry surprises teams:

• Auto-renewal fails silently (wrong permissions, DNS challenge failure, expired renewal credentials)
• A subdomain was added manually and never included in the renewal automation
• A certificate managed by a vendor or CDN expired — and nobody noticed it was their responsibility
• A staging or internal environment certificate expired and people assumed it was fine to ignore

---

Automated certificate management with Let's Encrypt

Let's Encrypt provides free DV certificates via an automated protocol called ACME. Tools like Certbot, Caddy, and Traefik integrate ACME natively and handle renewals automatically.

The two main challenge types for proving domain ownership:

• HTTP-01: Let's Encrypt checks that your server serves a specific file at a known path. Works for most web servers. Requires port 80 to be open.
• DNS-01: Let's Encrypt checks for a specific TXT record in your DNS. Required for wildcard certificates, and works even if your server doesn't have a public IP (useful for internal services).

Even with automation, you should monitor certificate expiry independently. Automation can fail. When it does, you want to know 30 days before expiry — not the day users start seeing security warnings.

---

Common TLS issues and how to debug them

For debugging, openssl s_client -connect yourdomain.com:443 is invaluable. It shows the full certificate chain, expiry date, and any chain issues. SSL Labs' SSL Test (ssllabs.com/ssltest) gives a comprehensive grade and identifies configuration weaknesses.

---

How to monitor SSL certificate expiry automatically

The right approach is automated monitoring that alerts you well before expiry. PingBase monitors your SSL certificates as part of its uptime monitoring, sending alerts at 30 days and 7 days before expiry — giving you plenty of time to renew before users are affected.

What to monitor:

• Every public-facing domain and subdomain
• Any domain that handles authentication or payment (expiry here is especially damaging)
• Staging and testing environments — an expired staging cert can block deployments
• Any domain managed by a third party (CDN, email provider, etc.) — they may not notify you

Set up monitoring for every domain you own, not just the ones you think are important. A forgotten subdomain with an expired cert reflects on your brand even if it's not your primary product.