SSL and Intermediate CA Certificates

Here’s an example of why security adoption can be so slow and fraught with difficulty.

My brother, an IIS and Exchange administrator for a large corporation, ran into an interesting problem. He was moving their Outlook Web Access installation from a single web server to a load-balanced cluster of three servers. He changed the DNS entry to point to the new cluster, and began to see unexplained errors in client web browsers. Internet Explorer (on some machines) was complaining of an expired certificate, but the whole certificate path displayed by IE was current and valid. Firefox was complaining with a “Website Certified by an Unknown Authority” error. All very confusing.

Problem was solved with some clever googling. The problem was that since the server certificate was exported from one server and imported to another, it didn’t transfer the new intermediate CA certificate. (The one installed with Windows Server 2003 expired in 2004.) This certificate was being passed to the browsers as described in this posting. Clients were failing to build the path sent by IIS (unless they had the valid intermediate certificate already in their own cache). A description of how to solve this problem is provided by Verisign but is a little daunting.

What’s broken here? Should IIS be sending expired certificates as part of its chain? Should IIS alert the administrator that some of the certificates it uses are expired? Should Microsoft Update push the newest intermediate certificates to clients as part of regular patch management? Should clients be able to give you information on exactly which certificate had the problem? Obviously this is just one example of why security adoption can be so difficult.