So, can I ask an awkward question? Realistically speaking, is there <i>any</i> chance that a large CA would ever actually be removed from Mozilla's store, no matter how severe their malfeasance?<p>I started wondering this after they declined to remove StartSSL after the Heartbleed fiasco, and while I sort of understood the reasoning there in isolation, between that incident and this long list of WoSign violations, I'm really getting the sense that CA's are "too big to fail" and that the downsides of suddenly breaking huge parts of the internet on unsuspecting users mean that the threat of removing badly-behaving CA's is an empty one. What would a CA have to do to <i>actually</i> be removed, especially if they were to sign really huge sites?
Does anyone know if it's possible to write a Firefox add-on that could warn you that the site you're connecting to uses one of these less trustworthy or esoteric CAs? I've looked through the APIs, but I don't see any hooks for that kind of info.<p>EDIT: Now that I think about it, it must be possible, Certificate Patrol is looking at the cert info, I'll see how they do it.
I'm starting to think that a service such as SSL Labs should also grade CAs (perhaps by looking through Certificate Transparency logs as well, once all CAs have to use them).<p>Then if you use like a "C-rated" CA, your HTTPS score is also limited to B. A B-rate CA would limit your HTTPS score to A, and only an A-rated CA would allow you to get A+ on SSLabs. Something along those lines.<p>I imagine rating the CAs would be quite a complex task, but they could start with the big ones first that own 80-90% of the market.
> For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it.<p>Now that's odd, because I know those two domains. I've even requested some certificates for them myself before (never had anything odd - I think I would've noticed if there was a way to add a domain without validation), but I left the company in January 2015.<p>It was my coworker requesting that certificate, and I've just found - still have the access to the servers as I help them with small issues on rare occasions - that at the same date it was issued (Feb 26, 2015) he had most certainly got a validation file (idisk.su.html) and put it into idisk.su's static root.<p>Webserver logs are, of course, long gone so can't really tell if it was actually accessed or not, but I think when I had requested certificates myself it was a wizard-style process where one got a file to download and the only next action was to validate it, no other way to proceed.<p>I mean, at least he got the file and put it there, in a proper place. And it's also weird that the certificate in question (<a href="https://crt.sh/?id=29805560" rel="nofollow">https://crt.sh/?id=29805560</a>) had included another idisk.su subdomain (mail.idisk.su) that wasn't marked as not validated in the report (<a href="https://www.wosign.com/report/wosign_incidents_report_09042016.pdf;" rel="nofollow">https://www.wosign.com/report/wosign_incidents_report_090420...</a> page 13).<p>I don't doubt there was a severe bug. But this leaves me wondering whenever the analysis followed was really accurate (not saying it wasn't, but still sort of curious that it could be).
Where WoSign have demonstrated glaring incompetence and utter ignorance of security practices as an CA, I doubt these issues aren't violated at quite a few dozens of other CAs. These are good lessons for other CAs.<p>To me, the ultimate question is this: if we are trusting CAs as the 3rd party entity in order to make PKI schemes work, then who's going to be auditing the "supposedly trustworthy" party?
While I've seen some scripts to "blackhole" so-called bad/suspicious CAs, I have yet to find something that cleans things across the board for different browsers.<p>Apple's implementation of "Rootless" while useful for other things hasn't helped by denying the ability to remove certs unless one reboots into recovery and does "csrutil disable".