PKI as it stands is only a few steps from Google just deciding everyone must have a short-lived certificate from Google to be on the web.
The root programs who have their own CAs are also cloud providers, who arguably have a legitimate need for the CA. Or in Apple's case they have their own CA, but don't issue externally. They keep CA and root program separate.
If you don’t like a particular CA’s policies, you can choose a different one.
The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.
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-sch...[2]: https://www.entrust.com/blog/2020/02/apple-announces-398-day...
You can now make any web server operate with a publicly valid TLS certificate without paying any money, registering a domain, configuring DNS or disclosing any personally identifiable information. It can be entirely automatic and zero configuration. The only additional service required is something like a STUN server so the public IP can be discovered and updated over time.
He is hosting his domain on a machine behind a reverse proxy over which he has no control (common enough); in this case the server will not know its own public IP as all resolves to (for example) `www.mydomain.com` will return the address of the proxy. To get the public IP he uses a STUN (or similar) public-facing service.
Not quite sure why he needs the public IP, though: from what I remember, the certs include the domain, not the IP.
TLS is not The Web
Does the TLS working group know that? Pretty much all their design work apart from one guy representing email use via Postfix and a few guys working on a perpetual-motion-machine profile for telcos assumes the only possible use for TLS is the web.Personally, I think we have a bigger problem on the PKI side, where Web PKI is very strong, but Internet PKI has been neglected. The recent move to remove client authentication is a good example.