Certificate Status Decryption Rule Conditions

For each certificate status decryption rule you configure, you can match traffic against the presence or absence of a given status. You can select several statuses in one rule condition; if the certificate matches any of the selected statuses, the rule matches the traffic.

You can choose to match against the presence or absence of multiple certificate statuses in a single certificate status rule condition; the certificate needs to match only one of the criteria to match the rule.

You should consider, when setting this parameter, whether you're configuring a decrypt rule or a block rule. Typically, you should click Yes for a block rule and No for a decrypt rule. Examples:

If you're configuring a Decrypt - Resign rule, the default behavior is to decrypt traffic with an expired certificate. To change that behavior, click No for Expired so traffic with an expired certificate is not decrypted and resigned.
If you're configuring a Block rule, the default behavior is to allow traffic with an expired certificate. To change that behavior click Yes for Expired so traffic with an expired certificate is blocked.

The following table describes how the system evaluates encrypted traffic based on the encrypting server certificate’s status.

Certificate Status Rule Condition Criteria
Status Check	Status Set to Yes	Status Set to No
Revoked	The policy trusts the CA that issued the server certificate, and the CA certificate uploaded to the policy contains a CRL that revokes the server certificate.	The policy trusts the CA that issued the server certificate, and the CA certificate uploaded to the policy does not contain a CRL that revokes the certificate.
Self-signed	The detected server certificate contains the same subject and issuer distinguished name.	The detected server certificate contains different subject and issuer distinguished names.
Valid	All of the following are true: The policy trusts the CA that issued the certificate. The signature is valid. The issuer is valid. None of the policy’s trusted CAs revoked the certificate. The current date is between the certificate Valid From and Valid To date.	At least one of the following is true: The policy does not trust the CA that issued the certificate. The signature is invalid. The issuer is invalid. A trusted CA in the policy revoked the certificate. The current date is before the certificate Valid From date. The current date is after the certificate Valid To date.
Invalid signature	The certificate’s signature cannot be properly validated against the certificate’s content.	The certificate’s signature is properly validated against the certificate’s content.
Invalid issuer	The issuer CA certificate is not stored in the policy’s list of trusted CA certificates.	The issuer CA certificate is stored in the policy’s list of trusted CA certificates.
Expired	The current date is after the certificate Valid To date.	The current date is before or on the certificate Valid To date.
Not yet valid	The current date is before the certificate Valid From date.	The current date is after or on the certificate Valid From date.
Invalid certificate	The certificate is not valid. At least one of the following is true: Invalid or inconsistent certificate extension; that is, a certificate extension had an invalid value (for example, an incorrect encoding) or some value inconsistent with other extensions. The certificate cannot be used for the specified purpose. The Basic Constraints path length parameter has been exceeded. For more information, see RFC 5280, section 4.2.1.9. The certificate's value for Not Before or Not After is invalid. These dates can be encoded as UTCTime or GeneralizedTime For more information, see RFC 5280 section 4.1.2.5. The format of the name constraint is not recognized; for example, an email address format of a form not mentioned in RFC 5280, section 4.2.1.10. This could be caused by an improper extension or some new feature not currently supported. An unsupported name constraint type was encountered. OpenSSL currently supports only directory name, DNS name, email, and URI types. The root certificate authority is not trusted for the specified purpose. The root certificate authority rejects the specified purpose.	The certificate is valid. All of the following are true: Valid certificate extension. The certificate can be used for the specified purpose. Valid Basic Constraints path length. Valid values for Not Before and Not After. Valid name constraint. The root certificate is trusted for the specified purpose. The root certificate accepts the specified purpose.
Invalid CRL	The Certificate Revocation List (CRL) digital signature is not valid. At least one of the following is true: The value of the CRL's Next Update or Last Update field is invalid. The CRL is not yet valid. The CRL has expired. An error occurred when attempting to verify the CRL path. This error occurs only if extended CRL checking is enabled. CRL could not be found. The only CRLs that could be found did not match the scope of the certificate.	The CRL is valid. All of the following are true: Next Update and Last Update fields are valid. The CRL's date is valid. The path is valid. The CRL was found. The CRL matches the certificate's scope.
Server mismatch	The server name does not match the server's Server Name Indication (SNI) name, which could indicate an attempt to spoof the server name.	The server name matches the SNI name of the server to which the client is requesting access.

Note that even though a certificate might match more than one status, the rule causes an action to be taken on the traffic only once.

Checking whether a CA issued or revoked a certificate requires uploading root and intermediate CA certificates and associated CRLs as objects. You then add these trusted CA objects to an decryption policy’s list of trusted CA certificates.