Each time you visit an SSL-secured Website, you get the “green bar”/lock and your computer recognizes that the certificate is valid because it already has a copy of a certificate authority’s (CA) root certificate in its “Trusted Root Certification Authorities” certificate store. For example, by default, when you install a fresh XP/7 machine, there are over 50 root CAs pre-installed. Among them are: Thawte, Verisign, StartSSL, Microsoft, etc. These are some of the de facto “big players” in the SSL market, and Microsoft has made the decision for you (when you install the OS) that these root certificates will be installed and, therefore, trusted.
Because these root certs are installed, then, any Website that uses a certificate signed by any of these CAs (Thawte, Verisign, StartSSL, Microsoft) will be valid and you get the lock and/or “green bar”. However, what happens if you browse to a Website that uses a certificate signed by (for example) DigiCert? You would receive the IE security warning box (telling you to stay away from the Website because it is potentially untrustworthy since your computer doesn’t have a copy of DigiCert’s root certificate installed).
Generally, you won’t have a problem browsing to SSL Websites. But how can this be? Don’t the root certificates need to be updated/replaced, and aren’t new CAs popping up all the time?
Indeed.
Included in every few Microsoft Updates or so, Microsoft releases an update that will include the latest certificates from those root CA authorities. Your workstations likely have this update applied already and it would have included a copy of the DigiCert root certificate (hence no warning). On the contrary, best practice dictates that you hand-install new root certificates to your domain controllers, member servers, and terminal servers and don’t allow them to auto-update new root CAs.
The logic behind this is that many bits of spyware and malware on the internet find creative ways to install “self-signed” root CAs. If that happens, you’ve given a potential attacker access to your terminal server and most firewalls won’t or can’t pick up this information since it’s encrypted, unless you’re forcing your users through an SSL proxy. While it’s impractical to maintain that level of granular control over your desktops, it is generally thought to be manageable to maintain this level of control over the servers.
Tags: certificate, certificate authority, certification authority, Security, ssl
