3.2.5. Certificate verification options

Zorp is able to automatically verify the certificates received.

When checking revocation state for certificate chains Zorp offers two options:

  • leaf verification: When enabled, leaf revocation check performs both CRL and OCSP staple checking.

  • non-leaf verification: Non-leaf revocation check performs CRL checking.

To support both maximum security verification and the more common use-cases with less strict scenarios, the level of strictness for the verification can be configured separately for leaf and for non-leaf certificates. The configuration is done in encryption policies using options intermediate_revocation_check_type and leaf_revocation_check_type.

For both intermediate_revocation_check_type and leaf_revocation_check_type options 3 values are available:

  • NONE: no revocation check is done

  • HARD_FAIL: revocation check is performed with strict rules. No uncertainty is tolerated, the certificate must have up-to-date and authentic information about a status not being revoked. Otherwise the certificate is rejected by the policy.

  • SOFT_FAIL: revocation check is performed, however, the information is not verified, and the failure to get revocation information is tolerated. If any available information states that the certificate is revoked, the certificate is rejected, otherwise the connection can be established.

intermediate_revocation_check_type also controls the chain verifier behavior of OCSP stapling. If no CRL list from the intermediate CA is available, the OCSP stapling signer's 'certification revoked' state cannot be determined. If intermediate_revocation_check_type has the HARD_FAIL value, the OCSP stapling message is not accepted as a valid revocation information. However, if the OCSP stapling message shows 'revoked state' the message is considered regardless of its chain verification.

The following tables describe how the values, that is NONE, HARD_FAIL or SOFT_FAIL influence the result of the revocation check type:

CRL resultOCSP stapling resultSOFT_FAIL evaluates the results as:HARD_FAIL evaluates the results as:
GOODGOODACCEPTACCEPT
GOODUNKNOWNACCEPTACCEPT
UNKNOWNGOODACCEPTACCEPT
UNKNOWNUNKNOWNACCEPTDENY
GOODREVOKEDDENYDENY
REVOKEDGOODDENYDENY
UNKNOWNREVOKEDDENYDENY
REVOKEDUNKNOWNDENYDENY
REVOKEDREVOKEDDENYDENY

Table 3.1.  Evaluation logic for leaf revocation check type

CRL resultSOFT_FAIL evaluates the results as:HARD_FAIL evaluates the results as:
GOODACCEPTACCEPT
UNKNOWNACCEPTDENY
REVOKEDDENYDENY

Table 3.2.  Evaluation logic for non-leaf revocation check type

The types of accepted certificates can be controlled separately on the client and the server side using the attributes of the ClientCertificateVerifier and ServerCertificateVerifier classes (or your own classes derived from these), respectively.

By default (if the check_subject parameter is set to TRUE in the verifier), Zorp compares the domain name provided in the Subject field of the server certificate to application-level information about the server (that is, the domain name of the URL in HTTP and HTTPS connections).

Example 3.1. Accepting invalid certificates

The following example configures a simple Encryption Policy that permits invalid certificated, and does not check the subject of the server's certificate.

EncryptionPolicy(
    name="MyTLSEncryption",
    encryption=TwoSidedEncryption(
        client_verify=ClientNoneVerifier(),
        server_verify=ServerCertificateVerifier(
            trust_level=TLS_TRUST_LEVEL_NONE, intermediate_revocation_check_type = 
            TLS_INTERMEDIATE_REVOCATION_NONE, leaf_revocation_check_type = 
            TLS_LEAF_REVOCATION_NONE,
            trusted_certs_directory="",
            verify_depth=4,
            verify_ca_directory="/etc/ca.d/certs/",
            verify_crl_directory="/etc/ca.d/crls/",
            check_subject=FALSE
            )
Previous Up Next
 Home