Basic path validation policy

 

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 certificate1.

    WebSphere MQ for UNIX 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.

  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 good2.

  6. Ensure that there are no unknown critical extensions or any duplicate extensions.

  7. Ensure that the certificate has not been revoked. The CRLDistributionPoints extension is checked for a list of X.500 distinguished name GENERALNAME_directoryname and URI GENERALNAME_uniformResourceID.

    Only LDAP format URIs are supported. If the extension is not present, the name of the certificate's issuer is used. 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 URI form are the only supported name forms used to look up CRLs and ARLs3

    RelativeDistinguishedNames are not supported.

  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, that the "isCA" flag is true.

  11. If the BasicConstraints extension is not present the certificate is only valid as an EE certificate. 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.

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 key of the certificate issuer.

  3. Ensure that the CRL has not expired4, 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, WebSphere MQ for UNIX and Windows systems only verify that no critical extensions are present.

  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 will cause identified certificates to be treated as revoked5 (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.

      RelativeDistinguishedNames are not supported and will fail CRL validation if encountered.

 

Parent topic:

Certificate validation and trust policy design on UNIX 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 iKeyman. Select the required certificate from the signer list and click the View/Edit... button. 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 IKEYCMD or GSKCapiCmd with the -trust flag on the -cert -modify command. For further information about this command, see Chapter 18, "Managing keys and certificates" in the WebSphere MQ System Administration Guide.

2 There are no checks to ensure the subject's validity is within bounds of the issuer's validity. This is not required, and Verisign certificates have been shown to not pass such a check.

3 When retrieved from the database, ARLs are evaluated in exactly the same way as CRLs. Many CAs do not issue ARLs at all. However, WebSphere MQ for UNIX and Windows systems will look for ARLs and CRLs if checking a CA certificate for revocation status.

4 If no current CRLs are found, WebSphere MQ for UNIX 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 3280 what action to take in the event of no current CRLs. WebSphere MQ for UNIX and Windows systems attempt to use out of date CRLs so that security will not be adversely reduced.

5 ITU X.509 and RFC 3280 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. WebSphere MQ for UNIX and Windows systems adopt the ITU X.509 guidance so that security will not be adversely reduced.

A potential scenario exists where the CA who 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 should not be considered revoked and thus not rejected by the application. In this scenario, following X.509, WebSphere MQ for UNIX 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.


sy12820_