Posts Tagged ‘SSL’

How to approach fixing the TLS trust model


TLS is an exciting protocol and its wide deployment makes it even more interesting to work on. It has been said many times that the success of online commerce is due to the success of SSL/TLS and the fact that people felt safe in submitting their credit card information over the Internet. These days a lot of people have been speaking openly about how broken the TLS trust model is because of its reliance on Internet PKI and the Certificate Authorities infrastructure and there is some truth to that. We have seen two cases already where CAs trusted by all browsers have issued fraudulent certificates for high profile sites. Those incidents revealed two key problems in the existing TLS infrastructure today:

  • Any CA can issue a certificate for any web site on the Internet, which I call “certificate binding” problem
  • Revocation checking as deployed is ineffective

To counteract these deficiencies, multiple proposals have either existed or emerged. The most notable two are using DNSSEC for certificate binding and Convergence, which is based on independent system of notaries. While both have merits, I believe both have sufficient problems that will prevent them from being deployed widely, which is required for any successful change.

Using DNSSEC for storing information about the server cert is actually very appealing. The admin is in control of which cert is deployed and controls the DNS zone for the site, so it makes sense to be able to use the DNS zone information to control trust. There is even a working group inside IETF to work on such proposal. The problems with DNSSEC are multiple though, here I list just a few:
  •  It is not as widely deployed yet, but that is being fixed as we speak
  • Client stub resolvers don’t actually verify the DNSSEC signature, rather rely on the DNS server to do the verification. This opens the client to attack, if a man-in-the-middle is between the client and its DNS server.
  • There is non-zero amount of corporate networks, which do not allow DNS resolution of public Internet addresses. In such environments, the clients rely on the proxy to do the public Internet DNS resolution. This will break DNSSEC based approach, as clients don’t have access to the DNS records.
  • DNSSEC is yet another trust hierarchy, which is not much different than the current PKI on the web, just a different instance.

Moxie Marlinspike has the right idea about trust agility and his proposal, which he calls Convergence, has a very good foundation. Where I believe it falls short is the fact that many corporate networks block outgoing traffic to a big portion of the Internet. Unless all notaries are white-listed for communication, traffic to those will be blocked, which will prevent Convergence from working properly. Also, the local caching creates a problem with timely revocation – if a certificate is found to be compromised, then until the cache expires, it will still be treated as a valid one.

My take
I actually don’t want to introduce any new methods of doing certificate validation. My goal is to point out a solution pattern that can be used to make any scheme actually deployable and satisfying most (if not all) cases. There are few basic properties any scheme should have:
  1. All information needed for doing trust verification should be available if connectivity to the server is available
  2. Certificate should be bound to the site, such that there is 1-to-1 mapping between the cert and the site.
  3. A fresh proof of validity must be supplied

There is already existing and deployed, although rather rarely, part of TLS called OCSP stapling. It does something very simple – the TLS server performs the OCSP request, receives the response, and then supplies that response as part of the TLS handshake, the last part being the most crucial. The inclusion of the OCSP response as a TLS message removes all of the network problems that the currently proposed solutions face. As long as the client can get a TLS connection to the server, trust validation data can be retrieved. This brings property 1 to the table. In addition, OCSP responses are short lived, which satisfies property 3 as well. So the only missing piece is the 1-to-1 property.

So, there are two ways the problem can be approached – either bring certificate binding to OCSP somehow, or use any other method to provide certificate binding. The latter can actually be achieved rather easily with minimal changes to clients and servers. RFC 4366, Section 3.6 describes the Certificate Status Request extension, which is the underlying protocol messaging of how OCSP stapling is implemented. The definition of the request message is:

      struct {
          CertificateStatusType status_type;
          select (status_type) {
              case ocsp: OCSPStatusRequest;
          } request;
      } CertificateStatusRequest;

      enum { ocsp(1), (255) } CertificateStatusType;

The structure is extensible allowing for any other type of certificate status to be requested, as long as it is defined. I can easily see this message defining DNSSEC and Convergence as values of CertificateStatusType, then define the appropriate format of the request sent by the client. Conveniently, the response from the server is also very much extensible:

      struct {
          CertificateStatusType status_type;
          select (status_type) {
              case ocsp: OCSPResponse;
          } response;
      } CertificateStatus;

      opaque OCSPResponse<1..2^24-1>;

Currently, the only value defined is for OCSP response, which is treated as opaque value as far as TLS is concerned. Nothing prevents whatever information the above proposals return from being transmitted as opaque data to the client.

Just like Moxie explored in his presentation, using the server to do the work of retrieving trust verification data preserves the privacy of the client. It does put some extra burden on the server to have proper connectivity, but that is much more manageable and totally under the control of the administrator.

It is true that there will have to be change implemented by both clients and servers which that will take time. I fully acknowledge that fact. I do believe though, that using the Certificate Status Request is the most logical piece of infrastructure to use to avoid all possible network related problems and provide an inline, fresh, binding trust verification data from the server to the client.

One thing I have not yet answered to myself is – how do we make any new model to fail safe. Having hard failure and denying the user access has been problem forever, but if we keep on failing unsafe, we will continue chasing the same problem into the future.

So in conclusion, for any solution to fixing the TLS trust model must satisfy the following:
  • Provide timely/fresh revocation information
  • Work in all network connectivity scenarios
  • Preserve the client privacy
Ideally, it will also fail safe :)
Tags: , , , , , , , ,

TLS Client Authentication and Trusted Issuers List


One of the common questions I’ve seen asked lately is related to TLS client authentication, which likely means more people are interested in stronger client authentication. The problem people are hitting is described in KB 933430, where the message the server sends to the client to request client authentication is being trimmed. Let’s look at why this occurs and what are the possible solutions, but first some background.

When TLS server is configured to ask for client authentication, it sends as part of the handshake the TLS CertificateRequest message. The TLS 1.2 RFC defines the message as follows:

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

where the supported_signature_algorithms is addition in the 1.2 version of the TLS protocol. The certificate_authorities part of the message is further defined:

      opaque DistinguishedName<1..2^16-1>;

When the server sends this message, it optionally fills in the certificate_authorities part of the message with a list of distinguished names of acceptable CAs on the server. The main reason for this list is for the server to help the client in narrowing down the set of acceptable certificates to choose from. For example, if the server only accepts certificates issued by the company private CA, there is no need for the client to send a certificate issued by a public CA, as the server won’t trust it. Nothing in the RFC prevents the client from sending any certificate, but it is in the best interest of the client to send appropriate certificate.

On Windows, the way the TLS is implemented, the server picks all the certificates that are present in the “Local Computer” “Trusted Root Certification Authorities” store (or in short the local machine root store). With Windows Server 2008 and later, the default list of trusted authorities is very small as I’ve described in a previous post, so including those distinguished names in the message does not pose a problem. However, if the server has most of the trusted roots installed or has additional root certificates, it is possible for the combined length of the distinguished names to exceed the limit of the TLS record size, which is 2^14 (16384) bytes. The TLS standard supports this, as it breaks messages up into records and a single message can span multiple records – this is called record fragmentation. Windows does not implement this part of the RFC though, so it cannot send messages that are bigger than what a TLS record can hold. In most cases this works just fine, but in this particular instance it is a problem.

Now, what can be done to solve this problem. The are two solutions – either decrease the list of root certificates in the message or do not send that list at all (allowed by the RFC). The former approach is possible, but is more error prone and I wouldn’t recommend it for most people. I would argue that the latter approach is the preferred one, but I always get backlash when I propose this. If one were to think about the original purpose of this message and the way Windows has implemented this, it will be easier to understand why this is better. Remember:

  • the server wants to “help” the client do an informed decision on which certificate to send as its identity
  • Windows sends the contents of the local machine root store as the list

If we take those two factors together, the end result is that the server is not helping *at all* the client to make a good decision.  A few sources – my own research,’s SSL Survey, and the EFF SSL Observatory – point out that 10-15 root CAs issue the majority of the certificates seen on the web, therefore if we send 16k worth of these, the probability that any certificate the client has is *not* issued by someone in the list is close to zero. Therefore, in this configuration, the list the server presents to the client doesn’t effectively filter down the set of certificates on the client. It is almost equivalent to sending an empty list to the client and ask it to chose randomly.

In short, if you are hitting this problem, you are better of using Method 3 described in KB 933430 and setting SendTrustedIssuerList to 0, which disables sending of the list of CAs than any other method.

Tags: , , , , ,

Automatic CA root certificate updates on Windows


I was recently listening to Chris Palmer talking about SSL on the PaulDotCom podcast and one thing caught my attention – the discussion on IE behavior with trusted roots certificates. It was discussed that IE is violating the “No-Write-Up” policy of the integrity level (IL) mechanism in Windows. While the end effect looks like it, the inner workings of how this is accomplished is more complicated and the behavior is not restricted to IE.

Let’s start with some preliminary background information:

  • Certificates are validated through a process of building a chain up to a trust anchor, the underlying of which is constructing a graph of nodes (certificates) and edges (issuance relationships) and then the graph is traversed to find all possible complete chains (in most cases just one). The smaller the graph is, the quicker it is to find a complete chain. Once the chain is complete, the certificate at the root of the chain is checked for trust. If the chain ends in a certificate present in the list of trusted root certificates and all other verifications pass, the certificate validation is successful.
  • Microsoft has a specific program called “Microsoft Root Certificate Program”, which is how certificate authorities (CAs) submit their root certificates for inclusion in Windows. The end result of this program is a *fixed* list of root certificates that Windows considers trusted. The entire list is available on TechNet and is updated whenever there are any changes. This list (or the equivalent of it at the time) was present in full in the root certificate store in Windows XP and earlier, but starting with Vista, this default list in the root certificate store is much smaller in order to increase performance while validating certificates. If a chain ends up in root certificate which is part of the Root Program but is not present in the list of trusted roots currently on the machine, Windows downloads the appropriate root certificate directly from Windows Update. The full process for all versions of the OS is described in a KB article. I’m not going to rehash the explanation of how it works, but the key point is that only those certificates accepted through the root program will be downloaded from Windows Update.

The IE low integrity processes are not instructing the broker to do anything, it all happens under the hood in the crypto APIs. Now, here is why the IE behavior is observed. You go to a web site, which certificate is issued by a CA not yet in your trusted root list. Because IE uses the standard cryptography API that Windows provides, when certificate validation is performed, Windows itself (not IE, nor its broker process) goes and fetches the root certificate from Windows Update *if* that certificate is part of the Root Program. The same behavior will be seen for any program that is using the same API to do certificate validation. Chrome as far as I know uses the Windows crypto APIs to do certificate validation and relies on the trusted roots list from Windows, so if you browse with Chrome, you will see the exact same thing happen (though I haven’t verified it personally).

Some people have asked me how they can prevent Windows from going to Windows Update in such cases. This can be achieved by disabling automatic root update through policy as described on TechNet. It should be noted that one should exercise caution in doing so, because disabling root update means that Windows will no longer manage certificate trust for you. You will have to manage the set of trusted root certificates on your own. To that end, import the full list of CAs part of the Root Program such that those are available in the list of trusted roots. Microsoft provides a small program – rootsupd.exe, as part of KB931125 which accomplishes this task. With this approach, you have control over trust management, but you need to keep the list updated whenever the set of roots in the root program changes. Microsoft has a wiki page which includes the information about new certificates that are part of an update. This page has RSS feed available which you can subscribe to so that you are notified of new updates, which makes keeping track of the updates an easy job.

I hope this helps explain how this all works and clarify that there is no real violation of the No-Write-Up policy, even though it might seem like it from high level.

Tags: , , , , , , ,

Fraudulent SSL certificates


As many people are reporting today, there have been a few SSL certificates issued to a fraudulent party. The Comodo CA had an RA account compromised and used to issue certificates for some of the top web sites on the net. Their advisory is

All major browsers are updating to blacklist those certificates and I’d suggest you install updates as soon as you can to prevent possible attacks. Since none of the certificates have been seen in the wild, the chance is very very slim, but it doesn’t hurt to do an update.

It was very interesting to see Jacob Appelbaum correlate multiple sources of information to discover this independently from the actual announcement. I’ve been advocating that bad guys are already doing this, but very few people believe it. Now I hope this demonstrates that automated correlation can reveal lots of data. Furthermore Adam Langley has a good discussion why revocation has problems and we should be looking into how to improve the state of it.


Tags: , , , , ,

Windows SSL/TLS update for secure renegotiation


Couple of weeks ago Microsoft released an update to the SSL/TLS stack to implement secure renegotiation as described in RFC 5746. The Microsoft KB article describes the three settings controlling the behavior of the patch, but a bit more detail can be useful.

A bit of background first. TLS extensions are a method of extending the TLS protocol without having to change the specification of the core protocol and are described in RFC 4366. It is defined as arbitrary extra data that can be appended to the ClientHello and/or ServerHello messages (which are the first messages sent by each side). Servers are supposed to ignore data following the ClientHello if they don’t understand it.

Since the TLS extensions were not a formal RFC in the past, some server implementations were written to fail requests which have more data following the ClientHello message, which makes them non-interoperable with clients that send TLS extensions. This is the precise reason why RFC 5746 has adopted the idea of Signaling Cipher Suite Value (SCSV) to avoid breaking interoperability with servers not accepting TLS extensions. The recommended approach, though, is to use the TLS extension defined by the RFC.

Now here are the important details. By default, any version of Windows prior to Vista did not send TLS extensions when using the TLSv1.0 protocol. With the new update, this has changed and if TLSv1.0 is enabled, then the renegotiation indication extension will be sent as part of the TLS handshake, as recommended. So the small set of servers (no one that I know of knows the actual percentage of such servers) which do not tolerate this behavior will cause interoperability problems. This is where the UseScsvForTls setting described in the Microsoft KB comes in. Setting the registry key to non-zero value will cause the SSL/TLS stack to generate TLS ClientHello messages containing SCSV and without extensions, so interoperability with such servers can be restored. As far as the other two keys, AllowInsecureRenegoClients and AllowInsecureRenegoServers, they control the compatible vs strict mode and will not make any difference on the structure of the messages on the wire. The only effect is whether communication is allowed to continue with unpatched party or not.

Signaling Cipher Suite Value
Tags: , , , , , , ,

PhoneFactor WordPress plugin


I have recently stumbled upon the plugin PhoneFactor has for WordPress and decided to give it a shot, knowing the idea behing the PhoneFactor authentication model. The install was smooth, since WordPress does a good job on integrating installing plugins into the admin panel. There were a few issues that I hit once it was installed, but they were mainly caused by my own customizations to WordPress to force SSL on the admin panel and some other security enhancements.

If you are like me and rely heavily on SSL for the admin area, you might already know and be frustrated by the busted defaults for most plugins. In their defense, it is a WordPress issue, since their built in functions return http based URLs instead of https when hosted over SSL. I believe this is being addressed in 3.0, but so far I’ve had to patch each new release of WP to get safety, but I digress.

The only issue with the plugin itself is that it reported the username I picked as used, even though it was not. You can safely ignore this or if you want to do it right, apply the following patch:

@@ -171,6 +171,7 @@ pf.testNumberCompleted = function(data) {
                                                        CURLOPT_POST => true,
                                                        CURLOPT_POSTFIELDS => $post,                                                                                                                       CURLOPT_RETURNTRANSFER => TRUE,
+                                                       CURLOPT_SSL_VERIFYPEER => false                                                                                                            );                                                                                                                                                 $curl = curl_init();
                                                foreach ($curl_options as $option => $value) curl_setopt($curl, $option, $value);

With that taken care of, one can sign up for an account right from the plugin. Once it is all said and done this plugin is AWESOME. Now I can actually authorize each login to my blog and ensure that even if someone were to get their hands on my password, they won’t be able to login to the blog. And the best part is that the call feature is actually free!

Thanks PhoneFactor for a great plugin!

Tags: , , , ,

Results after 30 days of (almost) no trusted CAs


Today marks the 30th day since I removed all the root certificates for trusted certificate authorities. It was an interesting one month and I’ve learned a bunch. The main takeaway from this experiment is that I don’t need 3 digit number of trusted CAs in my browser. Again, this is person specific and US centric, but the total count as of today is 10! The list of subject names and signatures follows for the ones interested in the exact list.

CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US

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

OU=Class 3 Public Primary Certification Authority, O=VeriSign, Inc., C=US

OU=Equifax Secure Certificate Authority, O=Equifax, C=US

CN=GTE CyberTrust Global Root, OU=”GTE CyberTrust Solutions, Inc.”, O=GTE Corporation, C=US
97817950d81c9670cc34d809cf794431367ef474 Secure Server Certification Authority, OU=(c) 1999 Limited, incorp. by ref. (limits liab.),, C=US

CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
02faf3e291435468607857694df5e45b68851868, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, S=Western Cape, C=ZA

OU=Go Daddy Class 2 Certification Authority, O=”The Go Daddy Group, Inc.”, C=US

CN = GlobalSign Root CA, OU = Root CA, O = GlobalSign nv-sa, C = BE

The last one I’ve included for completeness, since I don’t really need it, but I had to enable it to access over https. It is currently not trusted.

While this is a good list of certs to enable for security geeks like myself, I’m not quite sure how feasible this is today for the average user, so I wouldn’t recommend doing this to your parents’ computer. Even for me it was hard to realize that application failures (such as twhirl completely stopping to work) are due to a root certificate no longer being trusted and SSL connections failing. I also had to look at the wire traffic on a few occasions where the UI would never expose the “I want to see which certificate is failing” option.

One needs to be very careful which certs are disabled. Since it is hard to troubleshoot failures that result from disabling trusted roots, reading up and getting familiar with how certificates work is a great idea. Firefox has its own certificate storage, completely separate from the OS, so messing with it is not as big of an issue, as any errors are isolated to Mozilla applications. Here are some resources for Windows (which affects IE and Chrome):

  • There is a list of mandatory certificates that Windows needs to operate, which is listed here.
  • There is a great overview of how the trusted roots certificates work on Windows and explains why people see things “change” under the hood.
  • Also, in newer versions there seem to be a lot more control on how certificates are validated and what roots are trusted.
  • The list of CAs that Windows trusts.

I hope this information is helpful to people. Feel free to ping me with questions you might have related to this small project.

Tags: , , , , , , , ,

30 days with (almost) no trusted CAs


I’ve decided to embark on a small project to determine what is the smallest set of trusted root certificates I need in my day-to-day life. I have disabled all trusted CAs in both IE and Firefox and will enable the needed root certificates as I go. So far I’ve spent a week of this and have about 10 certificates, 3 of which were needed because I needed to pay my bills : ).

I will run in this mode for 30 days, at the end of which I will report how many root certificates I had to enable to allow me to go through life. In the meantime, I am tweeting every time I need to enable a CA along with the site that needed it.

It is a fun ride so far, so let’s see where it is going to take me.

Tags: , , , , ,

How to disable trusted root certificates


As part of my testing of how many trusted root certificates I need for my day-to-day activities, I needed to ensure I don’t trust any certificate authorities. There is a great post by Nelson Bolyard to one of the security mailing lists of Mozilla, which explains why one should not delete CA certificates, but rather disable them. The main take away is that there is a big difference between the statements “I don’t know you” (if you remove the certificate) and “I know you and I don’t trust you” (disabling the certificate). Some browsers also handle these errors differently.

The different browsers store certificates differently. IE, Chrome, and I believe Safari as well (haven’t tested it) on Windows use the OS built-in certificate infrastructure, while Firefox uses its own certificate storage. As such, here are the steps you need to take for the two different cases:

IE, Chrome (Safari?)

You need to run the certmgr.msc utility (either through Start->Run/Search or from a command prompt). This will launch the UI used to manage the certificate stores in Windows for the current user.

CertMgr Certificate Stores

The “Third-Party Root Certification Authorities” stores all the trusted 3rd party CAs. You will find either a fairly small set of those if Windows hasn’t downloaded the full list, or quite a bit of them after the full list has arrived. To disable the root certificates, select the ones you want and drag them to the “Untrusted Certificates” store and drop them under the “Certificates” subfolder. This instructs the certificate infrastructure in Windows to not trust these certificates. The result is that even though you have the certificates in other stores, the operations will fail. The “Untrusted Certificates” store trumps all others, so you don’t have to worry about forgetting a certificate somewhere else.

Keep in mind that doing this in Windows will affect all programs that use SSL/TLS and certificates. I’ve broken my twitter client for example by removing all CAs from the trusted list : ).


You will need to click on Tools->Options, select the Advanced category, select the Encryption, click View Certificates, and click on the Authorities tab. This will open up a window with all the trusted certificate authorities. For each of those, once you select it, you can click on the “Edit” button and you will see a window that looks like this:

Firefox Trusted CA

This CA is trusted for all 3 types of identification. To disable the certificate, just uncheck all the check boxes and click Ok:

Firefox Disabled CA

The result is that this certificate is no longer trusted to vouch for the identity of anything. You need to repeat the process for all the certificates you want to disable and I don’t know of an easy way to automate this. For the certificates listed as “Builtin Object Token”, Marsh Ray has tried deleting them and claims that this results in disabling them (since they are built-in and cannot be deleted) after restarting Firefox.

After you have disabled the CA certificates, you can expect SSL/TLS connections to fail if the certificate is issued by a disabled CA.
Have fun browsing with minimized attack surface : )

Tags: , , , , , , , , , ,

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: , , , , ,