Most common trusted root certificates


With the press coverage lately about governments being able to subvert SSL/TLS by coercing a certificate authority into issuing rogue certificates, I decided to do some data gathering in order to answer a simple question:

How many trusted roots does the average person need in their browser?

To answer the question, I wrote a small tool to collect the root cert for a list of sites and ran it on a sets of data – a mix of known SSL/TLS sites and hosts on the Alexa Top 1 Million list. So out of 350k hosts queried, I was able to collect 50812 entries. The stats are fairly interesting and somewhat expected. The number of certificate authorities that have issued more than 50 certificates for that set of data is 37.

While I was gathering the data, it became known that even Mozilla includes some root certificates that don’t have complete clarity of ownership.

My plan now is to remove most of the CA root certificates that ship in browsers. It will be informative to see what breaks and how many issues I run into. After a month or so of usage, I will post the details and hopefully it will be an easy guide as to the smallest set of trusted CAs to have and not be impacted in daily business. Granted this will be a US centric list, most international users can probably add one or two trusted roots that are for CAs issuing country specific certificates.

What follows is the list of root certificates (also available as text file) sorted with decreasing popularity. The format is “Number of issued certs | Friendly name | Subject”.

7519 | GeoTrust | OU=Equifax Secure Certificate Authority, O=Equifax, C=US
4277 | USERTrust | CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
4007 | Go Daddy Class 2 Certification Authority | OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
3701 | VeriSign Class 3 Public Primary CA | OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
2948 | USERTrust | CN=UTN-USERFirst-Hardware, OU=, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
2649 | thawte |, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, S=Western Cape, C=ZA
2077 |  |, CN=plesk, OU=Plesk, O=Parallels, L=Herndon, S=Virginia, C=US
1898 | Equifax Secure Global eBusiness CA-1 | CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
1806 | VeriSign | OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
1580 |  | E=webaster@localhost, CN=localhost, OU=none, O=none, L=Sometown, S=Someprovince, C=US
1461 |  | E=root@localhost.localdomain, CN=localhost.localdomain, OU=SomeOrganizationalUnit, O=SomeOrganization, L=SomeCity, S=SomeState, C=--
1378 | thawte |, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, S=Western Cape, C=ZA
1366 | VeriSign | CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
1189 |  |, CN=plesk, OU=Plesk, O="SWsoft, Inc.", L=Herndon, S=Virginia, C=US
922 | Entrust | Secure Server Certification Authority, OU=(c) 1999 Limited, incorp. by ref. (limits liab.),, C=US
902 | GlobalSign | CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE
783 | GTE CyberTrust Global Root | CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
737 | CúOúMúOúDúO | CN=COMODO Certification Authority, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
692 |  | E=ca@snakeoil.dom, CN=Snake Oil CA, OU=Certificate Authority, O="Snake Oil, Ltd", L=Snake Town, S=Snake Desert, C=XY
461 | DigiCert | CN=DigiCert High Assurance EV Root CA,, O=DigiCert Inc, C=US
394 | Starfield Class 2 Certification Authority | OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
264 |  |,, O=ispgateway, L=Kempten, S=Bayern, C=DE
257 |  |, CN=plesk, OU=Plesk, O="Parallels, Inc.", L=Herndon, S=Virginia, C=US
208 | Entrust (2048) | Certification Authority (2048), OU=(c) 1999 Limited, incorp. by ref. (limits liab.),
198 | Trustwave | CN=SecureTrust CA, O=SecureTrust Corporation, C=US
168 |  |, CN=*, OU=web, O=lxlabs, L=WA, S=WA, C=IN
143 | thawte | CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
101 |  |, CN=confixx, OU=Confixx, O="SWsoft, Inc.", L=Herndon, S=Virginia, C=US
98 | StartCom Certification Authority | CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
92 |  |, CN=CA Cert Signing Authority, OU=, O=Root CA
87 | USERTrust | CN=UTN - DATACorp SGC, OU=, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
71 | VeriSign | OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US
70 | Starfield Technologies |, CN=, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
64 |  | CN=localhost, OU=For testing purposes only, O=Apache HTTP Server
63 |  |,,,, L=US, S=US, C=US
62 | SECOM Trust Systems CO LTD | OU=Security Communication RootCA1, O=SECOM, C=JP
61 | Network Solutions | CN=Network Solutions Certificate Authority, O=Network Solutions L.L.C., C=US

Tags: , , , , ,

9 Responses to “Most common trusted root certificates”

  1. Allen Kelly Says:

    I’m bookmarking this and looking forward to your results!

    If you’re on twitter, I’d like to follow: @allenkelly

  2. Tweets that mention Most common trusted root certificates | netsekure rng -- Says:

    [...] This post was mentioned on Twitter by Nasko Oskov. Nasko Oskov said: some stats on most common trusted roots [...]

  3. Morgan B. Says:

    Great article. Also looking forward to the results. And I too would like to follow you/this on twitter if possible; @molebu.


  4. F. Fisc Says:

    It would be best not to uncheck the first boxes under VerSign,Inc. Financial institutions did not reinstall the cert.

    I unchecked all other boxes in the Certificate Manager.

    Most web page certs were reinstalled upon request.

    Still working with this.

  5. Nasko Says:

    It is your choice which root certificates to disable and which ones not. Trusted roots don’t get reinstalled in Firefox, they either come with the browser or you add them to the list.

  6. Nelson Bolyard Says:

    So, lots of users are now thinking “One bad apple spoils the whole bunch” and “I never liked the idea of trusting CAs anyway, so I’ll disable them all now”. What most of them fail to consider is: they have no other reasonable basis on which to validate certificates. I know a LOT of people who’ve done this. Here, in descending order of frequency, is what they do to validate their certs after they distrust CAs:

    1) nothing. They blindly trust (“create exception”) for every cert they encounter. Yup, their security sure is better now that they don’t trust CAs!

    2) They look at the names in the certificate, to see if the names are as expected. If they’re going to a site, and the cert they get has a subject name that seems reasonable, and doesn’t say “bad guys” in the issuer name, then they accept it, feeling that they’ve done a good job of authenticating the cert. Of course, every bad guy with two brain cells to rub together will create a cert whose names all look exactly right. Only the key will be wrong. The user never check the key, becuase of course, they have no basis on whcih to do so. They just get a false sense of security. Yup, their security sure is better now that they don’t trust CAs!

    3) They trust the cert, then go look at the site for signs of obvious forgery. We all “know” that forged web sites are full of spelling and grammar errors, right? So, if you accept a cert and the site has no spelling and grammar errors, then it must be authentic, right? Again, any bad guy with half a brain will copy the pages from the victim server verbatim (computers are very good at making accurate copies), so page content can NEVER tell you that the copy you’re reading is authentic!

    I could go on. Now, some users use a service that tells them if the cert they see is the same one that many other users have seen. That may improve the odds slightly in some cases, but doesn’t help at all if the site is a phishing site, e.g. if you go to instead of, it may be that all users in the world who visit see the same server you do, but that doens’t make it citibank!

    So before advising people to disables CAs, or before planning to disable CAs for yourself, answer for yourself this question: what will you do instead to validate the keys in the certs you get that will be HALF as good as trusting what the CAs have already checked?

  7. Nasko Says:

    Let me start with saying that I’m not advising anyone to disable CAs. I am
    simply publishing the results of experiments I ran myself. I’ve also found
    that most people don’t even know how to properly deal with certificates, so
    I wanted to outline how to do it, if one were to go down that route.

    That said, I agree with you that most users don’t need to disable CAs and I
    totally agree that most users will make the wrong decision given a choice.

    Does that mean that we should not try to educate people how things work and
    help the small pool of people that want to understand the inner workings of
    PKI and SSL?

    To answer your direct question, I have made a personal decision of which CAs
    I deem “trusted” and if I get an error for untrusted certificate from a
    site I just don’t proceed.

    This is the reason why I spent 30 days looking at each error to find the
    root certificate in the chain and see which CA it belongs to, which helped
    me ensure I didn’t miss a CA I’ve forgotten about. There are also the list
    of CAs I know that I don’t need to trust. This is my version of minimizing
    the attack surface, which has expanded quite a bit as time has passed by.

  8. Dave Says:

    >So before advising people to disables CAs, or before planning to disable CAs for yourself, answer for
    >yourself this question: what will you do instead to validate the keys in the certs you get that will be
    >HALF as good as trusting what the CAs have already checked?

    So you’re saying that users have no rational basis for trusting (or not trusting) any of the CAs that come hardwired into browsers, so they may as well trust them all? That’s… well, it’s honest, but I wouldn’t have expected to hear it from a browser vendor :-).

  9. Nick Says:

    And your list saves me again!

    (The CA is “O = PM/SGDN”, “OU = DCSSI”, and “CN = IGC/A”, not on your list)

    I’ve been running with your minimal CA list for years now, and it provides some nice peace of mind when headlines like this come up.


Leave a Reply

You must be logged in to post a comment.