Why does WSA strip CRL information from generated certificates while decrypting HTTPS traffic?

Questions

1. Why does the Cisco Web Security Appliance (WSA) strip CRL information from generated certificates while decrypting HTTPS traffic?
2. When generating a "spoofed" server certificate during SSL decryption, the WSA strips the certificate revocation list (CRL) from the original certificate. Why is this done?

Environment

WSA any version, HTTPS proxy and SSL decryption enabled.

Symptoms

The CRL information in the original server certificate is no longer present in the generated certificate while decrypting HTTPS traffic on WSA, and thus clients cannot confirm whether the certificate has been revoked.

The WSA strips the CRL information because it is no longer valid for the generated certificate. The explanation involves an understanding of how CRLs work.

A certificate authority (CA) can optionally maintain a list of certificates that it considers no longer valid, called a certificate revocation list, or CRL. A certificate may be revoked for a variety of reasons - the CA may determine that the entity that requested the certificate is not who they said they were, or the private key associated with the certificate may be reported stolen. Clients that are validating a web server identity based on a signed server certificate may consult the CRL to confirm that the certificate has not been revoked.

A CRL contains a list of certificates which have been revoked by a particular CA and that list is then signed by the CA. Revoked certificates are identified by serial number. A client can retrieve this CRL and then confirm that the server certificate is not listed in the CRL. The URL for downloading the CRL is usually included as a field in the certificate. As a practical manner, most clients do not validate certificates against a CRL.

When the WSA is decrypting HTTPS or SSL traffic, it does this by generating a new server certificate and signing it with its own internal CA (certificate uploaded or generated under the HTTPS proxy section).

If the WSA did not strip the CRL information, then a client that wanted to validate the CRL would find that the certificate and the CRL are signed by different certificate authorities, and either ignore the CRL or flag an error. Furthermore, under some circumstances, the WSA will change the serial number in the generated certificate to be different than the serial number in the original certificate. This means that, even if a client ignored the difference in CA between the CRL and the WSA-generated certificate, the serial number information would not be valid.

The best way to address the issue is for the WSA to validate the CRL itself, on the client's behalf and then exclude the CRL information from the certificate. WSA is not capable of doing this today.

On AsyncOS versions 7.7 and above:

Starting with AsyncOS Version 7.7, the WSA supports the Online Certification Status Protocol (OCSP) which is an alternative to CRL.

When enabled, OCSP provides the ability to obtain the revocation status of an X.509 digital certificate.