Prepare for Certificate Expiration Shortening

The maximum validity of public TLS certificates will gradually shorten over the coming years:

• Until March 15, 2026, the maximum validity of a TLS certificate is 398 days.
• From March 15, 2026, the maximum validity of a TLS certificate will be 200 days.
• From March 15, 2027, the maximum validity of a TLS certificate will be 100 days.
• From March 15, 2029, the maximum validity of a TLS certificate will be 47 days.

The maximum period for reusing domain and IP address verification information is also shortening:

• Until March 15, 2026, the maximum reuse period for verification data is 398 days.
• From March 15, 2026, the maximum reuse period for verification data is 200 days.
• From March 15, 2027, the maximum reuse period for verification data is 100 days.
• From March 15, 2029, the maximum reuse period for verification data is 10 days.

The maximum certificate validity determines the highest number of days for which the certificate is considered valid. In order for a Certificate Authority (CA) to issue a certificate, it must verify that the applicant actually controls the domain or IP address listed in the certificate.

If you currently have a certificate and renew it annually (according to the current rules), re-verification of domain control occurs with each renewal.

But what if you need to replace the certificate earlier than renewal — such as if the private key is compromised? In such a case, the CA can reuse the verification performed at the last renewal, avoiding the need for new validation. This is possible because the maximum reuse period for domain verification has not yet expired.

The basic requirements (also known as Baseline Requirements, or the CA/B Forum rules for certificate issuance) have always defined both of these time limits, but they were usually set to the same value.

The change in the last phase of the new rules — when the maximum certificate validity decreases to 47 days, while the domain verification can be reused for only 10 days — is intended to ensure that verification is performed more frequently. The CA/B Forum assumes that information about domain control becomes outdated very quickly.

The same domain verification schedule will apply to OV and EV certificates. Verification will need to be performed at the same intervals as for DV certificates, i.e., every 200 / 100 / 10 days.

Other information contained in OV and EV certificates (such as the organization name and address) will require renewal only every 398 days. While domain verification can and should be automated, this additional information cannot be fully automated.

No, not exactly. The restrictions affect what certificates certificate authorities (CA) can issue, not what certificates browsers can accept.

The browser only verifies that the current date falls within the certificate's validity period.

Once the individual rule changes take effect, certification authorities will no longer be able to issue TLS certificates with a validity longer than 200 / 100 / 47 days.

However, a certificate with a validity of 398 days that was issued before the rule change will remain valid until it expires. The same is true for certificates with a validity of 200 days when transitioning to the 100 days limit and for certificates with a validity of 100 days when transitioning to the 47 days limit.

No, the baseline requirements are mandatory only for public certificate authorities.

Internal PKI operates within your network or clouds. It encompasses certificate authorities, but the policies that internal certificate authorities apply — including certificate validity periods — are determined by you. A short validity period may be appropriate for internal PKI, but it is not mandatory. All internal PKI software can be managed yourself, but it is a complex and error-prone task. DigiCert offers various internal PKI solutions for enterprise, cloud, and manufacturing scenarios.

No. During the order period (in years), there are no additional costs for renewal or certificate replacement. You can perform an unlimited number of reissues during the order validity period.

No, they apply only to leaf certificates issued by the intermediate certificate authority. There are no CA/B Forum or other standards bodies rules limiting root and intermediate certificate validity periods, but best practices are generally recognized, and software vendors that use certificates set their own rules for their trusted root programs, which may vary significantly.

The Mozilla Root Store Policy (section 7.4) states that Mozilla will cease to trust root certificates 15 years after the key is generated.

The lifetime rules in the Chrome Root Program Policy, version 1.6 (February 15, 2025), are more complex. There is no fixed limit, but "any root CA certificate with key material generated more than 15 years ago will be progressively removed from the Chrome Root Store." Roots containing keys created before April 16, 2014, will be removed according to a fixed yearly schedule defined in the Root Program Policy.

The Microsoft Trusted Root Program states that "newly issued root CAs must have a validity period of at least eight years and a maximum of 25 years from the date of submission." The difference in rules between Microsoft's policy and others stems from the range of applications that Microsoft supports in its PKI, significantly broader than those of other browsers.

A common best practice is that a CA root certificate should not expire before any associated intermediate CA certificate.

Poor root and intermediate CA life cycle management can have serious consequences, as recently illustrated when a seemingly forgotten Google intermediate CA certificate expired, leaving many Google Chromecast devices without service.

For common and simple cases, like web servers and public TLS certificates, automation is free for CertCentral customers thanks to the widely supported Automated Certificate Management Environment (ACME) and ACME Renewal Information (ARI) standards.

Of course, not all certificates are public TLS, and not all technologies support ACME. For these cases, DigiCert Trust Lifecycle Manager provides advanced automation and integration options.

Automating with ACME requires some changes to the device or application (typically a web server) that requests the certificate. For most administrators, this process is straightforward and well-documented.

ACME is the Automated Certificate Management Environment.
ARI is ACME Renewal Information.

ACME is a standard supported by all major certificate authorities, whereby certificate client software (typically a web server) requests a certificate from the CA and installs it on the client. (In this scenario, the web server is the client.)

Client software must also support ACME. Support is widespread but not universal. The ACME client program typically runs on the client system per a schedule using Linux cron or Windows Task Scheduler, but other solutions integrate scheduling into larger products.

ARI is a related standard whereby the server can recommend a schedule, so the client knows to renew the certificate before it expires. With proper configuration, ARI can instruct the client to renew even if the certificate has been revoked, preventing an outage.

Under the new TLS certificate rules from March 15, 2026, it will be possible to reuse Subject Identity Information (SII) verification only for 398 days, instead of the current 825 days.

This means the main impact on your OV and EV certificates will be the need to re-verify SII (the information in the certificate that identifies your organization) annually, instead of every two years.

According to the TLS Baseline Requirements, this requires an annual phone call with a DigiCert representative, so the process cannot be fully automated.

Note that OV and EV certificates also protect domain names, so their validity period will change according to the same schedule as DV certificates: to 200 days in 2026, 100 days in 2027, and 47 days in 2029. Therefore, the need to automate management of these certificates is as critical as for DV certificates.

The number of 47 days may seem arbitrary, but it is based on a simple sequence:

• 200 days = 6 maximum months (184 days) + 1/2 thirty-day month (15 days) + 1 day buffer
• 100 days = 3 maximum months (92 days) + approximately 1/4 of a thirty-day month (7 days) + 1 day buffer
• 47 days = 1 maximum month (31 days) + 1/2 of a thirty-day month (15 days) + 1 day buffer

This model of setting an "odd" validity period with an added buffer has been standard practice by the CA/B Forum for a long time. The current limit of 398 days was chosen as 1 maximum year (366 days) + 1 maximum month (31 days) + 1 day buffer.

Yes, according to the rules, it is possible to get another 398 days if you renew your certificates before March 15, 2026. However, this is a one-time extension — at the next renewal, the maximum validity period will already be reduced to 100 days. Therefore, set up automation in advance to be prepared.

If you need to recreate a certificate with a new key (rekey) on or after March 15, 2026, DigiCert (like any other public certificate authority) must comply with the rules in effect at the time, giving you a certificate with a maximum validity of 200 days in the best case.

The best time to automate certificate management is as soon as possible — ensure that you are ready for this process without risking outages caused by expired certificates or other problems.

The market for public TLS certificates is primarily geared towards certificates used in browsers, typically installed on a web server, but there are other use cases as well. VPN gateways and some internet of things (IoT) devices are good examples.

These devices will also need to speed up their certificate lifecycle management pace. Many directly support ACME or another automation protocol, making parameter changes minimal. In other cases, there may be support for an alternative automation mechanism or no support at all — here, the user will need to provide programmatic automation.

Adapting to the new schedule will be a common problem for these devices. It is essential to create a complete inventory of affected assets, which DigiCert can help with.