Categories: CA Program Security

Revoking Trust in one ANSSI Certificate

Last week, Mozilla was notified that an intermediate certificate, which chains up to a root included in Mozilla’s root store, was loaded into a man-in-the-middle (MITM) traffic management device. It was then used, during the process of inspecting traffic, to generate certificates for domains the device owner does not legitimately own or control. While this is not a Firefox-specific issue, to protect our users we are a updating the certificate store of Firefox in order to dis-trust these certificates. The Certificate Authority (CA) has told us that this action was not permitted by their policies and practices, and they have revoked the intermediate certificate that signed the certificate for the traffic management device.


ANSSI (Agence nationale de la sécurité des systèmes d’information) is the French Network and Information Security Agency, a part of the French Government. ANSSI (formerly known as DCSSI) operates the “IGC/A” root certificate that is included in NSS, and issues certificates for French Government websites that are used by the general public. The root certificate has an Issuer field with “O = PM/SGDN”, “OU = DCSSI”, and “CN = IGC/A”.

A subordinate CA of ANSSI issued an intermediate certificate that they installed on a network monitoring device, which enabled the device to act as a MITM of domains or websites that the certificate holder did not own or control. Mozilla’s CA Certificate Policy prohibits certificates from being used in this manner when they chain up to a root certificate in Mozilla’s CA program.


An intermediate certificate that is used for MITM allows the holder of the certificate to decrypt and monitor communication within their network between the user and any website without browser warnings being triggered. An attacker armed with a fraudulent SSL certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. Such certificates could deceive users into trusting websites appearing to originate from the domain owners, but actually containing malicious content or software.

We believe that this MITM instance was limited to the subordinate CA’s internal network.


Mozilla is actively revoking trust of the subordinate CA certificate that was mis-used to generate the certificate used by the network appliance. This change will be released to all supported versions of Firefox in the updates this week.

Additional action regarding this CA will be discussed in the forum.

End-user Action

We recommend that all users upgrade to the latest version of Firefox. Firefox 26 and Firefox 24 ESR both contain the fix for this issue, and will be released this week.


Thanks to Google for reporting this issue to us.

Kathleen Wilson
Module Owner of Mozilla’s CA Certificates Module

16 comments on “Revoking Trust in one ANSSI Certificate”

  1. Nate wrote on

    Thank you for the update. Is this certificate revoked using OCSP? And if so, why does it also need to be actively revoked in Firefox?

    1. Kathleen Wilson wrote on

      No, this CA does not yet support OCSP.

  2. redwolfe_98 wrote on

    in earlier cases involving compromised certificates, the compromised certificates were added to a list of untrusted certificates, listed under “servers” when you are viewing the certificates, in FF’s “certificate manager”, but lately, compromised certificates have not been added to the list of untrusted certificates, which concerns me..

    here is one example where there were some compromised certificates which were not added to FF’s list of untrusted certificates:

    i believe that there are several other examples, where compromised certificates were not added to the list of untrusted certificates in FF’s “certificate manager”.. if mozilla wants to find them, just scan through MS’s advisories, regarding compromised certificates.. (i frequently check MS’s advisories in order to be informed about vulnerabilities)..

    1. Daniel Veditz wrote on

      Our advisory for the TURKTRUST incident can be found at

      We also revoked those certificates.

  3. Gervase Markham wrote on

    The certificate which was revoked did not contain an OCSP URL or a CRL URL, and so cannot be revoked by those means in normal usage patterns. However, even if it did, we currently also do Firefox updates to revoke intermediate certificates which have been mis-issued. In the future, we may have other mechanisms.


  4. Paul Léo Steinberg wrote on

    Why are you not removing the “IGC/A” root certificate completely from NSS? The issuing of the malicious intermediate certificate was only reported by ANSSI after Google discovered it. This proves that ANSII is not able to enforce their own certificate policies and thus should not be trusted to operate any CA.

    1. Daniel Veditz wrote on

      Revoking the root is a big step, destructive enough that you don’t want to make a mistake. Killing the rogue intermediate is a no-brainer and could be done immediately while we have a discussion of what to do about governmental Certificate Authorities. There’s a lively discussion about revoking the ANSSI root on our security policy list/newsgroup

  5. redwolfe_98 wrote on

    i believe that mozilla has been failing to add compromised and untrusted certificates to the list of untrusted certificates, in “firefox”.. the most recent example involved some “turktrust” certificates.. i believe that there are several others that should have been added to the list of untrusted certificates but weren’t added to the list.. for a reference, look at the “advisories” at the microsoft website in regard to compromised and untrusted certificates..

    i would post links to the MS-advisories but then my post would be rejected on the grounds that it was “spam”, since i included a link in my post..

    1. Daniel Veditz wrote on

      Your belief is wrong. We revoked the TURKTRUST certs last year at the same time Microsoft did. I went through the last several years of Microsoft advisories about certs and we have blocked all the ones they did apart from their own Microsoft-issued intermediates which were never trusted under our root list in the first place.

      1. redwolfe_98 wrote on

        daniel, i think you are misunderstanding what i am saying.. i am aware that mozilla says that they address these issues with compromised-and-untrusted certificates.. my point is that the compromised-and-untrusted certficates are not showing in the list of untrusted certificates, in FF’s “certificate manager”.. if you look, there, you can see that there are many certificates listed there, in the list of untrusted certificates, under “servers”, but, for the past year, or two, or three, mozilla has not been adding untrusted certificates to the list of untrusted certificates (which can be viewed in FF’s “certificate manager” ), at least they are not showing in the list of untrusted certificates.. all that you have to do is look at the list of untrusted certificates, in FF’s “certificate manager”, to see that the untrusted “turktrust” certificates are not listed there, and neither is the “DG Trésor” certificate, the subject of this blog-post..

        as i said, it concerns me when these untrusted certificates are not added to the list of untrusted certificates (which can be viewed in FF’s “certificate manager” )..

        here is a link to a screenshot of the list of untrusted certificates, in FF’s “certificate manager”, to possibly help you to understand what i am talking about:

        note that no “turktrust” certificates are listed there, in the list of untrusted certificates..

        you also could compare FF’s list of untrusted certificates (though no new ones have been added, in the last few years) with IE’s list of untrusted certificates..

        1. Daniel Veditz wrote on

          This is a failure of the user interface, thank you for pointing it out. If you read the source (doesn’t everyone?) you will see the entries for these certs, but it would be better to surface this information for concerned users. One problem is that these distrusted certs have been shoe-horned into a section of the UI that was intended to show the override certs the user has created, so now the list will potentially show certs that are fraudulent and will never work (built-in) and broken/mismatched certs that the user has forced to work.

          I filed a bug on this issue

    2. Daniel Veditz wrote on

      And also we don’t reject links outright so please link away if it’s relevant. They may trigger moderation but if they aren’t actual spam a human will let them through. The web is made of links.

  6. Alexandre Terrat wrote on

    Certains n’auront pas attendu l’intervention des médias à ce sujet.
    Déplorable et douteux dans la mesure ou l’ ANSSI et leur “troupes” disposent largement des moyens techniques pour parer , du moins anticiper ce type de “dysfonctionnement” de surcroît dans la mesure où cela remet en cause l’intégrité des données confidentielles de leur propre Rs In et des citoyens .
    On concluera ainsi : Errare humanum est . ( histoire d’être sympathique )

    Merci à la communité Mozilla / Gg / 어나니머스(Anonymous) (North Korea)

  7. Jamie wrote on

    My firefox used to have certificate error sometimes when i connect to ssh proxy, it just won’t let me to visit any website..

  8. yoho wrote on

    I understand the problem for users privacy but what would be the solution for https content inspection devices if they can’t use such ‘impersonating’ certificates ?

  9. Kathleen Wilson wrote on

    Such ‘impersonating’ certificates should not chain up to a root certificate in Mozilla’s CA program (i.e. a root certificate included in NSS). People needing such inspection devices can create their own self-signed root cert and import it into the systems within their network.