![]() You can see here that Censys provide a list of the most common issuers of certificates along with the number of certificates they've issued. Using their dashboard we can quickly and easily see that Let's Encrypt, Sectigo and DigiCert are listed as the biggest issuing CAs.Īnother awesome resource I will point to is Censys, much more than a CT log search tool, but that's specifically what I'm going to be using today. The first such tool I'm going to look at is Merkle Town, a CT dashboard created and hosted by Cloudflare. These logs are operated by independent companies all over the world and then further companies aggregate all of these feeds together and even make cool dashboards and advanced search features available. ![]() You can read the blog for more details but in short CT is a series of public, auditable logs that contain all certificates issued by all CAs. Today though, we have a very easy way of determining this, Certificate Transparency. You might have to ask every CA what their issuance volume was and then compare them all to each other, hoping they weren't presenting figures in creative ways. That's great and will help us some time into the future, but it won't help us now or in the coming years for all of those legacy clients that aren't going to save us.Ī few years ago that was probably a really hard question to answer. In the case above if the chain that was served would fail on your client then it wouldn't just give up, it'd try alternate chains itself to see if it could solve the problem (more on that in Part 3!). A modern client like that will not only look at the chain that was served, it would look at alternate trust paths if necessary too. If you're reading this blog post on a relatively modern browser, let's say anything mainstream from the last few years, your client would likely have never choked on this particular issue. This means there is a much better chance that those legacy clients have it and installed and as a result it will work. The reason the second chain is more friendly to legacy clients is that the ultimate Root CA it anchors on is 10 years older and as a result has been trusted and distributed for much longer. USERTrust RSA Certification Authority (Intermediate) Validity to Or this one, which could be delivered for legacy client support: USERTrust RSA Certification Authority (Root) Validity to Sectigo RSA Domain Validation Secure Server CA (Intermediate) Validity to The chains that sites could build would be this one, which is a normal chain without legacy client considerations: Very similar again to the BBC incident, sites and services were serving a specially crafted certificate chain to anchor on this older Root CA for backwards compatibility in old clients. ![]() This was a widely trusted and distributed Root CA that expired just a few days ago at the time of writing and that expiration is what caused issues. The problem certificate was this one:ĪddTrust External CA Root (Root) Validity to Very similar to the problem the BBC had that I mentioned in Part 1, the issue could be solved on either the server with some certificate chain magic or on the client with an update. I still intend to do that but I also want to go deeper into the issue of what happened in the AddTrust expiry incident and hopefully give organisations more insight into how they may foresee and prevent similar incidents in the future. After many hours of laborious work I realised just how difficult that was going to be to complete. Likewise, when I started writing this post after breaking it out, it was meant to be a look at the largest CAs out there and then gathering some insight into when we might see similar problems to those mentioned in the first post. When I started writing the original blog post it didn't have multiple parts and it was never meant to be that long. Now though, I'm going to look at the data available and gauge how big an issue this might be in the years to come. In my previous blog post I looked at the problem of expiring Root CA Certificates and why it exists and you should definitely read that post first.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |