How SSL Certificates Work (And What to Do When They Expire)

If you manage a website, the SSL certificate is the small green padlock that nobody notices until it breaks. When it breaks, every visitor sees a full-page warning. Traffic stops. Calls start. The fix usually takes minutes. Knowing what to do before the panic starts is the difference between a five-minute incident and an hour-long outage.

This guide covers what SSL certificates actually are and why the 200-day maximum just took effect. It walks through how to check a certificate’s status and the renewal playbook that works for any public CA. If your certificate has already expired, skip ahead to the recovery patterns.

What an SSL Certificate Actually Is

An SSL certificate is a digital file that binds a domain to a public key and an organization. Browsers use it to verify they are talking to the real server and negotiate an encrypted session. Modern certificates use TLS, not SSL, despite the legacy name.

The terminology is misleading. SSL (Secure Sockets Layer) has been fully replaced by TLS (Transport Layer Security). SSL 3.0 was deprecated in 2015. TLS 1.0 and 1.1 were removed from all major browsers by 2021. The current version is TLS 1.3. The term “SSL certificate” stuck because it is what people search for, but the actual protocol is TLS.

A certificate is a signed digital file containing several pieces of information:

• Subject — the domain or organization the certificate is issued to.
• Public key — the cryptographic key the server uses to negotiate encryption.
• Issuer — the certificate authority (CA) that signed the certificate.
• Validity period — the start and end dates during which the certificate is valid.
• Signature — the CA’s cryptographic signature, which browsers verify against their trusted root store.

The trust model is hierarchical. Your server’s certificate is signed by an intermediate certificate. The intermediate is signed by a root certificate held by a public certificate authority. Browsers ship with a list of trusted root certificates. If the chain from your server’s certificate up to a trusted root validates, the browser accepts the connection. If any link breaks, the browser warns the user.

How the SSL/TLS Handshake Works

The SSL/TLS handshake establishes a secure connection in three phases. The browser requests the certificate. The server returns it. The browser verifies the certificate chain and uses the public key to negotiate a shared session key. All subsequent traffic uses that session key.

The handshake happens in milliseconds, but the steps matter when something goes wrong. A simplified TLS 1.3 handshake:

1. Client Hello. The browser sends a list of supported cipher suites. It also sends the requested hostname (via Server Name Indication) and random data for key generation.
2. Server Hello and Certificate. The server picks a cipher suite and sends its certificate (and any intermediate certificates). It returns its own random data plus a key share.
3. Certificate Verification. The browser walks the certificate chain from your server’s cert up to a trusted root in its store. It checks expiration, revocation, hostname matching, and Certificate Transparency log inclusion.
4. Key Exchange. Both sides derive a shared session key from the exchanged random data and key shares. The session key encrypts all subsequent traffic.
5. Finished. Both sides confirm they have the same session key. Application data starts flowing.

TLS 1.3 (the current version) reduced the handshake from two round trips to one, which improved connection speed noticeably. TLS 1.3 also removed obsolete cipher suites and made forward secrecy mandatory. Older protocol versions are gone from all major browsers.

The 200-Day Limit (And What’s Coming Next)

The maximum TLS certificate lifetime dropped to 200 days on March 15, 2026. The CAB Forum’s SC-081 ballot was proposed by Apple and passed in April 2025. It sets further reductions to 100 days in 2027 and 47 days in 2029. Manual renewal becomes impractical at the 2029 cadence.

The CA/Browser Forum (CAB Forum) is the industry body that sets baseline requirements for publicly trusted certificates. In April 2025, Apple proposed Ballot SC-081v3 to reduce maximum certificate lifetimes substantially. The ballot passed without opposition. The phased schedule is now in effect.

The Reduction Schedule

Date	Max certificate lifetime	Max DCV reuse	Renewals per year
Before March 15, 2026	398 days	398 days	~1
March 15, 2026 (now)	200 days	200 days	~2
March 15, 2027	100 days	100 days	~4
March 15, 2029	47 days	10 days	~8

Why It Matters Operationally

The 2029 endpoint is the operational shock. A 47-day certificate lifetime is manageable with automation. The 10-day Domain Control Validation (DCV) reuse limit is harder. Today you can revalidate domain ownership once a year. By 2029 you will need to revalidate every 10 days. That cadence makes manual processes infeasible.

The intent is to force the industry toward automation. CAs that do not support ACME or similar automated protocols will become unworkable. Organizations still managing certificates in spreadsheets will need to switch to certificate lifecycle management platforms or fully automated ACME clients.

Two more dates belong on your calendar. September 30, 2026 is when the first wave of 200-day certificates starts expiring. That is the first real stress test of the new cadence. And September 13, 2026 brings a separate change. Chrome stops trusting new certificates that chain to roots older than its age limit. Your CA handles the root migration, but watch for chain changes around that date.

How to Check Your Certificate’s Status

Use a checker tool that queries the certificate over HTTPS and reports issuer, validity dates, key size, and chain status. NetworkCheckr’s SSL Certificate Checker returns these fields plus warnings for upcoming expiration. Manual checks via openssl s_client also work.

The fastest path is a dedicated checker. NetworkCheckr’s SSL Certificate Checker queries any public hostname and returns the certificate chain. It also reports the issuer, validity dates, key algorithm and size, signature algorithm, and any chain or hostname issues. The tool runs in your browser. No signup. No ads.

For manual checks from the command line, use openssl:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

This returns the certificate’s validity dates, subject, and issuer. The -servername flag is critical for any server that hosts multiple sites under different certificates. Without it, you may get the wrong certificate.

For ongoing monitoring, set up calendar reminders 30 days before each certificate’s expiration. If you use ACME-based auto-renewal, alerts come from the ACME client when renewal fails. Most monitoring services (Datadog, Pingdom, UptimeRobot) include certificate expiration checks as a standard feature.

What Happens When Your Certificate Expires

When a certificate expires, browsers display a security warning and block access by default. Some users can click through the warning, but most do not. Expired certificates cause immediate site outages and damage user trust. There is no grace period.

The browser warning is intentionally alarming. Chrome shows a full-page “Your connection is not private” screen with a NET::ERR_CERT_DATE_INVALID error. Firefox shows “Warning: Potential Security Risk Ahead.” Safari blocks the connection entirely on iOS and shows a similar warning on macOS. Most users hit the back button immediately.

Beyond the user-visible damage, expired certificates break automated systems. API clients reject connections. Scheduled jobs fail. Mobile apps refuse to communicate with the backend. Some browsers cache HSTS preloading, which means users cannot bypass the warning even if they want to.

There is no extension or grace period. The CA-issued expiration date is cryptographically signed into the certificate itself. Modifying it would invalidate the signature. The only fix is to issue a new certificate and install it on the server.

The Universal Renewal Playbook

Renewal is not extension. The CA issues a new certificate with a new validity period. The process has five steps. Generate a new CSR. Submit it to your CA. Complete domain control validation. Install the new certificate. Verify the installation worked.

Step 1: Generate a New CSR

A Certificate Signing Request (CSR) is a file containing your public key and identifying information. Generate it on your server with openssl:

openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

You can also generate a CSR through your hosting control panel (cPanel, Plesk) or your certificate authority’s web interface. Best practice is to generate a new key pair for each renewal, not reuse the old one.

Step 2: Submit the CSR to Your CA

Submit the CSR through your CA’s portal or via an ACME client. Choose the certificate type. DV works for most sites; OV or EV apply only if you specifically need them. Then choose the validity period, whatever your CA offers up to the current 200-day maximum. Most modern CAs accept ACME-based submissions, which automates this step.

Step 3: Complete Domain Control Validation

The CA verifies you control the domain through one of three methods:

• HTTP challenge. Place a specific file at a specific URL on your server. The CA fetches it to confirm control.
• DNS challenge. Add a specific TXT record to your DNS. The CA queries it to confirm control.
• Email challenge. The CA sends a verification email to a predefined administrative address on your domain.

ACME clients handle this automatically. Manual issuance requires you to perform the chosen challenge yourself.

Step 4: Install the New Certificate

Replace the old certificate files on your server with the new ones. For Apache, edit the SSLCertificateFile and SSLCertificateChainFile directives. For Nginx, edit the ssl_certificate and ssl_certificate_key directives. For IIS, import the new certificate through the Server Certificates console. Reload the web server to pick up the new files.

Step 5: Verify the Installation

Confirm the new certificate is serving. Use our SSL Certificate Checker to verify the new expiration date and complete chain. Test from an incognito browser to bypass any cached intermediates. Check that no warnings appear and that the chain is complete. If anything looks off, fix it before announcing completion.

Common Renewal Mistakes (And How to Recover)

Most renewal mistakes come from missed expiration dates, broken automation, or chain issues during installation. The fixes are systematic. Identify the failure mode. Restore an unexpired certificate if available. Generate and install a fresh certificate. Verify chain completeness.

Four recovery patterns cover most disasters.

Pattern 1: The Certificate Expired and You Did Not Notice

Symptom: customers report “your connection is not private” warnings. Site appears down. The fix is the universal renewal playbook above, executed urgently.

If you use a public CA with ACME, run your ACME client manually. Certbot’s certbot renew --force-renewal bypasses the usual “not yet due” check. The whole cycle typically completes in under 10 minutes. If you use a paid CA without automation, generate a CSR and submit through their emergency renewal flow. Most paid CAs issue emergency certificates within an hour.

Pattern 2: Auto-Renewal Quietly Stopped Working

Symptom: the certificate expired despite ACME being configured. The cause is usually one of three. A permissions change. A DNS update that broke the validation challenge. Or a server move that left the ACME client behind.

Check the ACME client’s log first. Common errors fall into three categories. “DNS challenge failed” means DNS records were not updated. “Permission denied” means the client cannot write to the certificate directory. “Rate limit exceeded” means you triggered too many failed renewals. Fix the root cause, then force a renewal. Set up monitoring to catch the next failure earlier.

Pattern 3: Incomplete Certificate Chain

Symptom: some clients work, others do not. Browsers with built-in intermediate caches succeed. Mobile apps, command-line tools, and clean browsers fail. The error is usually “certificate chain incomplete” or “unable to verify intermediate certificate.”

The fix is to install the full chain on your server, not just the leaf certificate. Most CAs provide a “full chain” or “bundled” version of the certificate file. Apache and Nginx both let you concatenate the leaf, intermediate, and chain into a single file. Test with openssl s_client and check that the chain returns all certificates up to (but not including) a public root.

Pattern 4: Wrong Hostname on the Certificate

Symptom: the certificate is valid, but the browser shows “this certificate is not valid for hostname X.” Cause is a Subject Alternative Name (SAN) mismatch or a wildcard limitation. Wildcards cover one level (*.example.com covers www.example.com but not api.staging.example.com).

Generate a new CSR that includes all required hostnames in the SAN list. Reissue with the same CA. Some CAs charge for adding SANs after the fact, so listing them at the original issuance saves money.

ACME Auto-Renewal: The Standard Approach

ACME is the protocol for automated certificate issuance and renewal, defined in RFC 8555. Let’s Encrypt, ZeroSSL, and Buypass all support it. ACME clients like Certbot and acme.sh handle the full lifecycle. Automation is the only practical approach at modern certificate lifetimes.

ACME (Automated Certificate Management Environment) was developed by the Internet Security Research Group, the nonprofit behind Let’s Encrypt. The IETF standardized it as RFC 8555 in March 2019. Every major free CA supports it, and several paid CAs added ACME support to remain competitive.

Choosing an ACME Client

The two most widely used clients:

• Certbot — the EFF-maintained reference client. Written in Python. Easy installation on most Linux distributions. Strong documentation. Default choice for most users.
• acme.sh — shell-based client written entirely in bash. No Python dependencies. Works on minimal systems where Python is not available. Slightly steeper learning curve but very stable.

Web hosts and reverse proxies often include ACME support natively. Caddy, Traefik, and HAProxy all support automatic ACME-based certificate management. WordPress hosts like Cloudways and Kinsta provide one-click Let’s Encrypt integration. If your platform offers built-in ACME, use it.

Setting Up Renewal Cadence

ACME clients renew certificates 30 days before expiration by default. Schedule the client to run twice daily via cron or systemd timer. Renewals only execute when needed. Failed renewals retry on the next scheduled run. The pattern survives transient network issues and brief CA outages without manual intervention.

Note that Let’s Encrypt stopped issuing OCSP responses on August 6, 2025. The CA now publishes revocation information exclusively through Certificate Revocation Lists (CRLs). Most clients handle the transition automatically.

ARI: Let the CA Tell You When to Renew

ACME Renewal Information (ARI) is the newest piece of the automation stack, published as RFC 9773 in June 2025. Instead of renewing on a fixed schedule, an ARI-aware client asks the CA when to renew. The CA answers with a suggested window for each certificate.

The big win is mass-revocation insurance. If a CA must revoke certificates early, ARI tells affected clients to renew before the revocation lands. Your site replaces its certificate automatically instead of going down with everyone else. ARI also lets CAs spread renewal load to avoid traffic spikes.

Support is already mainstream. Certbot added ARI in version 4.1.1, and lego and simple-acme support it as well. Let’s Encrypt has served ARI on the CA side since the draft era. At the 47-day lifetimes coming in 2029, this is the safety margin that keeps renewals from failing silently.

6-Day and IP Address Certificates

The industry is not just complying with shorter lifetimes. Some of it is moving faster voluntarily. Let’s Encrypt made 6-day certificates generally available on January 15, 2026. Each one is valid for exactly 160 hours. They are opt-in: select the shortlived profile in any ACME client that supports certificate profiles.

The same launch brought IP address certificates. You can now get a publicly trusted certificate for a bare IPv4 or IPv6 address. IP certificates must use the shortlived profile and validate via http-01 or tls-alpn-01. The DNS challenge does not apply, since there is no domain to prove. Certbot supports both with the --preferred-profile and --ip-address flags in version 5.3 and later.

Why would anyone choose a 6-day certificate? A stolen key is only useful until the certificate expires, so short lifetimes shrink the damage window. Short-lived certificates also reduce dependence on revocation checking. Google Trust Services goes further with custom validity periods, letting you request 6, 12, or 33 days. And Let’s Encrypt has announced its default lifetime will drop from 90 to 45 days over the next few years.

Related Tools & Resources

NetworkCheckr offers three tools that pair with this guide. The SSL Certificate Checker reports certificate status. The DNS Lookup verifies DNS records used for domain validation. The Reverse DNS Lookup confirms server identity for related checks.

• SSL Certificate Checker — verify any certificate’s issuer, expiration, key size, and chain.
• DNS Lookup — query DNS records, including the TXT records used for ACME DNS-01 validation.
• Reverse DNS Lookup — confirm a server’s PTR record matches its hostname.
• TXT Record Lookup — check ACME challenge TXT records and related DNS entries.
• How Long Does DNS Propagation Take? — understand DCV propagation timing.
• All NetworkCheckr Tools — the full set of free networking utilities.

Frequently Asked Questions

Six questions cover the practical edge cases. Whether the new 200-day limit affects existing certificates. How auto-renewal actually works. What to do during a renewal outage. Whether self-signed certificates have a place. The difference between DV, OV, and EV. And how to choose a certificate authority.