Certificate validation and trust policy design on UNIX, Linux and Windows systems

IBM MQ validates TLS certificates according to two types of policy, basic, and standard. Standard policy checking conforms to RFC 5280.

The information in these topics applies to the following systems:

  • IBM MQ for UNIX and Linux systems
  • IBM MQ for Windows systems

The following terms are used in this section:

    Certificate policy
    Determines which fields in a certificate are understood and processed.

    OCSP policy
    Determines which fields in an OCSP request or response are understood and processed.

    CRL policy
    Determines which fields in a certificate revocation list are understood and processed.

    Path validation policy
    Determines how the certificate, OCSP, and CRL policy types interact with each other to determine whether a certificate chain (a trust point "RootCA" to an end-entry "EE") is valid.

The basic and standard path validation policies are described separately because it reflects the implementation within IBM MQ for UNIX, Linux and Windows systems. However, the standard OCSP and CRL policies are the same as the basic policies, and the standard certificate policy is an extended version of the basic policy, so these policies are not described separately.

By default, IBM MQ applies basic policy validation first. If basic policy validation fails, IBM MQ applies standard policy (RFC 5280) validation. If basic policy validation succeeds, standard policy validation is not applied. Thus, a validation failure means that both basic and standard policy validation failed, possibly for different reasons. A validation success means that either basic policy validation succeeded and standard policy validation was therefore not applied, or basic policy validation failed and standard policy validation succeeded.


Enforcing strict RFC 5280 compliance

To enforce strict RFC 5280 compliance, use the certificate validation policy configuration setting. This setting allows you to disable the basic policy, so that only the standard RFC 5280 policy is used. For more information about the certificate validation policy configuration setting, see Certificate validation policies in IBM MQ.

The following examples are digital certificates that are accepted by the basic certificate validation policy, but which are rejected by the RFC 5280 compliant standard policy. In order for a digital certificate chain to be trusted, the entire chain must satisfy the configured validation policy.

To view the full details of a digital certificate, use the runmqakm command: 
runmqakm -cert -details -db key.kdb -pw password -label certificate_label
A certificate that has trust status enabled in the runmqakm output is not necessarily trusted for use in a TLS handshake. Trust status enabled means that the certificate is eligible to be used as a CA certificate to verify other certificates, if the certificate also satisfies the rules of the certificate validation policy. For more information about the RFC 5280 compliant standard certificate validation policy, see Standard path validation policy.

    Example certificate 1 - incorrect key usage
    This example shows a certificate where the key usage field does not comply with the standard certificate validation policy rules for a CA certificate. One of the requirements for a certificate to be valid for use as a CA certificate is that the key usage field must indicate that it is permitted to sign other certificates using the keyCertSign flag. A certificate without this flag cannot be used as a CA certificate. 
    Label : root
Key Size : 1024
Version : X509 V3
Serial : 54cb6f740c7ee410
Issuer : CN=Example Root CA,O=Example,C=GB
Subject : CN=Example Root CA,O=Example,C=GB
Not Before : 9 February 2012 17:19:00 GMT
Not After : 1 October 2019 18:19:00 GMT+01:00
Public Key
    30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
    05 00 03 81 8D 00 30 81 89 02 81 81 00 CC 44 D9
    25 6D 26 1C 9D B9 FF DE B8 AC 44 AB E3 64 80 44
    AF BE E0 00 93 53 92 33 F8 7E BD D7 71 ED 21 52
    24 75 DF D6 EE 3C 54 97 84 29 EA 93 4C 4A D1 19
    5D C1 A0 82 F5 74 E1 AD D9 87 10 D5 6A 2B 6F 90
    04 0F 7E 6E 85 6D 32 99 33 9C D9 BB 57 86 DE 68
    23 C9 F2 6D 53 E3 F5 FF D1 0B E7 23 19 3A F6 70
    6B C8 C7 EB DB 78 8E 8C 9E 55 58 66 B6 31 DB 40
    5F 6A 97 AB 12 D7 E2 3E 2E 79 EE 78 7B 02 03 01
    00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
    EE 68 D4 4F 73 4F F4 21 DE 1A 01 11 5E DE B1 B8
    DF 40 AA D8
Fingerprint : MD5 :
    50 B5 E9 B2 D7 35 05 6A DC 6D 4B 1E B2 F2 DF A4
Fingerprint : SHA256 :
    B4 D7 6E C4 47 26 24 C7 4F 41 C3 83 03 6F 5C C7
    07 11 61 E0 0E 36 59 1F 1C E6 69 39 2D 18 05 D2
Extensions
    basicConstraints
        ca = true
        pathLen = 1239876
        critical
    key usage: encipherOnly
Signature Algorithm : SHA256WithRSASignature (1.2.840.113549.1.1.11)
Value
    9D AE 54 A9 9D 68 01 68 15 B5 53 9F 96 C9 5B D1
    52 40 DB CB 33 AF FD B9 26 D5 90 3F 1E 0B FC A6
    D9 8C 04 90 EB AA FD A8 7A 3C AB 60 5F 20 4F 0D
    7B 73 41 27 6A 2B BF 8C 99 91 B6 49 96 82 6A 24
    0A E8 B9 A5 AF 69 3D 2C A3 3C C8 12 39 FB 56 58
    4E 2A FE AC AC 10 89 53 B1 8F 0F C0 50 BF 5E 00
    91 64 B4 A1 4C 9A 4E D5 1F 38 7C AD 32 A9 8A E1
    91 16 2C 6D 1E 4A CA 99 8D CC 22 CD BF 90 49 FC
Trust Status : Enabled
    In this example, the key usage field contains only the encipherOnly flag. The keyCertSign flag is not set, so this certificate is not permitted to sign other certificates. It therefore cannot be used as a CA certificate.

    Example certificate 2 - missing basic constraints extension
    This example shows a certificate which lacks the basic constraints extension. The basic constraints extension is used to indicate whether this certificate is permitted for use as a CA. It is also used to indicate the maximum length of any certificate chain which can be signed by the certificate. The standard certificate validation policy requires that the certificate has a basic constraints extension with the isCA flag set in order to be used as a CA. 
    Label : root
Key Size : 1024
Version : X509 V3
Serial : 1c7dfea316570bf6
Issuer : CN=Second Example Root CA,O=Example,C=GB
Subject : CN=Second Example Root CA,O=Example,C=GB
Not Before : 9 February 2012 17:18:22 GMT
Not After : 1 October 2019 18:18:22 GMT+01:00
Public Key
    30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
    05 00 03 81 8D 00 30 81 89 02 81 81 00 B2 70 49
    7C AE 1B A7 B3 06 49 6C 99 19 BC A8 77 BE 86 33
    21 6B C9 26 CC A6 28 52 9F 7B CF 03 A4 37 A7 4D
    6B 06 AA ED 7D 58 E3 70 F3 F7 C1 06 DA E8 27 C6
    3D 1B AC FA EF AA 59 7A 9A AB C1 14 4E AF 13 14
    4B 71 CA 8D FE C3 F5 2F E8 AC AD EF 21 80 6D 12
    89 4A 2A 84 AA 9D E0 4F C1 93 B1 3E 16 E8 3C 75
    39 2A 74 1E 90 CC B1 C3 2B 1D 55 26 76 D2 65 C1
    06 47 2A BF 79 96 42 76 A9 6E 65 88 5F 02 03 01
    00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
    33 9F A1 81 43 F1 43 95 48 A5 66 B4 CD 98 E8 15
    9C B3 CA 90
Fingerprint : MD5 :
    91 EA D9 C0 2C 05 5B E2 CD 0B F6 DD 8A 11 44 23
Fingerprint : SHA256 :
    62 46 35 0B 0E A1 A7 2A D5 74 70 0F AA 47 9A 9C
    6B 80 1B F1 0B 4C 81 05 85 0E 91 11 A4 21 D2 34
Extensions
    key usage: digitalSignature, keyCertSign
Signature Algorithm : SHA256WithRSASignature (1.2.840.113549.1.1.11)
Value
    79 34 BA 5B 6F DC 06 A3 99 24 4E 8A 2B 27 05 47
    0D 4D BE 6A 77 D1 1D 5F 54 82 9D CC F6 92 D4 9A
    AB 4D B6 DD 6E AD 86 C3 6A A3 32 E3 B3 ED E0 62
    4A EB 51 08 AC BE 49 9E 9C D7 FE AE C8 9D 17 16
    68 31 6B F4 BA 74 1E 4F 5F 05 48 9F E7 46 BA DC
    17 7A 60 88 F8 5B DB 3C 51 D4 98 97 28 82 CF 36
    47 DA D2 0F 47 FF 70 EA 45 3A 49 66 E6 E2 F9 67
    2C C8 3E 24 A2 3B EC 76 1F D6 31 2B BD A9 B5 08
Trust Status : Enabled
    In this example, the certificate lacks the basic constraints field entirely. Therefore this certificate cannot be used as a CA certificate.

    Example certificate 3 - intermediate CA with old version of X.509
    This example shows an intermediate CA certificate which is at X.509 version 1. The standard certificate validation policy requires that all intermediate CA certificates must be at least X.509 version 3. Root CA certificates are exempt from this requirement as there are still some commonly used version 1 root CA certificates in existence. However, this exemption might change in future. 
    Label : intermediate
Key Size : 1024
Version : X509 V1
Serial : 02
Issuer : CN=Test Root CA,O=Example,C=GB
Subject : CN=Test Intermediate CA,O=Example,C=GB
Not Before : 10 February 2012 17:33:45 GMT
Not After : 11 April 2018 18:33:45 GMT+01:00
Public Key
    30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
    05 00 03 81 8D 00 30 81 89 02 81 81 00 C0 07 C2
    D0 9F 84 DB 7C 20 8F 51 F9 C2 1A 3F CF E2 D7 F2
    F1 56 F2 A4 8F 8F 06 B7 3B 01 31 DE 7C CC 03 63
    AA D3 2F 1C 50 15 E3 56 80 40 7D FF 75 87 D3 F3
    00 89 9A 26 F5 57 05 FA 4F ED 3B DD 93 FA F2 DF
    38 26 D4 3A 92 51 CC F3 70 27 42 7A 9F AD 51 45
    67 B7 AE 11 AD 4F 2D AB D2 CF 73 E6 F0 45 92 F0
    47 16 66 7E 01 C7 76 A3 7B EC D2 76 3F E5 15 EC
    D7 72 2C FE 14 F5 78 83 AA C4 20 AB F7 02 03 01
    00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
    DE BB 75 4B 14 E1 44 B9 B6 44 33 97 49 D0 82 6D
    81 F2 2F DE
Fingerprint : MD5 :
    72 49 44 42 E2 E6 89 F1 CC 37 C9 F6 B5 8F F3 AE
Fingerprint : SHA256 :
    83 A4 52 AF 49 34 F1 DC 49 E6 95 AE 93 67 80 13
    C2 64 D9 26 22 A0 E8 0A 5A A9 71 EC E8 33 E1 D1
Signature Algorithm : SHA256WithRSASignature (1.2.840.113549.1.1.11)
Value
    40 4A 09 94 A0 18 07 5E 96 D7 A6 52 6B 8D 20 50
    E8 91 F7 7E EA 76 B4 08 DF 76 66 1F FA FF 91 79
    2E E0 66 8B 9F 40 FA 14 13 79 81 DB 31 A5 55 1D
    44 67 41 F4 EA 1A F7 83 4F 21 F4 43 78 4E F8 5E
    6F B2 B8 3A F7 6B B4 F5 C6 F8 EB 4C BF 62 6F 3E
    C7 20 EC 53 B3 40 51 36 C1 0A 4E 73 ED 74 D1 93
    02 C5 FB 61 F7 87 64 A5 94 06 7D 25 7C E3 73 DD
    08 D4 07 D0 A4 3F 77 88 12 59 DB A4 DB 68 8F C1
Trust Status : Enabled
    In this example, the version field is X.509 V1. This certificate is an X.509 version 1 certificate and therefore cannot be used as an intermediate CA.

Parent topic: Security reference