Mozilla Security Blog
Categories: CA Program Firefox Security

Message to Certificate Authorities about Subordinate CAs

Johnathan Nightingale

12 responses

Earlier today we sent an email to all certificate authorities in the Mozilla root program to clarify our expectations around certificate issuance. In particular, we made it clear that the issuance of subordinate CA certificates for the purposes of SSL man-in-the-middle interception or traffic management is unacceptable. We made it clear that this practice remains unacceptable even when the intended deployment of such a certificate is restricted to a closed network.

In addition to this clarification, we have made several requests. We have requested that any such certificates be revoked, and their HSMs destroyed. We have requested the serial numbers of those certificates and fingerprints of their signing roots so that we, and other relying parties, can detect and distrust these subCA certificates if encountered. We have requested that any CAs who have issued subCA certificates fulfill these requests no later than April 27, 2012.

Finally, we re-iterated our belief that each root is ultimately accountable for every certificate it signs, directly or through its subordinates. Participation in Mozilla’s root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe, up to and including the removal of root certificates that mis-issue, as well as any roots that cross-sign them. Nevertheless, we believe that security is best served when browsers and CAs can work together; we hope that frank communication and clear expectations can resolve these issues before any such action is required. We must also be diligent in looking for new ways to improve the security systems of the web. Those systems are built on the trust of web users, and we all have a responsibility to be strong stewards of that trust.

Johnathan Nightingale
Senior Director of Firefox Engineering

12 comments on “Message to Certificate Authorities about Subordinate CAs”

  1. Ivan wrote on

    Thank you for taking care of your users.

  2. Geoff wrote on

    Well it’s about time Mozilla came out in favour of their users, instead of the mysterious and shady network that is their trusted CAs.

  3. foo wrote on

    Why is the CNNIC cert still in Mozilla then?

    http://www.imminentweb.com/technologies/remove-cnnic-ca

  4. me wrote on

    Nice words, but why haven’t you revoked the untrustworthy CA right away?

    Promising not to do it again is not a basis for trust.

  5. Rich Jones wrote on

    This is an applaudable stance for Mozilla to take. Let’s hope they listen.

  6. Benjamin Franz wrote on

    Because this is designed to keep the CAs from going into ‘hide what we already did’ mode. It’s an amnesty program for the CAs designed to purge the system of any already existing subordinate CAs.

    It is a smart move.

    It gives the CAs a way to ‘come clean’ without punishing them for doing the right thing. It is a ‘carrot and stick’ approach: Come clean **now** and we will not kill your CA business. Don’t come clean now and we will be merciless if and when we catch you.

  7. you wrote on

    @me: The problem here is, of course, that everyone is also interested in CAs revealing the truth. If their root certificates are always revoked then their business is destroyed which already is the worst that can happen. So it would not be rational for them to report security breaches at all. So revocation should only happen when CAs get cought.

  8. Iang (on why the jaws of trust just snapped shut) wrote on

    @you and @me – yeah it’s a difficult problem. I would say that rationally trying to encourage CAs to behave simply won’t work. CAs are far better at this game that we are, and have locked up the vendors by many and various ways. The ability of the vendors to police them is very limited.

    In this particular case, the Trustwave MITM subroot was only put in place in 2011, and by the end of that year Trustwave had already had second thoughts (you can see this information on the bugzilla list). So history may judge that this CA scrapes through: only a single instance, over limited timeframe, and they stopped the project and disclosed it. It seems that wiser minds prevailed in the end.

    However many of us believe (for good-ish but unprovable reasons) that there are multiple other instances out there (more than 10?) of subCAs sold for internal traffic monitoring purposes. One of those is going to be caught and the certificate chain revealed.

    The bottom line I think is that, absent both of these:

    + prior open disclosure,
    + already agreed *fast* plan to withdraw these subCAs, with prejudice to the subCA client,

    that root will be terminated forthwith.

  9. Alex Syrnikov wrote on

    Hi, guys. I think this is good. But I have One suggestion. Can you make SSL certifikate chain params avalable from JavaScript? So I can get it and send via AJAX on original server to check that what client in Firefox got is what server sent. In case of mismatch javascript will show warning message that connection is listened by third side.

  10. respondant wrote on

    @you said “…that everyone is also interested in CAs revealing the truth. If their root certificates are always revoked then their business is destroyed which already is the worst that can happen.”

    I would say that the “worst that can happen” is a CA building a business on MITM subroots, even unintentionally. If that has happened at any point in a CA’s history, they have already abrogated their responsibility of being a trusted Certificate Authority. They have already proven that they are not willing to perform due diligence on their own clients, and what their clients do with the subroots that they themselves issued to those shady clients. They’re proving that they don’t audit the trust declarations made by themselves to those they are selling subroots to.

    CAs are in the very business of creating a documented chain of trust between CA, sub root and ultimately web site. When one subroot is used for any kind of MITM, that trust is shattered up and down the chain. In effect their business is already destroyed. If a CA couldn’t do due diligence over the last two years, why should any of us think that they have the capacity or institutional willpower to do the right thing over the next two? Their model is already broken. Really, all a trusted CA has is their good name, and these types of shenanigans sully that name.

    Good riddance to bad CAs, revoke their CA and let their finances go where their ethics already are — utter bankruptcy.

  11. Andy S wrote on

    No need to expose Certificates to JavaScript (but could be done as a piece of cake for some who may want them). The only thing Mozilla (and other browsers) should do: trust only chains with a single CA at the top level. If there’s another CA-level certificate in the chain – block (or expose to the user via alarm-message) it. And require trusty CAs in the world to sign site-level certificates with only CA-level chain root keys.

  12. JimC wrote on

    @Alex Syrnikov : if a MITM is replacing the expected certificates on a connection, it would also be able to replace your JS code. You need to do your checks of security out-of-band, not in-band.