TLS server certificates will have a minimum validity period of 47 days by 2029

The Japanese version is here（日本語版はこちら）

TLS server certificates will have a minimum validity period of 47 days

Ballot SC-081v3 proposed a fundamental review of the TLS Baseline Requirements (TLS BR) and was voted through on April 11, 2025.

Certificate Validity Period Reduction Schedule

The current maximum validity period of 398 days will eventually be shortened to 47 days

The transition will begin in March 2026 and be completed by March 2029

Maximum validity period to 47 days

Table: Reference for maximum Validity Periods of Subscriber Certificates

The period during which validation data can be reused is also significantly reduced

• Subject name (SAN) validation data reuse period: Finally 10 days
• Information other than SAN (e.g., organizational information): Finally 398 days

Table: Domain Name and IP Address validation data reuse periods

Table: Subject Identity Information validation data reuse periods

Reference URL:

https://github.com/cabforum/servercert/compare/b7fd69b36171d81930e7758482984ce957a1ce7a…5f7247ef354cf202c8c6e617bfc4a89e080a085d

Why shorten the validity period now?

Web PKI is an important infrastructure that supports the security of the Internet. Certificates guarantee “correctness at the time of issuance,” but over time the information becomes detached from reality.
Short-term certificates and data revalidation are expected to reduce the following risks:

• Prevents spoofing damage caused by domain transfers, expiration, unauthorized access, etc.
• Reduces the impact of improper validation and erroneous issuance
• Promotes the development of automatic update infrastructure to stabilize operations
• Compensates for lack of performance and reliability of revocation information (CRL/OCSP)
• Enables smooth transition when changing encryption algorithms

Over-reliance on revocation checks is risky

Certificate revocation information is difficult to obtain in real time, and there are many issues with reliability and privacy. By shortening the lifespan of certificates, we can get closer to a structure where natural revocation can be expected without relying on revocation checks.

Google Chrome and Microsoft Edge do not perform revocation checks using CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) each time you browse the web. These browsers use a mechanism called CRLSets to check the revocation status of a certificate when a user accesses a website, rather than contacting the certificate authority every time. This method uses a list of revoked certificates that is regularly updated, but the problem is that it does not include all revoked certificates.

Continued shortening

It is thought that the movement to shorten the validity period will not be completed in 47 days, but will move towards short-lived certificates (validity period of 7 days or less).

Short-lived certificates are certificates with a very short validity period, which can minimize the risk of certificates being obtained illegally, and can also improve management efficiency by automating certificate renewal work. CRL Distribution Points extensions and OCSP (Online Certificate Status Protocol) extensions are not required, and revocation verification is completely unnecessary. Even if an event occurs that meets the revocation requirements of the Baseline Requirements, it is subject to revocation exclusion.

The validity period of subscriber certificates issued between March 15, 2024 and March 15, 2026 will be limited to 10 days.
Furthermore, certificates issued after March 15, 2026 will be required to have an even shorter validity period of 7 days or less.

The following are expected problems.

Infrastructure load due to large volume of certificate issuance

Short-term certificates have a very short validity period of 7 or 10 days, so servers around the world need to re-obtain certificates about once a week. This causes a dramatic increase in the load on all related systems, including CA infrastructure, CT logs, and API backends.

Risk of service outages due to automation failure

Even if automation is assumed, there is an increased risk of certificate renewal failures due to script or batch processing errors, DNS inconsistencies, temporary API failures, etc. This may lead to frequent service outages due to certificate expiration.

Inefficient client-side cache

If certificates are changed frequently in a short period of time, browsers and other clients will need to re-download the certificate chain every time. This increases network bandwidth usage and terminal processing load.

Difficulty in dealing with IoT and embedded devices

It is very difficult to apply this to devices that do not have an automatic update mechanism or have limited network connections for updates (e.g. smart meters, medical equipment, sensors, etc.).

Ballot SC-081v3 Voting Results

*MOIS will not be counted as it was cast outside the voting period.

Result

• Yes: 28
• Abstain: 5 (Excluding MOIS)
• No: 0

Background of the Chrome Root Program Policy v1.6 revision

Important revisions in the Chrome Root Program Policy v1.6, updated on February 15, 2025, may have a significant impact on certificate validity periods.

Root certificates applied for after September 15, 2025 will be required to limit the validity period of TLS server certificates to a maximum of 90 days. This will force future certificate issuance to have a mechanism for updating certificates within 90 days.

However, this change will not be immediately applied to all certificates. Since it applies to certificates applied for after September 15, 2025, certificates issued before that date will not be affected for the time being. In addition, root certificates are replaced every five years, so it is expected that all certificates will be replaced in a way that corresponds to 90 days by around September 2030, and the transition was expected to proceed without waiting for the establishment of Ballot.

The relationship between Apple and Google

Google, which provides Chrome, pays large amounts of money to browser developers such as Apple and Mozilla to set Google search as the default search engine. These payments are called “search default placement fees” and are considered an important part of Google’s strategy to maintain its dominance in the search market.

In 2022, Google paid Apple approximately $20 billion (approximately 2.7 trillion yen) to secure its position as the default search engine in the Safari browser on iPhones, iPads, and Macs. This amount is equivalent to approximately 16.75% of Apple’s annual operating profit.

Note that the timing of Google’s change to Chrome Root Program Policy v1.6 overlaps with the current discussion of Ballot.

Background of Apple’s proposal to shorten the validity period

On October 10, 2024, Clint Wison of Apple proposed the following revised CABF Baseline Requirements (Ballot SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods).

The proposal shortens the maximum validity period of TLS server certificates from 398 days to 45 days. (SC-081v1)

On December 12, 2024, a proposal was presented to reduce the maximum validity period from 398 days to 47 days and to delay the start of the validity period reduction. (SC-081v2)

On March 6, 2025, a proposal was presented to further delay the start of the reduction. (SC-081v3)

The voting period was from April 4 to April 11, 2025, and due to the majority of YES votes, it is expected to be adopted into the Baseline Requirements on April 11, 2025.

Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

groups.google.com

Summary of arguments in favor

This is the right direction for a healthier public CA ecosystem, and systems that cannot support automatic renewal should be placed behind an internal CA, reverse proxy, or WAF. Major browsers are also expected to strengthen client-side validation of certificate validity periods. Operating an internal CA allows full control over certificate validity periods, but security and availability must be ensured. Apple is responsible for protecting users’ secure communications, and some vendors support ACME. Short-term certificates improve encryption flexibility and encourage administrators to renew regularly. The widespread use of automation tools reduces the burden on IT teams and allows for rapid rotation in the event of large-scale revocation events. The proposal is intended to reduce errors, reduce outages, reduce “stale certificates,” and reduce the persistence of attacks.

Summary of Objections

The proposal suggests a lack of experience in the IT industry and is unrealistic given that many software packages and hardware do not support ACME. Lack of ACME support in Windows environments and legacy applications is particularly problematic. Other issues cited include the rising price of public CA certificates and increased business PKI costs, the risk of Let’s Encrypt failing, the one-year grace period for the proposal being too short, and concerns about compatibility with IoT devices. Other issues raised include inconsistencies in validity periods with certificates for electronic signatures, technical debt, and a lack of budget and personnel. The proposal’s forced automation is not suitable for all use cases, and there are concerns about security risks and increased management burden.

Opinions during discussion

Pro-opinion

• The proposal is a step in the right direction towards a healthier public CA ecosystem.
• Systems that cannot support an automatic renewal method should be behind an internal CA or a reverse proxy or WAF.
• If certificates issued by a CA are used for internal systems, it is preferable to use an internal CA.
• Operating your own internal CA gives you full control over certificate validity periods, but in return, you are burdened with ensuring the security and availability of the CA.
• If the proposal is adopted, major browsers will also strengthen client-side validation of certificate validity periods.
• If you don’t want to operate an internal CA, you can use PKIaaS or managed PKI services.
• Apple is responsible for protecting the secure communications of iPhone, iPad, and Mac users.
• Some vendors support ACME (e.g. FortiGate 7.0+).
• You can use an internal CA for remote user VPNs, but ACME integration is also possible when using public CAs.
• Support for ACME is provided in many places, and automating it reduces the burden on IT teams.
• Waiting for all systems to be ACME-enabled will get you nowhere.
• Automation tools and services are widely available, and it’s not the first time that certificate validity periods have been shortened.
• In 2020, Apple unilaterally shortened Safari certificate validity periods, but this time with a one-year notice period.
• Short-term certificates improve cryptographic flexibility in the ecosystem and encourage administrators to update keys regularly.
• The proposal is a good idea, and it is preferable to space the changes evenly over a one-year period.
• The intention of the proposal is to encourage automation to reduce errors (especially key compromises), reduce outages when rapid certificate rotation is required during large-scale revocation events, and reduce “stale certificates” by shortening the expiration time, reducing the persistence of attacks such as BGP hijacking.
• If integrated with a WiFi system, it has outbound connectivity and can obtain certificates.
• If completely offline, it can still install certificates when updating content.
• Large companies like Apple have the budget to make large-scale technology changes in short periods of time.
• Short-term certificates improve cryptographic flexibility in the ecosystem and encourage administrators to update keys regularly.
• The suggestions are a good idea and it would be preferable to space the changes evenly over the course of a year.

Dissenting Opinion

• The proposal suggests a lack of experience in the IT industry.
• It is not realistic because many software packages and hardware platforms do not support ACME or similar automated device certificate rollover.
• IIS, Tier 1 firewall vendors, IoT devices, and many small SAS vendors are not supported.
• ACME clients such as Certbot are widely used on Linux, and there is a mature ecosystem, but the tools and support for Windows are not as well developed.
• Lack of ACME is problematic for both legacy and supporting applications.
• Apple does not have a track record in the server space, so the veracity of the proposal is questionable.
• Public CA certificate prices will rise, increasing business PKI costs.
• If Let’s Encrypt fails, it could cause a major outage on the public internet.
• If the proposed solution or functionality is not provided within a year, consider migrating from the vendor.
• A two-year grace period is needed, from September 2027 to September 2029, instead of the proposed September 2025 to September 2027.
• Response may be delayed because existing validity period changes are burdening IT professionals.
• Certificate exchanges are frequent between vendors, increasing the burden on IT staff.
• Support for IoT devices is the biggest concern.
• We ask for an explanation of why TLS/SSL certificates have a shorter validity period while certificates for digital signatures have a validity period of 3 to 5 years.
• The focus should be on selecting trusted CAs rather than shortening the certificate expiration period.
• Technical debt may be generated and response will take time.
• There may be a lack of budget and manpower to update systems within the 12-month grace period.
• Many vendors are not ready to respond.
• Many systems have limited or no Internet connectivity when personal mobile devices communicate with systems over local Wi-Fi networks using HTTPS.
• Currently, commercial certificates are purchased, manually installed, and renewed every 12 months, but the proposal would require renewal every 45 days.
• Practical alternatives are to not use TLS or to use self-signed certificates and have users ignore warnings, but neither is desirable.
• It is better to rely on revocation rather than shortening certificate expiration.
• The proposal is very controversial and would force the use of automated programs such as ACME.
• TLS server certificates do not require key protection, so a certified signature creation device is required to be legally enforceable.
• I understand the concept of short-term certificates, but it is not practical at this time for TSL/SSL certificates.
• TSL/SSL issuers are not regulated like (Q)TSPs in Europe, so the question is how to ensure that reissued certificates do not use the same key.
• QWAC has been introduced in Europe, but should the same requirements be imposed on TSPs that are already highly regulated?
• ACME supports many challenge types, but they are not suitable for all situations and risk profiles.
• HTTP-01 and TLS-ALPN-01 require direct access to the system that requires the certificate, increasing the attack surface and potentially posing a higher risk than certificates with a 398-day expiration.
• Many DNS zone vendors do not offer fine-grained access control, so DNS-01 challenges require broad write permissions, which may also pose a higher risk.
• Intermediate solutions (border systems making ACME requests on behalf of other systems) are immature and less compatible than ACME itself.
• If the proposal is an indirect means of forcing the use of ACME, it increases security risks for these use cases and also increases administrative burden.
• We ask for more information on the intent and purpose of the proposal.
• Vote against if a vote is necessary. The problem is with applications bypassing recall checks, fix that.
• Automation is not suitable for all use cases, and this proposal may increase errors and failures.
• Built systems and “frozen” devices are very difficult to manage certificate and configuration updates.
• Companies that can barely afford to buy annual certificates switch to free ACME certificates, but these can be easily “hacked”.
• The vote does not change Apple’s decision. A previous vote rejected the shortening of certificate validity periods, but Apple unilaterally implemented the change in Safari.
• What is the point of voting if the results of the CAB Forum vote are not followed by its members? Is the role of the CAB Forum less important than that of browser operators like Apple?
• The Web PKI has moved in the direction of shortening certificate expiration times over the past decade, but questions remain about whether this was the right direction.
• Concerns that with roughly 1.78% of keys being compromised, the remaining 98.22% will be forced into automation.