3 ms·

The CA/Browser Forum, not Google, decides the length of time certificates are valid for. If you don’t like a particular CA’s policies, you can choose a differe

The CA/Browser Forum, not Google, decides the length of time certificates are valid for. If you don’t like a particular CA’s policies, you can choose a different one.

ocdtrekkie 7mo ago
That's fundamentally untrue. Browser root programs unilaterally decide their requirements, and also unilaterally boot other CA/B members out of the CA/B. The CA/B is not by any means a useful functional body, it's an excuse why companies can't be forced to undo things after the fact.
nickf 7mo ago
That's absolutely incorrect. While CABF sets the 'Baseline Requirements' that ultimately go into the WebTrust audit scheme that root programs use to accept roots into their trust stores...browsers can and do set their own rules. The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.
- alwillis 7mo ago
  > browsers can and do set their own rules. Here's a link to the minutes of the CABF meeting where the 25 certificate issuers and the 4 browser vendors—Apple, Google, Microsoft, Mozilla—agreed to reduce the validity period of TLS certificates unanimously [1]. > The reduction of TLS cert lifetime to a max of 398 days was an Apple policy. Actually, all of the browser vendors voted to reduce the validity period of TLS certificates from 825 days to 398 days at the September 2019 meeting. The ballot failed because a majority of the certificate issuers voted against it. At the February 2020 CABF meeting, Apple announced it would unilaterally enforce the 398-day limit through its own root program policy. Starting September 1, 2020, any new TLS certificate with a validity period exceeding 398 days would simply not be trusted by Safari, macOS, or iOS. This effectively made the 398-day limit a de facto standard — no CA would issue longer certificates if they’d be rejected by Apple devices [2]. |Date |Max Certificate Validity|SAN Data Reuse Period| |-----------------|------------------------|---------------------| |Before March 2026|398 days (current) |398 days | |March 15, 2026 |200 days |200 days | |March 15, 2027 |100 days |100 days | |March 15, 2028 |47 days |10 days | |March 15, 2029 |47 days |10 days (final) | [1]: https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/ https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-sch... [2]: https://www.entrust.com/blog/2020/02/apple-announces-398-day-maximum-certificate-lifetime https://www.entrust.com/blog/2020/02/apple-announces-398-day...

The CA/Browser Forum, not Google, decides the length of time certificates are valid for. If you don’t like a particular CA’s policies, you can choose a different one.

ocdtrekkie 7mo ago

That's fundamentally untrue. Browser root programs unilaterally decide their requirements, and also unilaterally boot other CA/B members out of the CA/B. The CA/B is not by any means a useful functional body, it's an excuse why companies can't be forced to undo things after the fact.

nickf 7mo ago

That's absolutely incorrect. While CABF sets the 'Baseline Requirements' that ultimately go into the WebTrust audit scheme that root programs use to accept roots into their trust stores...browsers can and do set their own rules. The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.

alwillis 7mo ago
> browsers can and do set their own rules. Here's a link to the minutes of the CABF meeting where the 25 certificate issuers and the 4 browser vendors—Apple, Google, Microsoft, Mozilla—agreed to reduce the validity period of TLS certificates unanimously [1]. > The reduction of TLS cert lifetime to a max of 398 days was an Apple policy. Actually, all of the browser vendors voted to reduce the validity period of TLS certificates from 825 days to 398 days at the September 2019 meeting. The ballot failed because a majority of the certificate issuers voted against it. At the February 2020 CABF meeting, Apple announced it would unilaterally enforce the 398-day limit through its own root program policy. Starting September 1, 2020, any new TLS certificate with a validity period exceeding 398 days would simply not be trusted by Safari, macOS, or iOS. This effectively made the 398-day limit a de facto standard — no CA would issue longer certificates if they’d be rejected by Apple devices [2]. |Date |Max Certificate Validity|SAN Data Reuse Period| |-----------------|------------------------|---------------------| |Before March 2026|398 days (current) |398 days | |March 15, 2026 |200 days |200 days | |March 15, 2027 |100 days |100 days | |March 15, 2028 |47 days |10 days | |March 15, 2029 |47 days |10 days (final) | [1]: https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/ https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-sch... [2]: https://www.entrust.com/blog/2020/02/apple-announces-398-day-maximum-certificate-lifetime https://www.entrust.com/blog/2020/02/apple-announces-398-day...