111–120 of 154 posts
Earlier quoted context omitted.
it’s more like blue m&m’s than an actual requirement
>it’s more like blue m&m’s than an actual requirement Did you mean Van Halen's famous "WARNING: ABSOLUTELY NO BROWN M&Ms" clause? https://www.snopes.com/fact-check/brown-out/
Are we going to experience the same bug next year for all LetsEncrypt certificates when the DST Root CA X3 expires? I guess modern devices could deal with LetsEncrypt issuing directly from their own modern ISRG Root X1, but would that leave legacy clients completely stranded (iOS <10, older versions of Windows and Android...?)
Earlier quoted context omitted.
Sounds like a good test case for exercising those otherwise useless "million dollar insurances" that some certificate vendors flash in their sales materials?
Have you ever read the terms? I don't know if they even publish them anymore, but I read one many years ago. TLDR; 1. The CA must misissue a cert. 2. The misissued cert is used by a malicious party to impersonate you. 3. Every user (your users) must prove their damages and claim individually. 4. There might have been a low maximum, per-user claim, but I can't remember. I'd be amazed if there's a single person on the…
†This is the root of a huge scandal in the UK that resulted in banks refunding people years of fees for a product called PPI which they should never have been sold. As a secondary effect this resulted in annoying spam from firms who'd help you claim your money back. By the end I almost felt sad I hadn't fallen for the original scam, because I was being inconvenienced by all the spam but (since I hadn't lost anything) not getting a pile of cash as a refund.
DataDog failed this morning because of root CA issue.[0] Was a fun Saturday morning with 5000 alarms blowing up my phone. [0] https://status.datadoghq.com/incidents/6bqpd511nj4h
Datadog has shit the bed for us multiple times in the last six months. Unannounced breaking API changes, unaddressed bugs, and now their embedded cert expired. Our org is currently divided over further commitment to the service, or leaving them entirely. They've made it very hard to argue in their favor.
Are we going to experience the same bug next year for all LetsEncrypt certificates when the DST Root CA X3 expires? I guess modern devices could deal with LetsEncrypt issuing directly from their own modern ISRG Root X1, but would that leave legacy clients completely stranded (iOS <10, older versions of Windows and Android...?)
The first thing that'll happen is Let's Encrypt's systems will tell systems by default to present certificate chains which don't mention DST Root CA X3. Lots of systems will, as a result, automatically switch to such a chain when renewing and you'll see a gentle trickle of weird bugs over ~90 days starting this summer unless Let's Encrypt moves the date.
Those bugs will be from clients that somehow in 2020 both didn't trust the ISRG root and couldn't imagine their way to using a different trust path not presented by the server. Somebody more expert in crap certificate verification software can probably tell you exactly which programs will fail and how.
Then there will be months of peace in which seemingly everything is now fine.
Then in September 2021 the other shoe drops. Clients that didn't trust ISRG but had managed to cobble together their own trust path to DST Root CA X3 now notice it has expired on services which present a modern chain or no chain at all.
Those sites which deliberately used the legacy DST Root CA X3 chain to buy a few more months of compatibility likewise see errors, but hopefully they at least knew this was coming and are expecting it.
But there are also sites using crappy ACME clients that didn't obey the spec. They've hard coded DST Root CA X3 not because they wanted compatibility at all costs and are prepared for it to end in September, but because they just pasted together whatever seemed to work without obeying the ACME spec and so even though Let's Encrypt's servers have told them not to use that old certificate chain they aren't listening. Those services now mysteriously break too, even in some relatively modern clients that would trust ISRG, because the service is presenting a chain that insists on DSR Root CA X3 and they aren't smart enough to ignore that.
On the upside, lots of Let's Encrypt certs are just to make somebody's web site work, and an ordinary modern web browser has been battle-tested against this crap for years, so it will soldier on.
Earlier quoted context omitted.
Is that a cURL bug?
It seems only to be older versions of curl or curl with openssl <= 1.1.1. My macbook's curl fails, but my arch linux box's curl works fine.
Earlier quoted context omitted.
Because the certificate authority paradigm is LITERALLY INSANE.
It’s the PKI paradigm that creates most of the insanity. Authentication is still an unsolved issue with PKI, there’s many ways that you can perform authentication, but all of the different approaches lead to one form of insanity or another. The CA system has its share of insanity, but it is the most successful PKI implementation in history, and by a long way.
This one bit me today and abruptly ended my day at the beach. The certificate reseller advised my customer that it was okay to include the cross-signing cert in the chain, because browsers will automatically ignore it once it expires, and use the Comodo CA root instead. And that was true for browsers I guess. But my customer also has about 100 machines in the field that use cURL to access their HTTPS API endpoint. cU…
HTTP clients in programming languages are not as smart as web browsers when it comes to verifying SSL certificate chains. For example, if the chain presented by the server is missing intermediate certificates, modern web browsers are able to fetch those intermediate certificates without issue. Most HTTP clients do not do that though, and instead will throw a cryptic error, something along the lines of "unable to get…
Let me know if I can help with more info.
Earlier quoted context omitted.
That's what my browser shows me too, but it's just because it's ignoring the cross-signed one that chains to AAA. The server is sending it, per InCommon's setup instructions.
That's correct The old TLS (versions 1.0, 1.1, 1.2) specifications said that the certificates supplied are to form a chain, starting from a leaf and leading back towards a root. Pretty much all clients assume that once they can see a way to a root they trust they'll give up following the provided chain and trust that - but sadly not all of them, so "over-specifying" the chain can cause problems. Modern clients tend t…
All the clients were limited to SHA-1 have already been forced off https; CAs in the CA/Browser forum weren't permitted to issue SHA-1 certs valid past Jan 1 2017, and you had to have gotten those issued before Jan 1 2016. Browsers were showing warnings on SHA-1 certs depending on expiration throughout 2015, so you had to either put up with a warning (and the customer service burden thereof), ditch your old clients and go sha-2 only, segregate traffic, or build custom software to send sha-1 certs to some people and sha-2 certs to others.
Microsoft added support for sha-2 certs in the OS system stack with XP Service Pack 3, released in 2008, and Microsoft was always pretty slow with support on things, other platforms may have supported this earlier. A CA bundle from like 2005-2008 is going to be fairly limiting today. A lot of CAs back then had a 20 year validity period, which may have started 5-10 years before the bundle date. Of course, a lot of bundles today end in 2038, so we'll be screwed then.