The following behaviors are observed when this issue occurs:
Delays in the Certificate Cache Proprietor
Log messages such as:
4130.629 CFSSL Cert Proprietor (10000DE): retrieved cert *.google.com does not match signature, is now deleted
Analysis revealed that the cache is keyed on the "Common Name" (that is, server name) in the certificate, and only stores one item per key value. Thus, if there is more than one certificate on the Internet with the same Common Name, they keep replacing each other in the cache, with the result that the appliance has to re-create its version of the certificate that it provides to the client. This is a CPU-intensive process, especially with the new 2048 bit keys. It happens more often with wildcard certificates, like "*.google.com", since the Common Name has to match the server name.
This issue has now been fixed in 220.127.116.11 release and a software fix will be available in the upcoming 18.104.22.168 release.
If you are unable to upgrade to 22.214.171.124 or to the upcoming 126.96.36.199 release then the following workaround can still be used:
Change the SSL forward proxy policy in the VPM:
Access the SSL Intercept layer.
Edit the rule that is set to intercept SSL (right-click and select Edit where action contains Enable HTTPS Interception Object).
Select Splash Text and enter the following in the text box below it: $(x-rs-certificate-serial-number)$(x-rs-certificate-valid-from)$(x-rs-certificate-valid-to)
Click OK> Install Policy.
If the appliance has the SSL interception enabled in CPL format only (instead of VPM), change the intercept line by adding the splash text as shown in the example below: