agwa

20 ms·

301.
by agwa 3y ago
Thanks for reading! Indeed, if people take one thing away from this article, it should be that the name in CA certificates is meaningless.
302.
by agwa 3y ago
Remember, "root" and "intermediate" are terms that apply to certificates , not organizations. Let's Encrypt does operate two root certificates which you can see installed in your OS/browser. They also operat
303.
The Difference Between Root Certificate Authorities, Intermediates and Resellers(agwa.name)
94 points by agwa 3y ago|38 comments
304.
by agwa 3y ago
Transparency is not optional - Chrome and Safari don't accept certificates that aren't published in Certificate Transparency logs. Certificate Transparency logs use Merkle Trees so that if they try to hide a certificate, it can be
305.
by agwa 3y ago
DigiCert did not cross-sign Let's Encrypt; Identrust did.
306.
by agwa 3y ago
We definitely don't "just" trust the certificate authorities. Considerable effort is spent monitoring CAs for non-compliance, and CAs which are found untrustworthy are booted.
307.
by agwa 3y ago
Author here. Happy to answer any questions!
308.
by agwa 3y ago
Yup, the two most popular are: https://github.com/zmap/zlint https://github.com/certlint/certlint They each have their strengths and weaknesses, so CAs are advised to use both.
309.
by agwa 3y ago
There is a major distinction between root store policy and CT policy which you are missing. Root store policy contains requirements which are enforced by audits, and if a CA violates the root store policy it is considered misissuance requir
310.
by agwa 3y ago
I was involved in the drafting of that language and you are 100% correct.
311.
by agwa 3y ago
Yeah, the question is how far you want to go. To be safe against every possible CA screwup, you basically have to re-implement every browser's entire certificate validation engine and run certificates through each one. That would obv
312.
by agwa 3y ago
No, it's because the SCTs in the certificate have invalid signatures.
313.
by agwa 3y ago
If your certificate was issued after the start of the incident but before Let's Encrypt suspended issuance, then the certificate is currently not working in Chrome or Safari. This incident wasn't just about downtime, it was also a
314.
by agwa 3y ago
> You wouldn't like it if Firefox did an online check with a central authority for every website you visited Enforcing Certificate Transparency does not require doing an online check for every website you visit. > Mozilla, the
315.
by agwa 3y ago
They "lint" certificates before issuance, as do most CAs. However, I don't think any linters check for this problem, as it requires access to more than just the certificate (the linter would need access to either the precert
316.
by agwa 3y ago
> If applying the algorithm to (1) produced (3), what produced (2)? I believe the root of the problem is that Let's Encrypt is creating certificates and precertificates independently, instead of creating a precertificate and then
317.
by agwa 3y ago
Here's the 7-year-old bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1281469 I don't know why it is taking them so long, but it makes me sad.
318.
by agwa 3y ago
They will indeed need to revoke the affected certificates within 5 days, per the Baseline Requirements. Also, the affected certificates won't be accepted by Certificate Transparency-enforcing browsers (Chrome and Safari) because of the
319.
by agwa 3y ago
The problem is actually WAY more subtle, and pretty hard to understand unless you really get in the weeds of Certificate Transparency and certificate policy, but I'll give a shot at providing a concise explanation. Let's Encrypt h
320.
by agwa 3y ago
This all happened less than 2 hours ago, but a quick summary is that my Certificate Transparency monitor, Cert Spotter ( https://sslmate.com/certspotter ) performs various sanity checks on every certificate that it observes.
321.
by agwa 3y ago
This is because I discovered that Let's Encrypt was issuing non-compliant certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=1838667
322.
by agwa 3y ago
> So the person claiming to be the founder of "QuantumCA" does not possess the private key corresponding to https://crt.sh/?caid=200960 - can we be sure the private key is only accessible by ssl.com's CA
323.
by agwa 3y ago
Quantum is not a trusted CA. ssl.com has a white-labeled intermediate CA with the name "Quantum" in it, but this intermediate CA is operated by ssl.com under all the same controls as ssl.com's other intermediate CAs. Quantu
324.
by agwa 3y ago
The sub CA is operated by ssl.com, not HiCA (which is not a trusted certificate authority). HiCA is relaying the certificate requests to ssl.com, which is properly validating the requests in accordance with all the requirements. ssl.com is
325.
by agwa 3y ago
They aren't in any root programs. They're just taking certificate requests and relaying them to real CAs, which is why they need to exploit an RCE in the ACME client, since the ACME client wouldn't otherwise be able to compl
326.
by agwa 3y ago
There is not currently a good story for non-browser clients. Generally, non-browser clients don't enforce CT, and those that do are at risk of breaking if they don't stay on the ball with changes to the CT ecosystem. Browser make
327.
Spoofing vulnerability in Gmail's BIMI implementation(infosec.exchange)
2 points by agwa 3y ago|0 comments
328.
by agwa 3y ago
> If a CA misissues a cert for something major, like Facebook or Google Mail, and Google or Mozilla find out, my current belief is that they'd be in for a world of hurt. It doesn't even need to be major. Misissuing for example.
329.
by agwa 3y ago
No, ACME allows you to revoke a certificate if you can successfully complete a challenge for every domain in the certificate (see https://www.rfc-editor.org/rfc/rfc8555#section-7.6 "an account that holds authoriza
330.
by agwa 3y ago
2017, but it only started having real value once SCT auditing rolled out in 2022.

More ›