Xavier de Carné de Carnavalet

Ph.D. student in Information and Systems Engineering

Concordia Institute for Information Systems Engineering

Faculty of Engineering & Computer Science

Root Agency, the trusted dummy root certificate

We describe below a trust issue in two content filtering products that trust the dummy Root Agency certificate as part of their TLS proxy, exposing users to trivial man-in-the-middle attacks on HTTPS traffic.
To test if your connection is filtered by a product that trusts the Root Agency certificate (or simply does not perform any validation), go to:

If you do not see a browser warning, you are vulnerable.
Caveats: SNI required, otherwise you will land on our lab's website. Also, seeing a browser warning may simply mean the domain was not filtered, e.g., Untangle only filters under certain conditions. You may still be vulnerable on specific domains or if certificates contain specific keywords. This test does not cover such configuration. If you are an administrator, make sure to enable filtering of all domains in your proxy/firewall before accessing the URL above to avoid false negatives.

Affected products: Net Nanny, Untangle NG Firewall, and more?

Net Nanny is a popular parental control application to restrict and filter bad content from webpages visited by children. Tested versions include, and, but earlier versions could also be affected. Untangle NG Firewall is a network appliance to control and filter traffic in enterprise networks. Both are content filters. Tested versions include 13.0 and 13.2. Version 14.10 is no longer vulnerable. Given the repeated mistake in these two separate products, we have reasons to believe other products may share the same design flaw. Hence, we provide a test website (above) to help end users and administrators verify if they are affected by this type of vulnerability.

Proxying TLS traffic

As the web traffic is now mostly carried in encrypted form (HTTPS), it makes sense for content filters to try to look into TLS traffic. Unfortunately, the HTTPS/TLS protocol has been specifically designed to prevent such interception. Therefore, Net Nanny and Untangle (among many others) both need to "break" TLS to proxy its plaintext content after filtering. These products need at least to verify the server certificates of requested websites against a list of trusted Certificate Authorities (CAs). When relying on the OS trust store, all is good; however, Net Nanny and Untangle build their own custom trust store that contains unsafe certificates.

Root Agency

Microsoft provides the makecert.exe certificate management tool as part of its Windows SDK. By default, when creating a new leaf certificate, makecert chains it to a dummy root certificate called Root Agency. While this root certificate is not trusted by the OS or any browser, it is included in the Intermediate Certification Authorities store in every copy of Windows. The root certificate is valid since 1996, meaning it has probably been there since Windows 95 or 98. It was also generated with then-current standards and simply carry a 512-bit RSA public key. The corresponding private key can simply be retrieved from any version of makecert.exe in the PVK resource.

Root Agency trusted by Net Nanny and Untangle

When building their own trust store, it appears that Net Nanny (for Windows) and Untangle include certificates found not only in the OS trust store (a.k.a. Trusted Root Certification Authorities) and the Mozilla CA store, but also in Windows' Intermediate CA store. Directly trusting intermediate CA certificates is OK when such certificates are indeed issued by trusted root CAs (by transitivity). However, this is not what the Intermediate CA store is about. In particular, certificates found in this store might not be "intermediate" in the first place, but actual "roots", e.g., Root Agency. Now, if Net Nanny and Untangle rejected any certificate chain that contains weak RSA keys, any Root Agency-issued certificates would be stopped due to the 512-bit RSA key size. However, they do not reject such certificates. Worse, since the certificates issued on-the-fly by the proxy for requested domains do not reflect the actual certificate chain, the browser does not know about the weak key size and accepts the proxy certificate.

The attack

The vulnerabilities allow an attacker to conduct man-in-the-middle attacks on encrypted HTTPS traffic without triggering browser warnings. To do so, the attacker:
  1. Obtains a copy of makecert.exe as part of the Microsoft Windows SDK
  2. Extracts the private key for the Root Agency certificate (located in a resource, easy and one-time effort)
  3. Targets a victim that uses Net Nanny on a Windows computer or Untangle NG Firewall, and intercepts its network traffic
  4. Intercepts TLS connections and provides certificates signed by Root Agency's private key retrieved in point #2.

Vendor contact timeline

Vulnerability found in Net Nanny, PoC works
Contacted support@netnanny.com about a RSA-512 trusted root certificate
Response from Net Nanny's VP Development:
"The Net Nanny CA store is created by importing from the browsers/stores we detect. That is, Windows/IE, Mozilla, Android, and Apple/Safari stores. Additionally, we ship a list of CA's that matches Mozilla's CA's (since they use their own store). It is kept up to date with every release, however, we do not update the store again until the next release/update. It would be possible to update the store more frequently via a definition update. An enhancement request to do that has been entered into our system."
Paper presented at NDSS
Retested current version, Net Nanny is still vulnerable
Vulnerability found in Untangle NG Firewall, PoC by me, tested by Louis Waked
L. Waked contacted Untangle, automatic reply only
Paper presented at AsiaCCS by L. Waked
Contacted CMU CERT about Net Nanny
CERT "decided not to handle the case" as they "generally do not accept reports of issues that have already been publicly disclosed."
Tested Untangle 14.10, no longer vulnerable
Listed both common problems here
This document has been last modified on Wednesday January 02, 2019

Valid XHTML 1.0 Strict Valid CSS!