Basic path validation policy

The basic path validation policy determines how the certificate, OCSP, and CRL policy types interact with each other to determine if a certificate chain is valid.

The validation of a chain is performed in the following manner (but not necessarily in the following order):

  1. Ensure that the name of the certificate's issuer is equal to the subject name in the previous certificate, and that there is not an empty issuer name in this certificate or the previous certificate subject name. If no previous certificate exists in the path and this is the first certificate in the chain, ensure that the issuer and subject name are identical and that the trust status is set for the certificate 1 . Note: IBM MQ for UNIX, Linux and Windows systems will fail path validation in situations where the previous certificate in a path has the same subject name as the current certificate.
  2. Ensure that the signature algorithm used to actually sign the certificate matches the signature algorithm indicated within the certificate, by ensuring that the issuer signature algorithm identifier in the certificate matches the algorithm identifier in the signature data.
  3. Ensure that the certificate was signed by the issuer, using the subject public key from the previous certificate in the path to verify the signature on the certificate. If no previous certificate exists and this is the first certificate, use the subject public key of the certificate to verify the signature on it. IBM MQ supports DSA and RSA signature algorithms; however it does not support DSA Parameter Inheritance.
  4. Ensure that the certificate is a known X509 version, unique IDs are not present for version 1 certificates, and extensions are not present for version 1 and version 2 certificates.
  5. Ensure that the certificate has not expired, or not been activated yet, and that its validity period is good 2 .
  6. Ensure that there are no unknown critical extensions or any duplicate extensions.
  7. Ensure that the certificate has not been revoked. Here, the following operations apply:
    1. If the OCSP connection is enabled and a Responder Address is configured or the Certificate has a valid AuthorityInfoAccess extension specifying a HTTP format GENERALNAME_uniformResourceID check revocation status with OCSP.
    2. If revocation status from 7.a above is undetermined the CRLDistributionPoints extension is checked for a list of X.500 distinguished name GENERALNAME_directoryname and URI GENERALNAME_uniformResourceID. Only LDAP, HTTP and FILE format URIs are supported. If the extension is not present, or use of the CRLDistributionPoints extension results in undetermined status and the extension is not Critical, the certificate's issuer's name is used to query revocation status. A CRL database (LDAP) is then queried for CRLs. If the certificate is not the last certificate, or if the last certificate has the basic constraint extension with the "isCA" flag turned on, the database is queried for ARLs and CRLs instead. If CRL checking is enabled, and no CRL database can be queried, the certificate is treated as revoked. Currently, the X500 directory name form and the LDAP/HTTP/FILE URI forms are the only supported name forms used to look up CRLs and ARLs 3 . Note: RelativeDistinguishedNames are not supported.
    3. If revocation status from both 7.a and 7.b is undetermined, IBM MQ checks the OCSPAuthentication configuration setting to decide whether to allow the connection. 4

  8. If the issuerAltName extension is marked critical, ensure that the name forms are recognized. The following general name forms are currently recognized:

    • rfc822
    • DNS
    • directory
    • URI
    • IPAddress(v4/v6)

  9. If the subjectAltName extension is marked critical, ensure that the name forms are recognized. The following general name forms are currently recognized:

    • rfc822
    • DNS
    • directory
    • URI
    • IPAddress(v4/v6)

  10. If the KeyUsage extension is critical on a non-EE certificate, ensure that the keyCertSign flag is on, and ensure that if the BasicConstraints extension is present, the "isCA" flag is true.
  11. If the BasicConstraints extension is present, the following checks are made:

    • If the "isCA" flag is false, ensure the certificate is the last certificate in the chain and that the pathLength field is not present.
    • If the "isCA" flag is true and the certificate is NOT the last certificate in the chain, ensure that the number of certificates until the last certificate in the chain is not greater than the pathLength field.

  12. The AuthorityKeyID extension is not used for path validation, but is used when building the certificate chain.
  13. The SubjectKeyID extension is not used for path validation, but is used when building the certificate chain.
  14. The PrivateKeyUsagePeriod extension is ignored by the validation engine, because it cannot determine when the CA actually signed the certificate. The extension is always non-critical and therefore can be safely ignored.

An OCSP Response is also validated to ensure that the response itself is valid. Validation is performed in the following manner (but not necessarily the following order):

  1. Ensure that response status is Successful and the response type is PKIX_AD_OCSP_basic.r
  2. Ensure that response version data is present and the response is the correct version (Version 1)
  3. Ensure that the response is correctly signed. The signature will be rejected if the signer does not meet at least one of the following criteria:

    • The signer matches a local configuration of OCSP signing authority 5 for the certificate.
    • The signer is using the CA key for which the public key is contained in the CA certificate, that is, the CA itself is directly signing the response.
    • The signer is a direct sub-ordinate of the CA that signed the certificate for which revocation information is being checked and is authorized by the CA by including the value of id-ad-ocspSigning in an ExtendedKeyUsage extension. Note: Revocation checking of the response signer certificate is not performed if the id-pkix-ocsp-nocheck extension is present.

  4. Ensure that response hash algorithm, serialNumber, issuerNameHash, and issuerKeyHash match those of the request.
  5. Ensure that the response has not expired, that is, that the nextUpdate time is greater than the current time. 6
  6. Ensure that the certificate has valid revocation status.

The validation of a CRL is also performed to ensure that the CRL itself is valid, and is performed in the following manner (but not necessarily the following order):

  1. Ensure that the signature algorithm used to actually sign the CRL matches the signature algorithm indicated within the CRL, by ensuring that the issuer signature algorithm identifier in the CRL matches the algorithm identifier in the signature data.
  2. Ensure that the CRL was signed by the issuer of certificate in question, verifying that the CRL has been signed with the key of the certificate issuer.
  3. Ensure that the CRL has not expired 7, or not been activated yet, and that its validity period is good.
  4. Ensure that if the version field is present, it is version 2. Otherwise the CRL is version 1 and must not have any extensions. However, IBM MQ for UNIX, Linux and Windows systems only verifies that no critical extensions are present for a version 1 CRL.
  5. Ensure that the certificate in question is on the revokedCertificates field list and that the revocation date is not in the future.
  6. Ensure that there are no duplicate extensions.
  7. If unknown critical extensions, including critical entry extensions, are detected in the CRL, this causes identified certificates to be treated as revoked 8 (provided the CRL passes all other checks).
  8. If the authorityKeyID extension in the CRL and the subjectKeyID in the CA certificate are present and if the keyIdentifier field is present within the authorityKeyID of the CRL, match it with the CACertificate's subjectKeyID.
  9. If the issuerAltName extension is marked critical, ensure that the name forms are recognized. The following general name forms are currently recognized:

    • rfc822
    • DNS
    • directory
    • URI
    • IPAddress(v4/v6)

  10. If the issuingDistributionPoint extension is present in the CRL, process as follows:

    • If the issuingDistributionPoint specifies an InDirectCRL then fail the CRL validation.
    • If the issuingDistributionPoint indicates that a CRLDistributionPoint is present but no DistributionPointName is found, fail the CRL validation
    • If the issuingDistributionPoint indicates that a CRLDistributionPoint is present and specifies a DistributionPointName ensure that it is a GeneralName or LDAP format URI that matches the name given by the certificate's CRLDistributionPoint or the certificate's issuer's name. If the DistributionPointName is not a GeneralName then the CRL validation will fail. Note: RelativeDistinguishedNames are not supported and will fail CRL validation if encountered.

Parent topic: Certificate validation and trust policy design on UNIX, Linux and Windows systems 1 Trust status is an administrative setting in the key database file. We can access and alter the trust status of a particular signer certificate in using strmqikm. Select the required certificate from the signer list and click View/Edit. The Set the certificate as a trusted root check box on the resulting panel indicates the trust status. We can also set Trust status using runmqckm with the -trust flag on the -cert -modify command. For further information about this command, see Manage keys and certificates.2 There are no checks to ensure the subject's validity is within bounds of the issuer's validity. This is not required, and it has been shown that certificates from some CAs do not pass such a check.3 After they are retrieved from the database, ARLs are evaluated in exactly the same fashion as CRLs. Many CAs do not issue ARLs. However, IBM MQ will look for ARLs and CRLs if checking a CA certificate for revocation status.4 If OCSPAuthentication is set to WARN, IBM MQ logs the unknown revocation status and allows the connection to continue.5 This is a Certificate in the KeyStore a user has installed and that has Trust Status set. 6 If no current OCSP responses are returned from the responder, IBM MQ will attempt to use out of date responses in determining the revocation status of a Certificate. IBM MQ attempts to use out of date Responses so that security will not be adversely reduced.7 If no current CRLs are found, IBM MQ for UNIX, Linux and Windows systems will attempt to use out of date CRLs to determine the revocation status of a Certificate. It is not clearly specified in RFC 5280 what action to take in the event of no current CRLs. IBM MQ for UNIX, Linux and Windows systems attempt to use out of date CRLs so that security will not be adversely reduced.8 ITU X.509 and RFC 5280 are in conflict in this case because the RFC mandates that CRLs with unknown critical extensions must fail validation. However, ITU X.509 requires that identified certificates must still be treated as revoked provided the CRL passes all other checks. IBM MQ for UNIX, Linux and Windows systems adopt the ITU X.509 guidance so that security will not be adversely reduced.

A potential scenario exists where the CA that issues a CRL might set an unknown critical extension to indicate that even though all other validation checks are successful, a certificate which is identified must not be considered revoked and thus not rejected by the application. In this scenario, following X.509, IBM MQ for UNIX, Linux and Windows systems will function in a fail-secure mode of operation. That is, they might reject certificates that the CA did not intend to be rejected and therefore might deny service to some valid users. A fail-insecure mode ignores a CRL because it has an unknown critical extension and therefore certificates that the CA intended to be revoked are still accepted. The administrator of the system should then query this behavior with the issuing CA.