Errors in SSL after replacing the SSL-Interception certificate

Products

• ProxySG Software - SGOS

Issue/Introduction

You are intercepting SSL (transparent or explicit deployment) and your SSL certificate is about to expire. You create a new keyring, a new CSR (with the same common name as the previous cert), import the new certificate and change policy to use the new keyring.

However, you are now getting unexpected error messages. Depending on the browser it might be "The page cannot be displayed" (IE) or key-related messages (in Firefox and Chrome). Why is this happening?

Resolution

The reason for this is that when we refer to a keyring in policy (in this case the SSL-Intercept rule), we are actually referring to a certificate. We identify certificates by their CN (common name). A keyring contains the private key of the certificate and of course both have to match.

Since we don't want any service interruption while the SSL certificate is changed over to the new certificate (certificates can't be extended, only renewed), we have created a new keyring and this contains the private key as well as the certificate. We now look at policy and find a rule for SSL-Interception based on a specific keyring (the "old" keyring). We look at the certificate in that keyring and extract the certificate's CN (common name).

Now we change the SSL-Intercept rule to the new keyring. The CN is the same so we will use the first certificate with that specific CN - and this is usually the first certificate with this CN that has been created (so it's the "old" certificate). We obviously can't use the old certificate with the new private key, so this is where the error originates.

To work around this, there are two options:

1) You can create a new certificate (or CSR) with a different, yet unique, CN.

2) After completely de-referencing the keyring in configuration and policy, you can delete the old certificate and keyring and re-create both.

There is no better or worse option, they depend on your deployment, how certificate roll-out is handled in your organization, how much time you have etc. Both are valid options and both have certain implications depending on the deployment. For example, if you have an explicit proxy and you create a certificate with a different CN (maybe your "old" CN was the proxy's IP address, the new CN is the proxy's DNS name), you have to change the proxy settings in the browser to reflect this CN change, otherwise clients will get a "hostname mismatch" error in the browser.