Check Your Certificate's Days Left Above

Check Your Certificate's Days Left Against the 47-Day Timeline

Paste your certificate into the inspector above and it reads the exact notBefore and notAfter date pair, defined in RFC 5280 Section 4.1.2.5, that decides how long it stays trusted before it must be replaced.¹ Until 2020, the CA/Browser Forum permitted public TLS certificates valid for up to 825 days. Apple then unilaterally enforced a maximum of 398 days in Safari², and the CA/Browser Forum followed. The CA/Browser Forum ballot SC-081v3, passed in April 2025, will reduce the maximum validity for publicly trusted TLS certificates to 47 days by March 2029, following a staged reduction schedule³, so checking where your own certificate sits on that timeline now saves you from a scramble later.

Current maximum validity periods and the reduction timeline

As of mid-2026, the maximum validity period for publicly trusted TLS certificates is 398 days (approximately 13 months). The CA/Browser Forum ballot SC-081v3 introduces a phased reduction: from 398 days to 200 days starting March 15, 2026; to 100 days starting March 15, 2027; and to 47 days starting March 15, 2029. Additionally, the maximum data reuse period for domain validation is being reduced alongside certificate lifetime. Let's Encrypt already operates below these limits, issuing 90-day certificates today with plans to move to 45-day certificates by 2028⁴. Furthermore, internal certificates issued by private CAs are not subject to CA/Browser Forum requirements and may carry validity periods of multiple years, which some organizations use to reduce management overhead for internal services at the cost of a longer compromise exposure window.

How to track the reduction schedule for your own infrastructure

The phased reduction means different certificates in your infrastructure will be affected at different times depending on their issuance date. The CapyToolkit Certificate Inspector displays the notBefore and notAfter dates along with the remaining validity, so you can see how long each certificate stays valid and plan replacements before each step takes effect. Marking certificates issued before each effective date helps your team prioritize which ones to replace first as the shorter limits take hold.

Why shorter validity periods improve security

The security argument for shorter validity periods rests on limiting the damage window from a private key compromise. When a TLS private key is stolen, an attacker can impersonate the server for any connection they can intercept until the certificate expires or is revoked. Revocation is unreliable: OCSP soft-fail means browsers often proceed even when the OCSP responder confirms revocation if the responder is unreachable. Consequently, the certificate's validity period is the outer bound on how long a compromised key remains useful to an attacker. A 47-day certificate limits the damage window to 47 days without relying on revocation working correctly. Furthermore, shorter validity windows force organizations to automate renewal, which as a side effect improves deployment hygiene: organizations with automated renewal tend to discover and remediate certificate misconfigurations more quickly because each renewal cycle restarts from a clean state.

Why revocation alone is not a sufficient safety net

OCSP soft-fail means browsers often proceed even when the OCSP responder confirms revocation if the responder is unreachable. Revocation also depends on the client being able to reach the OCSP responder at all, which is not guaranteed on restricted networks. Consequently, relying on revocation as your only defense against compromised keys is risky, and a shorter validity period provides a hard upper bound on exposure that does not depend on revocation infrastructure being available.

The practical takeaway is to treat the validity window as your real security budget. A short-lived certificate limits how long a stolen key can do damage, so shorter lifetimes directly reduce risk even when nothing else changes. The CapyToolkit Certificate Inspector shows the Days Left countdown for every certificate, so you can see at a glance which certificates are approaching the window where a renewal failure turns into an outage.

Validity periods for different certificate types

Different certificate types carry different validity period norms based on their role in the PKI hierarchy. Leaf certificates for public TLS will be capped at 47 days by 2029 under SC-081v3. Intermediate CA certificates typically carry five-to-ten year validity periods; they are signed less frequently than leaf certificates and their keys are kept more securely. Root CA certificates typically carry validity periods of twenty to thirty years, reflecting the difficulty of distributing root updates to all devices worldwide.

How root and intermediate validity periods affect your renewal planning

When an intermediate CA certificate expires, every leaf certificate it has signed becomes invalid regardless of the leaf's own notAfter date. This means your renewal planning must account for the entire chain, not just the leaf certificates you manage directly.', Code signing certificates and S/MIME certificates follow their own CA/Browser Forum baseline requirements with different validity limits. Yet all of these validity periods are enforced the same way: by the notAfter field in the X.509 certificate, and any TLS client that enforces validity dates will reject any certificate past that date regardless of the certificate's type or the CA's intentions.

When to use this

Check your certificate above when planning a management strategy that spans the CA/Browser Forum's validity reduction timeline, or when auditing certificates for compliance with your organization's key management policy. It also helps when deciding whether to migrate from manual annual renewal to ACME-based automation, since the case for automation becomes urgent as validity windows shrink toward 47 days.

Examples