The validation of a chain is performed in the following manner (but not
necessarily the following order):
- The information in the following paragraph is consistent with the basic
path validation policy described in Basic path validation policy:
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 certificate7.
If the certificate does not have
a subject name, the subjectAltName extension must be present and critical.
- The information in the following paragraph is consistent with the basic
path validation policy described in Basic path validation policy:
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.
If both the certificate's issuersUniqueID
and the issuer's subjectUniqueID are present, ensure they match.
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
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 of the certificate
to verify the signature on it.
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
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.
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
Ensure that the certificate
has not expired, or not been activated yet, and that its validity period is
good8
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
Ensure that there are
no unknown critical extensions, nor any duplicate extensions.
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
Ensure that the certificate
has not been revoked. The CRLDistributionPoints extension is checked for a
list of X500 distinguished names. 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 is the only supported name form used to look
up CRLs and ARLs9.
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
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)
- Ensure that the subject name and subjectAltName extension (critical or
noncritical) is consistent with the constrained and excluded subtrees state
variables.10.
- If the EmailAddress OID is present in the subject name field as an IA5
string, and there is no subjectAltName extension, the EmailAddress must be
consistent with the constrained and excluded subtrees state variable.
- Ensure that policy information is consistent with the initial policy
set11:
- If the explicit policy state variable is less than or equal to the current
certificate's numerical sequence value, a policy identifier in the certificate
shall be in the initial policy set.
- If the policy mapping variable is less than or equal to the current certificate's
numerical sequence value, the policy identifier can not be mapped.
- Ensure that policy information is consistent with the acceptable policy
set:
- If the certificate policies extension is marked critical12, the intersection of
the policies extension and the acceptable policy set is non-null.
- The acceptable policy set is assigned the resulting intersection as its
new value.
- Ensure that the intersection of the acceptable policy set and the initial
policy set is non-null.
- The following is performed for all certificates except the last one:
- 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)
- If the BasicConstraints extension is present, ensure that the "isCA" flag
is true13. If the pathLength field is present, ensure the number of certificates
until the last certificate is not greater than the pathLength field.
- If the KeyUsage extension is critical on not the last certificate, ensure
that the keyCertSign flag is on, and ensure that if the BasicConstraints extension
is present, that the "isCA" flag is true14.
- If a policy constraints extension is included in the certificate, modify
the explicit policy and policy mapping state variables as follows:
- If the policyMappings extension is present (see 12(b)), ensure that it
is not critical, and if policy mapping is allowed, these mappings are used
to map between this certificate's policies and its signee's policies.
- f. If the nameConstraints extension is present15, ensure that it is critical,
and that the permitted and excluded subtrees adhere to the following before
updating the chain's subtree's state in accordance with the algorithm described
in RFC 3280 section 6.1.4 part (g):
- The minimum field is set to zero.
- The maximum field is not present.
- The base field name forms are recognized. The following general name forms
are currently recognized:
- rfc822
- DNS
- directory
- URI
- IPAddress(v4/v6)
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
The AuthorityKeyID extension
is not used for path validation, but is used when building the certificate
chain.
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
The SubjectKeyID extension
is not used for path validation, but is used when building the certificate
chain.
-
The following information is consistent with the basic path validation
policy described in Basic path validation policy:
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.
Trust status is an administrative setting in the key database
file.
You 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. You can also set Trust status using iKeycmd with
the -trust flag on the -cert -modify command. For further
information about this command, see Chapter 18, "Managing keys and certificates"
in WebSphere MQ System Administration Guide. 
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.
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.
WebSphere MQ for UNIX and Windows systems only support nameConstraint
Extensions that are created by WebSphere MQ for UNIX and Windows systems
WebSphere MQ for UNIX and Windows systems only support Policy Extensions
that are created by WebSphere MQ for UNIX and Windows systems.
"isCA" is always checked to ensure it is true to be as
part of the chain building itself, however this specific test is still made.
This check is in fact redundant
because of step (b), but the check is still made.
WebSphere MQ for UNIX and Windows systems only support nameConstraint Extensions that are created
by WebSphere MQ for UNIX and Windows systems.