nickf

6 ms·

61.
by nickf 1y ago
Don't forget the lede buried here - you'll need to re-validate control over your DNS names more frequently too. Many enterprises are used to doing this once-per-year today, but by the time 47-day certs roll around, you'll be
62.
by nickf 1y ago
This. Also, re-evaluate how many places you actually need public trust that the webPKI offers. So many times it isn't needed, and you make problems for yourself by assuming it does. I have horror stories I can't fully disclose,
63.
by nickf 1y ago
I've said it up-thread, but never ever never never pin to anything public. Don't do it. It's bad. You, and even the CA have no control over the certificates and cannot rely on them remaining in any way constant. Don't do
64.
by nickf 1y ago
Certificate pinning to public roots or CAs is bad . Do not do it. You have no control over the CA or roots, and in many cases neither does the CA - they may have to change based on what trust-store operators say. Pinning to public CAs or r
65.
by nickf 1y ago
'Most likely' - with the exception of Apple enforcing 825-day maximum for private/internal CAs, this change isn't going to affect those internal certificates.
66.
SSL certificate validity reduction – CABF vote almost certain to pass
2 points by nickf 1y ago|0 comments
67.
by nickf 2y ago
Curious as to why it’s that many inserts? The whole CT ecosystem has about 30-40,000 new certs/precerts a minute IIRC). Love merkelmap though!
68.
by nickf 2y ago
No, SSLCorp are hosting and managing a CA with Entrust branding. Same as Sectigo are doing. Entrust aren't doing issuance, verification - they're straight reselling from white-labeled issuing CAs.
69.
by nickf 2y ago
Just to be clear, the whole incident covered over 80,000 certificates. The TRO was applicable to only those of one subscriber - just over 70 certificates, yet caused the revocations of all 80k+ to be delayed.
70.
by nickf 2y ago
Perhaps, but only in the case that the delayed revocations were scoped to those certificates covered by the TRO, and not over 1000x more from subscribers who had nothing to do with the company who filed the TRO.
71.
by nickf 2y ago
Nothing public to point to, sorry. Sub-CAs: Not really. Operational risk to the parent CA is huge, you'd be hard pressed to get any current public CA to sign an issuing CA to be operated externally. Cross-signing still works (though it
72.
by nickf 2y ago
The parent was correct - it's not about the company not using x509 certificates, but not using publicly trusted certificates. There are myriad private/internal PKI solutions available from OpenSSL & bash to millions of dolla
73.
by nickf 2y ago
No, Sectigo is the PKI business that was carved out of Comodo, back in 2017. Comodo still exists, doing whatever they do. They have been totally separate entities since then.
74.
by nickf 2y ago
Time and money. Plus right now even if you bought the infra, the staff, paid for and passed the audits, and then waiting while Apple, Mozilla, Google and Oracle (at least) included your roots...Microsoft aren't taking more right now. S
75.
by nickf 2y ago
Probably 47 days mandatory maximum, hopefully by 2029.
76.
by nickf 2y ago
EV codesigning has been gone for almost a year now. MS said it no longer makes a difference.
77.
Sectigo Acquires Entrust's Public Certificate Business(sectigo.com)
2 points by nickf 2y ago|0 comments
78.
by nickf 2y ago
Server certs will be losing the clientAuth EKU this year, so those will be out. SMIME certs may start to drop it too. I don’t know many CAs that will do a clientAuth only cert from a public CA, largely because it’s unnecessary. If it’s for
79.
by nickf 2y ago
Opera do. Cisco have their own. Oracle do (for Java, primarily) but tend not to participate in CA/B Forum much. Brave did previously have something of a root program - not sure if they still do or if they track Moz and/or Chromium
80.
by nickf 2y ago
Do not pin to publicly-trusted certificates. It is a bad, bad idea. The roots, CAs and even the keys you might pin to are not within your control and can change with little or no notice. Certificate lifetimes are being driven down, too. Don
81.
by nickf 2y ago
The domain verification process is indeed a weak point - but there's now the upcoming introduction of MPIC (Multi Perspective Issuance Corroboration) to help with that (essentially checking the domain challenges from multiple network p
82.
by nickf 2y ago
I'm not sure how you think certificates work? It's not for 'yourself' - the certificate is an assertion to billions of users worldwide, called relying parties. If you don't care about those, then you can use a priva
83.
WebPKI – Introduce Schedule of Reducing Validity (Of TLS Server Certificates)(github.com)
7 points by nickf 2y ago|2 comments
84.
by nickf 2y ago
A phased approach to reducing the validity of TLS server certificates over the next two or three years, ending at a 45-day certificate lifetime by early 2027.
85.
by nickf 2y ago
I think part of the issue could be with the naming - 'public PKI'. I'd argue that doesn't really exist anymore - the nomenclature in use for some time now is 'web PKI'. It's now ostensibly an ecosystem for
86.
by nickf 2y ago
They have almost 300 in the affected list from DigiCert, so who knows?!
87.
by nickf 2y ago
90 day certificates will be here soon, and moving to shorter lifetimes from there.
88.
by nickf 2y ago
PSL has a couple of sections - ICANN and PRIVATE. PRIVATE can be a little more flexible/ignorable. If they implement a hard rule, then occasionally they'd have to make exceptions when the real Dyn comes along and wants (legitima
89.
by nickf 2y ago
Like SMTP/IMAP etc? That would make sense, though I'm not sure how much revocation checking even happens there.
90.
by nickf 2y ago
You could start with this: https://crt.sh/ocsp-responders

More ›