18

Today I changed the SSL certificate that 3,000+ Outlook clients are using. In doing this I changed the certificate to an "older" one that had the same subject name, expiration and everything else. Only the thumbprint and one SAN name changed. Once reports came in of an issue, I reverted the change. (1 hour)

It seems that in doing this several deployed instances of Outlook hung, and despite my 15 years of working with Outlook in a support capacity, I couldn't salvage the profile and had to recreate it. (I don't want to repeat this process for the remaining 20+ profiles)

I can only assume a SSL cache exists in Windows, Outlook, or in it's IE dependency.

This brings me to my question:

  • What SSL data exists in the IE SSL state button? Is this a cache of web HTTP data, or certificate data?

  • Is there a per application SSL cache and/or a global one? (e.g. schannel, etc)

  • How do I edit or manage this cache?

Here is a picture of the SSL editor in IE (see "Clear SSL State")

enter image description here

Update:

Even though the certificate is properly formed, unchecking the following text box in Outlook configuration appears to correct the issue

enter image description here

makerofthings7
  • 50,090
  • 54
  • 250
  • 536

2 Answers2

5

Normally, SSL management is per process. The SSL implementation DLL will, for instance, remember SSL sessions and be able to negotiate abbreviated handshakes (that's when a client reconnects to a server, and they agree to reuse the symmetric shared secret they established in a previous connection). Internet Explorer now has the habit of spawning several process, but includes some tricks to share the SSL session information across these process. This all disappears when all IE process are closed, though.

What remain in cache are the CRL. When Windows wants to validate a certificate (e.g. a server certificate), it will try to obtain revocation information, thus CRL or OCSP responses, downloaded from URL which are found in the certificates themselves. Windows will cache the CRL, and that's an on-disk cache because it resists reboots. Windows will also cache "negative" CRL, i.e. failures to obtain a CRL from a given URL. If Windows could not obtain a CRL from a specific URL, it may abstain from trying again the same URL for as long as eight hours -- and even a reboot might not suffice to unlock it. This is often irksome.

Similarly to the CRL cache, Windows may also download intermediate CA certificates, using URL from the certificates (the Authority Information Access extension). These CA certificates can be cached, too, although they do not necessarily appear in the certificate stores (as visible from certmgr.msc).

See this blog post for some information on the Windows CRL cache.

When using certificate-based client authentication in an Active Directory context, things become more complex, because:

  • The SSL client validates the SSL server certificate.
  • The SSL server validates the AD server certificate.
  • The AD server validates the SSL client certificate.

All three validations being performed on distinct machines, with subtly distinct rules, and the mapping of certificates onto AD accounts can fail in many ways.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
5

The 'Clear SSL State' button is there to purge the SSL cache of selected Client Certificates used for authenticating to SSL-based services. It's just there to make client-certificates work faster (partly by remembering which certificate you used to authenticate to a certain site). It doesn't cache previously seen SSL certificates.

Outlook+Exchange can use Client Certificates for authentication, but it's not a common configuration; most sites stick with NTLM or Kerberos over SSL.

Outlook+IMAP can't use client-certificates, but I may very well be wrong; I haven't heard of an instance where they're used.

What you may be running into instead is problems with the Windows SSL Validator.

sysadmin1138
  • 2,033
  • 13
  • 16