I started having SQL server problems that pointed to a Certificate problem. When I loaded the Certificates MMC snapin to see where the problem could be, I found 105 certificates listed under "Trusted Root Certification Authorities - Certificates" in both the Current User and Local Computer sections. They also appeared in other sub sections like "Third-Party Root Certification Authorities - Certificates". The certificates were from a number of organizations including "Deutsche Telekom", "GTE CyberTrust Root", "No Liability Accepted, Verisign, Inc.", and several other companies from around the world.

I exported then deleted all certificates. I recreated the self signed certificate and assigned it to the website that required it. Shortly after doing this, I saw that 5 or 6 Certificates had automagically appeared again. But 2 days later that's all that has shown up.

I also secured the firewall and server a little better after I did this. Can someone explain to me what is going on here and how this happened/s and what I can do to keep it from happening.

Who is Participating?

it is normal to have those entries in your trusted CA list. those are the usual certificate issuers of most the ssl certs around. if you don;t trust them, then when you access an ssl site secured by a certificate issued by one of those CAs, then the browser will pop up a message about not trusting that certificate issuer. you click a button that says something like 'trust them from now on' and it will be added to that list you refer to.

incidentally, mine also has 105 entries. I suspect that this is exactly normal.

> Whenever you visit a third party service encrypted by SSL, the certificate will
> be stored in your trusted certs list.

This is not entirely true. There is no requirement to have an ongoing trust of a certificate in order to be able to use an SSL/TLS secured connection.

You would need to add the issuing CA's root certificate to the Trusted Root CA's (or Intermediate CA) store, which then causes your client to trust the certificate presented by the remote server, rather than trusting the certificate presented by the server.

What I think is happening is that the "Update Root Certificates" Windows component may be installed, and this is updating the list of trusted root CAs. This is generally a good thing, as your computer is also notified of revoked root CA certificates.

um, but if i go to 'https://sighnin.ebay.com', my browser will check with the issuer (verisign) to make sure that it is valid and not revoked. If it is ok, then it will cache that cert in my trusted certificates list. will it not?

I think OP was talking about certificates in the Trusted Root CA node that's visible using the Certificates MMC Snapin.

If I go to the site you mention: https://signin.ebay.com, where exactly is this certificate placed in the certificate store? I don't see it anywhere.

On the other hand, if you visit a site with a certificate that is otherwise valid (e.g. not expired, common name matches DNS name), but is issued by an untrusted CA, you can install the CA's root certificate into your Third Party Root CA Store in order to facilitate seemless access subsequently. If the certificate has other problems (e.g. expired, or common-name does not match DNS name), you can install the server certificate itself, and this appears in the Other People node.

But certificates that have no problems (i.e. are valid all the way down the heirachy) don't appear in the cert store at all as far as I know.

You can check: Start -> Run -> MMC.exe -> add Certificate snapin, and check to see where the certificates appear.

>> But certificates that have no problems (i.e. are valid all the way down the heirachy) don't appear in the cert store at all as far as I know.

hmm, maybe you are right - can't say that i have spent any time investigating it. My comments are based on experience that the certs are cached somehow and somewhere by this example:

1. from a client behind a block-everything firewall, permit port 443 to signin.ebay.com only (nothing else)
2. access https://signin.ebay.com fails - presumedly because the cert cannot be validated
3. now open port 80 to verisign certificate store and revocation list servers
4. access https://signin.ebay.com now succeeds
5. now block access to the CS and RL servers again
6. access https://signin.ebay.com STILL succeeds - presumedly because the cert (or at least the validity status) is cached somewhere.

Therefore I am not surprised to see certificates like what are reported show up in the cert lists. Regardless of any of that, I maintain that certs showing up in there is not something to be of major concern - unless there is some other related reason for worrying about this behaviour. thus my question: "What makes you think that this is causing a problem?"

0

arnoriteAuthor Commented: 2005-05-04

Thanks for the input. I had a small emergency to take care of, but I'm back for a while now.

I read through the responses. Hopefully I'll remember all questions and comments I read.

The reason this even became an issue was when I tried to locally connect to SQL server on the server. I got an error, researched it and found that it was related to certificates. I found a Microsoft knowledgebase article. The article stated that the problem I was experiencing had to do with an untrusted (or something like that) certificate. It said to remove the certificate in question and install a good one. When I looked at the Certificates snapin, I found the 105 certificates. There are 3 reasons why I'm concerned ...

1) SQL Server wasn't working because of this
2) This is on a file server, not a workstation, and no one here surfs the Internet from the file server
3) There were suspicious looking certs appearing (revoked and expired) in the trusted root nodes. Why place those here?

Because of these reasons, I'm suspicious that the server may be hijacked/hacked/being used by wrong doers/etc.

I just checked another Windows 2K3 server running IIS and I'm seing the same thing on it. So maybe this is OK? It would be nice to know for sure, though.

When you install Windows there are a number of Trusted Root Certification Authorities, Intermediate and other certificates that are placed in the stores automatically. These certificates are from reputable verified authorities and/or Microsoft. These certificates are from companies/vendors/etc that go through a verification and screening process in a Microsoft process to get their certificates aded to the defaults that Microsoft ships with Windows and the optional Root Certificate Updates that you'll occasionally see on Windows Update.

If you do not have a copy of the Root Certificate Authority's Root CA certificate that was used to sign another certificate in your Trusted Root CA store you will see a security warning stating that you have not chosen to trust the issuer of the certificate (in some cases) or whatever you needed to trust the certificate to do will simply fail (other cases).

When you browse to an SSL protected site the server will send a copy of its certificate to your browser, the browser then looks to see who signed the cert (this is part of the certificate) and will then check to see if it trusts that issuer (has a copy of their Root CA Certificate in the Trusted Root CA store) and will pop a warning if it doesn't.

It then checks to make sure the certificate is within its valid date range and will once again pop a warning if it isn't.

Finally it checks to see if the host name you are going to matches the certificate's common name.

One possible additional step - if the browser is set to check the revocation status of the server certificate it will retreive a Certificate Revocation Listing from the certificates publisher to make sure the certificate hasn't been revoked.

-----------------

As far as the certificates reappearing - which store did they appear in and who were they from?

Dave Dietz

0

arnoriteAuthor Commented: 2005-05-05

Thanks everyone for your help.

Bottom line, it appears that those certificates are OK to be there. The SQL server problem was resolved by removing all Certificates in the stores. But based on what was discussed here and my actual experience, the problem was more than likely attributable to the self-signed certificate that I created.

>> the problem was more than likely attributable to the self-signed certificate that I created.

ahh, yes - that can cause problems if you have not added the root CA as trusted. you can see this problem when accessing with a web browser - a dialog pops up with some message like "the cert was issued by someone you have not chosen to trust", but add the root ca in your trusted issuer list, and the dialog goes away for good.

with non-interactive services, there is no dialog box because the service cannot be expected to make decisions based on their (logically unknown) content, thus service failure. If you add your own root ca as trusted, then the services will work properly.

Cheers.

0

arnoriteAuthor Commented: 2005-05-05

I wish the Microsoft KB article I read would have explained it like that! They had you remove all certs and then somehow replace the ones you needed. I wish I could always get the straight scoop like you gave me.