The New Validity Period of TLS Certificates – AVANTEC

About the job

Certificates will in future only be valid for 47 days, making automation essential. Before this proposal from Apple, Google had advocated for a maximum validity period of 90 days, but practically immediately aligned with Apple’s view.
The schedule:
The maximum certificate validity period will be reduced:
Between today and 15 March 2026, the maximum validity period of a TLS certificate is 398 days.
From 15 March 2026, the maximum validity period of TLS certificates will be 200 days.
From 15 March 2027, the maximum validity period of TLS certificates will be 100 days.
From 15 March 2029, the maximum validity period of TLS certificates will be 47 days.
I explain here, with the help of DigiCert’s blog, the current status and how we at AVANTEC see and approach the topic.
Why 47 days?
47 days may seem arbitrary, but can be easily explained:
200 days = maximum number of days within 6 months (184 days) + half a month of 30 days (15 days) + 1 extra day
100 days = maximum number of days within 3 months (92 days) + ~ a quarter of a month of 30 days (7 days) + 1 extra day
47 days = maximum number of days within 1 month (31 days) + half a month of 30 days (15 days) + 1 extra day
Apple’s reasoning for the change
Apple cited numerous arguments in the vote, one of which is particularly noteworthy. The CA/B Forum has made it clear through the continuous shortening of maximum durations over the years that automation is essential for effective certificate lifecycle management.
The vote states that shorter durations are necessary for many reasons:
The information in certificates loses trustworthiness over time, a problem that can only be improved by frequent revalidation of the information.
Revocation with CRLs and OCSP is unreliable. In fact, browsers often ignore these functions. There are many shortcomings in certificate revocation. A shorter validity period reduces the impact of using potentially compromised certificates.
In 2023, the CA/B Forum further emphasised its view by approving short-lived certificates without CRL or OCSP that expire within 7 days.
Explanation of the new regulation
Two points of the new regulation could cause confusion:
The rules change in 2026, 2027, and 2029, with the gap between the last two years being two years.
From 15 March 2029, the maximum lifetime of a TLS certificate will be 47 days, but the maximum reuse of domain validation information will only be 10 days. Manual revalidation is technically still possible but will certainly lead to errors.
The certification authority and we at AVANTEC are frequently asked by customers whether more frequent certificate renewals will incur higher costs. The answer is no. It is an annual subscription, and we have found that users often voluntarily replace their certificates faster once they switch to automation.
Therefore, and since even the changes to 100-day certificates in 2027 will no longer be manageable with manual procedures, we expect a rapid switch to automation long before the changes come into effect in 2029.
Apple’s statement on automated certificate lifecycle management is correct and something we have long prepared for. DigiCert offers various automation solutions with the Trust Lifecycle Manager and CertCentral, including support for the ACME protocol. DigiCert’s ACME protocol enables automation of DV, OV, and EV certificates and includes support for ACME Renewal Information (ARI). About ARI: "ARI is a related standard by which the server can suggest a schedule so the client knows to renew the certificate before it expires. Properly configured, ARI can instruct the client to renew if the certificate has been revoked, preventing an outage."
The challenge
Many appliance and software manufacturers still do not have automatic certificate replacement on their devices.
There is not much time left for a usable connection. DigiCert, for example, already offers a variant with DNS hosting and automation. We know from SwissSign that they are working on it. On the open market, "Let’s Encrypt" has long been present with support for ACME or other automatic updates. What bothers me here is an approach where I have to allow access to a web server via port 80 for the automatic process. Nowadays, I am a fan of "all connections away from me" and not to me. I find verification via a DNS-TXT hash entry much more appealing. But how can I automatically make an entry in the TXT? Not all hosts allow this. If I have access to the DNS, the so-called DNS-01 challenge also works with "Let’s Encrypt": https://letsencrypt.org/de/docs/challenge-types/#dns-01-challenge. There is still much potential for support in this area. DigiCert does it so that they host the domains themselves and can therefore do this 'internally'. Under the chapter Additions, we see that you are not forced to use their DNS. That is quite appealing.
Automation
This topic would require its own blog article. Perhaps there will be one in the near future.
According to https://docs.digicert.com/en/trust-lifecycle-manager/enroll-and-manage-certificates/enrollment-protocols-and-apis.html, there are different protocols and APIs. Which manufacturers support CMP, EST, SCEP, and REST API? Unfortunately, ACME is often the limit.
We find a lot of information about "Managed Automation Solutions" at DigiCert.
https://docs.digicert.com/en/trust-lifecycle-manager/automate-management-of-certificates/managed-automation-solution.html
It leaves us with many open questions. We want to automate as many phases of the certificate lifecycle as possible. This is explained in more detail in the link. We still see a lot of work here!
In summary:
A big wave is coming towards us and no one really wants to acknowledge it. We remain vigilant and continuously look out for possible approaches so that we are ready in the near future to implement suitable solutions with our products.
End of Client Authentication EKU for DigiCert public TLS certificates
I would also like to mention this important information.
According to this article, the "Client Authentication EKU" will be completely removed by 1 May 2026. The requirements of the Google Chrome Root Program demand specific TLS root hierarchies whose policies no longer support "Client Authentication" and "Code Signing" for security reasons. The mentioned link is a document in which the latest statuses are adjusted and the timing and the "why" are described in more detail.
Addition
What is often mentioned in the context of QC (Quantum Cryptography) resistant cryptography: You also gain some crypto agility for the switch to PQC algorithms.
It probably does not have to be only DNS at DigiCert. Many others are supported.
Further links
https://www.digicert.com/de/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days https://www.avantec.ch/loesungen/swisssign/ https://www.avantec.ch/loesungen/digicert/ https://thesmartbug.com/blog/integrating-acme-renewal-information-ari-into-existing-clients/
The article The New Validity Period of TLS Certificates first appeared on Tec-Bite.