Mastodawn

As an aside: there's a reason #CABForum standards aren't supposed to apply to private CAs.

CA/B are moving back to CRLs for #certificate revocation because #OCSP doesn't work well. To keep #CRL size manageable, this requires certificate lifetimes to be very short (they decided on 47 days).

But a private #CA is a completely different animal. A private CA might only issue a few dozen certificates in its entire existence. Its CRL will never get huge.

Eckes

Jan 5

Gibt’s eigentlich schon sinnvolle kommerzielle oder freie issuer für clientAuth Zertifikate? #webpki #cabforum #tls

Pontiff Fractal Tiam Nov 19

I totally missed the memo that #letsencrypt disabled #OCSP:

https://letsencrypt.org/2024/12/05/ending-ocsp

And I see that there has been a #cabforum ballot making OCSP optional with only one issuer opposing:

https://cabforum.org/2023/07/14/ballot-sc063v4-make-ocsp-optional-require-crls-and-incentivize-automation/

A terrible Idea. And to make it worst, LE is distributing their #CRL over #cloudflare just as they did with their OCSP endpoints.

Ending OCSP Support in 2025

Earlier this year we announced our intent to provide certificate revocation information exclusively via Certificate Revocation Lists (CRLs), ending support for providing certificate revocation information via the Online Certificate Status Protocol (OCSP). Today we are providing a timeline for ending OCSP services: January 30, 2025 OCSP Must-Staple requests will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension May 7, 2025 Prior to this date we will have added CRL URLs to certificates On this date we will drop OCSP URLs from certificates On this date all requests including the OCSP Must Staple extension will fail August 6, 2025 On this date we will turn off our OCSP responders Additionally, a very small percentage of our subscribers request certificates with the OCSP Must Staple Extension. If you have manually configured your ACME client to request that extension, action is required before May 7. See “Must Staple” below for details.

ducksauz 🦆Oct 14

Does anyone know of the CA/Browser forum SC81 ballot to reduce certificate validity periods only applies to TLS Server and Client certificate usages or if it applies to all key usages?

This could create a huge pile of churn and toil if it also applies to certs used for SAML assertion signing, which have key usages set for: Digital Signature, Non Repudiation, Key and Data Encipherment.

ETA: paging @ScottHelme now that I've found him here.

#security #certificates #sc81 #cabforum

Klaus Frank Jun 9, 2025

Oh the #cabforum also wants to sunset "certificate issuance for .arpa domains".
At least one person following here uses an .arpa domain for their mastodon instance, so you probably want to checkout https://github.com/cabforum/servercert/pull/573
I guess.

SC-86: Sunset the Inclusion of Address and Routing Parameter Area Names by CBonnell · Pull Request #573 · cabforum/servercert

Resolves #153.

GitHub

Outvi V Apr 14, 2025

#CABForum passed SC-081v3 to shorten public #TLS cerficiate validity to a eventual 47 days, creating a market for new jobs like "certificate renew specialist" and "technican for certificate error ignoring".

This also brings light to a world of easier phishing cuz... you know, people don't get smarter in 1 or 2 days because some vote is passed.

https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/9768xgUUfhQ

Initial Vote Results on Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

Jesse Harris Oct 16, 2024

I see a lot of weeping, wailing, and gnashing of teeth over this proposal, but how do you think we get from "manually handle all of your certs in nightmare mode" to everything supporting ACME? You put a gun to the heads of the software vendors and equipment makers with a hard deadline. Not saying it won't suck for a while, especially with legacy systems, but that pain is decades of tech debt coming due. #cabforum #certificates https://github.com/cabforum/servercert/pull/553

SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods by clintwilson · Pull Request #553 · cabforum/servercert

Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2) Overall reduction of non-SAN validation reuse from 825 to 366 da...

GitHub

adorfer Oct 11, 2024

for those who refused to automate their TLS certificate deployment so far: prepare for increased workload:
"
- Overall reduction of non-SAN validation reuse from 825 to 366 days
- Overall reduction of SAN validation reuse from 398 days to 10 days
[..]
Overall reduction of maximum validity period from 398 days to 45 days
These reductions are proposed to occur starting in September 2025 through September 2027
"
https://github.com/cabforum/servercert/pull/553
#tls #cabforum

SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods by clintwilson · Pull Request #553 · cabforum/servercert

Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2) Overall reduction of non-SAN validation reuse from 825 to 366 da...

GitHub