Certificate validation and trust policy design on UNIX, Linux and Windows systems
WebSphere MQ validates SSL or 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:
- WebSphere® MQ for UNIX and Linux® systems
- WebSphere 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 WebSphere 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, WebSphere MQ applies basic policy validation first. If basic policy validation fails, WebSphere 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 WebSphere MQ.
The following examples are digital certificates which 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- 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.
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.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 - 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.
In this example, the certificate lacks the basic constraints field entirely. Therefore this certificate cannot be used as a CA certificate.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 - 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.
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.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