Hanno - we may have communicated before some years ago, but am more than happy to offer any help I can (if some of our customers are/were affected, happy to reach out and see if they can give you more answers as to which products).
nick (at) sectigo (dot) com
For any target of sufficient value that a government would do that, yes.
Of course it doesn't happen anyway, because governments don't have some kind of secret access to CAs.
I would imagine, as a CA that issues only DV certs, they'd disallow issuance to various ccTLDs, and perhaps stop newAccount registrations with email addresses at those ccTLDs. That's about as much as they could do - IP-blocking by region is ineffective and crude at best.
The question is, will that be enough? If OFAC can demonstrate that even with such restrictions, sanctioned entities are frequently obtaining certificates, they may be forced to require account creation or something else as a means of limiting that.
They also likely would have to implement some kind of domain name screening, just like banks have to block transfers that mention "Havana" or "Tehran".
They are currently not doing anything, even ccTLD blocks. They have issued certificates for .kp domains this month and in August of last year.
You’re right of course, but Apple won’t do it - they’re happily running a two-tier system where Uber, eBay, Doordash can force spam notifications on you with impunity. All my settings for marketing are off - eBay still sends me notifications about coupons (and additionally there’s no way to actually contact them to complain, of course). Doordash won’t let me get delivery notifications without marketing notifications.
Apple could fully enforce their policies and fix this in a heartbeat, but they won’t.
While I sort-of see what you're trying to say, if you knew the groups and teams involved - you'd know there was no favouritism and a strong degree of separation between CA and root programs.
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.
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.
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) |
Your failure to see the problem doesn’t mean it doesn’t exist. 40x the size might not really be an issue for the hypothetical server you’ve suggested - but that isn’t the reality for the world. Many devices do HTTPS and TLS.
Not to mention the issue is more with the clients.
CT logs would get a lot harder to run (and they’re already not so easy).
Google dominate the space because they have an active, robust trust-store program that they manage well. Apple the same. Mozilla and Microsoft too (though to a lesser extent).
If any ecosystem - such as XMPP - wishes to, they could start their own root-program, but many simply copy what Chrome or Mozilla do and then are surprised when things change.
