After more than 10 years, short-lived TLS certificates are finally permitted by the browsers based on CA/Browser Forum ballot SC-063. Gerv Markham started a short-lived certs discussion in 2014, where he advised he was reviewing the 2012 CA/Browser Forum discussion on the topic. He advised that short-lived certificates was a plank of the Mozilla revocation strategy. There was also a paper prepared in 2012 called Towards Short-Lived Certificates. The paper stated OCSP is as good as dead, so the CAs should issue certificates with a very short lifetime. I suppose no one thought it would take so much time.
Short-lived certificates are designed to help address a certificate revocation issue. Back in 2012, Adam Langley discussed the seat-belt issue, where it works fine, but snaps when you crash. This was based on the fact the browser implements soft-fail revocation checks where the CRL or OCSP response is ignored.
Even when the CA certificate status is trusted, there may be other issues. A CRL may be valid for up to 10 days, so even if a certificate is revoked, an attacker may be able to provide a valid CRL for many days after the revocation.
There are also privacy concerns where OCSP requests reveal details of individuals’ browsing history to the operator of the OCSP responder. As such, many browsers do not perform online OCSP checks by default.
Effective after ballot SC-063 completes intellectual property review, the CAs can issue short-lived TLS certificates, where the validity is less than or equal to 10 days. Effective March 15, 2026, the short-lived certificate validity period will drop to a maximum of 7 days. Since the validity period would be less than the effective period of a CRL or an OCSP response, the CA does not have to provide status of short-lived certificates. This means you may not find any CRL or OCSP information in a short-lived TLS certificate. In addition, the CA does not have to revoke a short-lived certificate.
To address the OCSP privacy issue, effective March 15, 2024, the CA does not have to provide an OCSP response. Note that most CAs will continue to support OCSP for all TLS certificates based on the Microsoft Trusted Root Program Requirements. We do expect Microsoft will address this policy issue in the future.
To ensure status continues to be provided to non-short-lived certificates, effective March 15, 2024, the CAs must provide a CRL for all non-short-lived TLS certificates. The ballot also addresses partitioned CRLs or sharded CRLs, which allows a CRL download to be smaller, so there is less delay for the browser user.
The ballot should not provide any impact to the services from your CA. If you do not get CRL support, it will be available in 2024. OCSP responses will stay available from all CAs that are trusted by Windows.
Entrust continues to support both CRL and OCSP for TLS certificates.