On Thu, 2013-01-24 at 10:40 +0100, Jan Lühr wrote: > > I noticed that my firefox installation included a wildcard > certificate issued by Entrust.net (attached (*)). I'm not clear how it > got there but wildcard certs make me suspicious by nature. Can you help > me out? > Apparently it got stripped. I put it online at > http://jluehr.de/DigisignServerID-(Enrich)-wildcard.pem
Hello Jan, I've changed the subject to clarify what this is about. First, let me point you to the background related to that certificate: https://blog.mozilla.org/security/2011/11/03/revoking-trust-in-digicert-sdn-bhd-intermediate-certificate-authority/ Next, let me explain how this certificate works. It is what I call a "knockout certificate", or which could also be described as a "blacklist certificate". The certificate is included in Firefox/NSS together with a special distrust record, which tells the software to not trust this certificate when seen - and not to trust any subordinary certificates that is has signed. If you view this certificate in Firefox (click the view button), you should get a message that it cannot be verified. If you click the edit trust button in certificate manager, it should tell you that it is not trusted. That means, the certificate is there to protect you. If you ever visit a website that uses one of the weak or compromised certs related to that blacklisted CA certificate, Firefox will not trust it, but reject it (Firefox will show you an error page explaining that the website's certificate is not trustworthy). The above should answer your question, let me know if it's not clear. But in addition I would like to use the opportunity to write some general technical explanations about the way we blacklistd certificates in the past and today. At the time we had to work on the above incident (in November 2011), our NSS code wasn't yet capable of simply blacklisting a certificate. We had to use a workaround. We (the NSS developers) manually created knockout certificates that look very similar to the ones that we wanted to blacklist. We created them to contain the same subject name and issuer name as the ones we wanted to blacklist. But as a difference, we set the validity period to a more recent date. Of course that certificate didn't contain a valid signature, but that didn't matter. At the time the NSS software tries to verify a certificate, it will see both the original (intermediate) CA certificate (the one that we wanted to blacklist but technically couldn't) and it will also see our specially crafted certificate with the newer timestamps - and given the choice, NSS will make use of the newer one, which has the explicit negative trust associated to it. Using this trick, we have been knocking out several certificates, related to several incidents. Unfortunately that resulted in the user visible certificates, such as the one you saw. Also, unfortunately, the user interface for certificate management in Firefox isn't really prepared to deal with such certificates, and doesn't clearly explain what kind of certificates they are. Unfortunately there havn't been sufficient resources to get this user interface into a better shape. An unfinished attempt can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=733716 This set of certificates that I have mentioned, it even includes a website certificate for my own server, kuix.de, which hasn't been part of an attack. Rather, when we had to deal with the first incident of that kind, we had asked a CA to please issue a certificate for the kuix.de server for testing purposes, which had allowed us to test whether our knockout code worked correctly. I hope that future users wondering about such certificates, or in particular, why a kuix.de certificate is shipped with Firefox, will find this explanation text when searching the web for it. As positive news, for future incidents, we should no longer require to create such specially crafted knockout certificates. In newer versions of Firefox (those that use NSS 3.13.2 or newer and have bug 727204 and bug 470994 fixed), we are able to blacklist certificates simply by including a suitable distrust record. As a positive side effect, users will no longer see entries in the certificate manager user interface for them. We used that approach for the recent incident related to the Turktrust CA. https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/ I would like to see improvements to certificate manager that clearly distinguished those knockout certificates from other entries. I would like to see improvements to certificate manager that show the user the list of distrust records that we have included, and which are currently not end user visible. Hopefully eventually someone will be able to make such work a priority. Regards Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
