How to Check SSL Certificate Expiration (and the 2026 200-Day Rule)

Enter your domain into InspectMyPage's SSL Checker to see its current certificate status, expiration date, days remaining, issuer, hostname validation, and trust information.

Certificate expiration deserves more attention now because publicly trusted TLS certificate lifetimes are getting significantly shorter. Since March 15, 2026, newly issued publicly trusted Subscriber Certificates may not have a validity period longer than 200 days, and the CA/Browser Forum recommends staying at 199 days or less. The maximum drops again to 100 days in 2027 and 47 days in 2029.

That does not mean every SSL certificate now lasts exactly 200 days, nor does it mean older certificates suddenly stopped working on March 15.

Here's what actually changed, how to check your certificate, and how to avoid an unexpected HTTPS outage.

How to check when your SSL certificate expires

Every X.509 certificate has a validity period.

Two fields define that period:

notBefore

when the certificate becomes valid

notAfter

when the certificate's validity ends

RFC 5280 defines the certificate as valid through that period, including those endpoints.

For most website owners, however, the important questions are simpler:

Is my certificate valid right now?

How long do I have before it expires?

InspectMyPage checks the certificate currently presented by your public hostname rather than requiring you to locate a certificate file on the server.

A healthy result should show that the certificate is trusted, matches the hostname you're checking, is currently within its validity period, and has time remaining before expiration.

That distinction matters because having a valid certificate file somewhere on your server does not necessarily mean your website is actually serving that certificate. A CDN, reverse proxy, load balancer, web server, or stale deployment can still present an older certificate.

Checking the public hostname tells you what visitors are actually receiving.

What changed with SSL certificate lifetimes in 2026?

The CA/Browser Forum has adopted a phased reduction in the maximum lifetime allowed for publicly trusted TLS Subscriber Certificates.

The current schedule is:

These thresholds come from the CA/Browser Forum TLS Baseline Requirements.

So as of today, the first reduction is already in effect.

A publicly trusted certificate issued now cannot exceed 200 days of validity under the Baseline Requirements.

The next major change arrives on March 15, 2027, when that maximum falls to only 100 days.

By 2029, it will be 47 days.

That is a dramatic change from the roughly year-long certificates many website owners became accustomed to.

Why are SSL certificate lifetimes getting shorter?

A certificate establishes trust for a particular identity and public key for a specific period of time.

The longer that period lasts, the longer stale or compromised certificate information can potentially remain useful.

Shorter certificates force the ecosystem to refresh that information more frequently.

But there's an operational consequence: certificate management increasingly needs to become automated.

Manually replacing a certificate once a year is one thing.

Doing it several times per year—and eventually potentially every month or so—is another.

That's one reason protocols such as ACME have become increasingly important. ACME is an IETF-standardized protocol designed to automate certificate management.

Why do some certificates last 199 days instead of 200?

This is one of the easiest parts of the new rule to misunderstand.

200 days is the hard maximum.

It isn't necessarily the duration a certificate authority should routinely issue.

For certificates issued during the current phase, the CA/Browser Forum requirements say they:

MUST NOT exceed 200 days

but:

SHOULD NOT exceed 199 days.

The distinction exists partly because the requirements define a day as 86,400 seconds. Issuing right at the absolute maximum leaves little room for time calculations that could accidentally push a certificate beyond the permitted period.

DigiCert, for example, moved its own public TLS certificates to a maximum of 199 days in February 2026.

So if InspectMyPage shows that your newly issued certificate lasts 199 days rather than 200, that isn't a problem.

It's expected behavior.

The 200-day limit does not mean certificates must last 200 days

This distinction is equally important.

The CA/Browser Forum maximum is a ceiling, not a required certificate duration.

A certificate authority is free to issue certificates that expire much sooner.

Let's Encrypt is a good example. It has been moving toward shorter-lived certificates, including a 45-day tlsserver profile, and has announced plans to shorten its default certificate profile over time.

A certificate that expires in 90, 64, or 45 days is not defective simply because the industry maximum is 200 days.

What matters is that renewal happens reliably before notAfter.

That's why days remaining can be more useful operationally than asking how long the certificate was originally issued for.

Did certificates issued before March 15, 2026 suddenly become invalid?

No.

This is an important misconception to avoid.

The CA/Browser Forum schedule is based on the certificate's issuance date. It does not retroactively rewrite the expiration date of a certificate that was validly issued under the previous rules.

DigiCert, for example, explicitly stated that certificates issued before its transition to shorter validity would continue to be trusted until their normal expiration.

So if you had a valid certificate issued before the transition with more than 200 days remaining, March 15 did not automatically chop its lifetime down to 200 days.

The rule primarily changes what certificate authorities can issue going forward.

How to check an SSL certificate manually

You don't need InspectMyPage to find a certificate expiration date.

Browsers expose certificate information, and developers or administrators can inspect certificates using command-line tools such as OpenSSL.

For a certificate file stored locally:

openssl x509 -in certificate.pem -noout -dates

You'll see values similar to:

notBefore=...
notAfter=...

notAfter is the certificate's expiration boundary.

For technical users, OpenSSL can also inspect the certificate being presented by a remote TLS server.

But there's an important distinction between checking a certificate file and checking the certificate actually being served.

Imagine you renewed a certificate successfully and the new certificate exists on disk.

That doesn't guarantee:

• your web server loaded it,
• your reverse proxy has it,
• your CDN is using it,
• your load balancer has the correct certificate, or
• the correct SNI configuration is serving it for your hostname.

That's why an external check is useful after renewal.

What happens when an SSL certificate expires?

Once a certificate passes its notAfter date, clients can no longer treat it as currently valid based on its certificate validity period.

For a public website, that can mean visitors encounter security warnings rather than reaching the site normally.

Chrome may show a privacy warning and certificate-related error information.

Firefox may report errors such as SEC_ERROR_EXPIRED_CERTIFICATE.

Safari can warn that a site or connection isn't secure when the certificate is expired or otherwise invalid.

A certificate date error does not always mean the website's certificate expired.

For example, Chrome documents that NET::ERR_CERT_DATE_INVALID can also appear when the user's own computer or mobile device has an incorrect date or time.

So if you encounter a date-related certificate warning, don't immediately assume:

“The website forgot to renew its SSL certificate.”

Check both sides.

Verify the device's clock, then inspect the certificate the website is actually presenting.

InspectMyPage can help distinguish an expired certificate from other certificate problems such as hostname mismatch or trust-chain failure.

How to renew an expiring SSL certificate

The exact renewal process depends on who manages your certificate.

A site using managed hosting or a CDN may have certificates issued and renewed automatically with little or no intervention.

A server managed directly with an ACME client may also renew certificates automatically.

A manually managed web server may require the certificate to be renewed or reissued, validated, installed, and then loaded by the relevant web server or proxy.

The important workflow is:

1. Identify who manages the certificate. This may be your host, CDN, certificate authority, control panel, ACME client, or your own server configuration.
2. Renew or reissue the certificate.
3. Complete domain validation if required.
4. Deploy the new certificate and any required intermediate certificates.
5. Reload or restart the service if your platform requires it.
6. Check the public hostname again to confirm the new certificate is actually being served.
7. Verify automatic renewal before relying on it.

That final verification is easy to skip.

A renewal job can report success while the public website continues serving an old certificate because the new certificate wasn't attached to the correct listener, proxy, CDN configuration, or virtual host.

After renewal, check the site from the outside.

How to stop SSL certificates from expiring unexpectedly

The industry's move toward shorter certificate lifetimes makes manual certificate management increasingly fragile.

The long-term solution isn't to become better at remembering expiration dates.

It's to remove remembering from the process.

ACME was designed to automate certificate issuance and management. Newer ACME Renewal Information, or ARI, also allows a certificate authority to tell compatible clients when it recommends renewing a certificate rather than every client relying on the same fixed schedule.

For example, Let's Encrypt recommends that clients using ARI check renewal information regularly. Without ARI, it recommends renewal timing based on the certificate's actual lifetime rather than assuming every certificate follows the same fixed number of days.

That becomes increasingly important as certificate lifetimes shrink.

A good certificate-management process should therefore automate renewal where possible, monitor for upcoming expiration, verify that renewal actually occurred, and verify that the renewed certificate is what the public hostname is serving.

By 2029, when the CA/Browser Forum maximum reaches 47 days, relying on a calendar reminder and a human manually installing certificates will be a much less comfortable strategy.

The bigger change isn't 200 days—it's automation

It's easy to look at the 2026 change and think:

“Okay, certificates used to last about a year and now they'll last about six months.”

But that's only the first stage.

The scheduled progression is:

200 days → 100 days → 47 days.

That changes the operational model.

Certificate renewal is moving from an occasional maintenance task toward a continuous automated process.

For website owners using modern managed hosting or CDNs, much of this may happen invisibly.

That's fine.

You don't necessarily need to become a certificate-management expert.

But you should still be able to answer:

Is my certificate valid?

When does it expire?

Does it match my hostname?

Is its trust chain valid?

Is my website actually serving the renewed certificate?

Those are exactly the questions an external certificate check can answer.