PAN-OS Behaviour for CRLs with IDP Extension: Certificate marked Unknown" if not listed in the CRL"

As per the present behaviour of implementation, if the S/N of a certificate is NOT listed in a CRL, which has IDP extension, the certificate status is marked as UNKNOWN.

This behaviour is in accordance with the RFC, wherein Certificate can be marked  as UNKNOWN if the CRL has IDP extension and the implementations are not required to support this extension.

RFC 5280

https://tools.ietf.org/html/rfc5280

5.2.5. Issuing Distribution Point

The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain  any unrecognized critical extensions.

Analysing this behaviour on the firewall:

The following logs can be seen in sslmgr.log:

2016-08-26 17:09:01.582 +1000 IDP extension present in crl http://crl3.digicert.com/sha2-ev-server-g1.crl so set status as unknown for unlisted certificate serial [0793EC89595DBA606D1FD9F7BE389802].

Here, 07:93:EC:89:59:5D:BA:60:6D:1F:D9:F7:BE:38:98:02  is the S/N  of  www.digicert.com Certificate.

How to verify

• "sha2-ev-server-g1.crl" is the CRL being downloaded (as seen in sslmgr.log) for these websites.
• Download the CRL to your local computer using the link.
• Check if the CRL has IDP extension :

$ openssl crl -inform DER -text -in sha2-ev-server-g1.crl
Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
        Last Update: Aug 25 17:04:24 2016 GMT
        Next Update: Sep  1 17:00:00 2016 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: 
                keyid:3D:D3:50:A5:D6:A0:AD:EE:F3:4A:60:0A:65:D3:21:D4:F8:F8:D6:0F
            X509v3 CRL Number: 
                1036
            X509v3 Issuing Distrubution Point: critical    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
                04.2.0..http://crl3.digicert.com/sha2-ev-server-g1.crl
Revoked Certificates:
    Serial Number: 0983906AA7BF5F294B1BB4EC71AC769C
        Revocation Date: Jul 16 19:09:26 2014 GMT
    Serial Number: 0C340284CF828B2E7D72AB750D17FCA1
        Revocation Date: Sep 14 08:02:02 2014 GMT
<SNIP>

•  Check for the S/Ns in the CRL does not return a match:

$ openssl crl -inform DER -text -in sha2-ev-server-g1.crl | grep 0793EC89595DBA606D1FD9F7BE389802 
$                       <<<<<<  (No Match) 

Example of where this behaviour can manifest itself: 

One of the scenarios where this behaviour can cause issues is when the SSL decryption profile is set to block session with "unknown" certificate status:

Following is the example of Certificate error seen on the end user when accessing github.com with certificate marked as uknown and connection blocked by the firewall: