(Cross-posted to IBM-MAIN and IBMTCP-L) Our z/OS product acts as a client to our non-z/OS server. As such, it makes TLS connections to fetch Policy and keys.
As I've written previously, we had a problem when we added TLSv1.3 support to the z/OS product, getting errors: ERROR check_cert_extensions_3280_and_later(): Basic Constraints extension must be critical for CA Certificate The fix was to update the root certificate used by the server to add the required Critical value for Basic Constraints (henceforth "BC" as a shorthand). This happened again here this week when a certificate was updated (someone used the wrong internal CA, which was old). Once we got it straightened out, I started wondering why this only happened once we added TLSv1.3 support. Some reading of RFC5280 (which obsoleted 3280) suggests that a PKIX-compliant certificate should ALWAYS be rejected if not BC. But this doesn't seem to be true until we add the TLSv1.3 support. I say "seems to" because I don't have an easy way to test all combinations. The older version of our z/OS product didn't support TLSv1.3. The changes to implement 1.3 support added three calls to the stack: * One that says "Yeah, we do 1.3": gsk_attribute_set_enum(pSSI->hEnviron, GSK_PROTOCOL_TLSV1_3, GSK_PROTOCOL_TLSV1_3_ON); * One to add the 1.3 key shares: gsk_attribute_set_buffer(pSSI->hEnviron, GSK_CLIENT_TLS_KEY_SHARES, "00230024002500290030", 0); * One to add the 1.3 ciphers (I think?): sslStatus = vsgsk_attribute_set_buffer(pSSI->hSocket, GSK_V3_CIPHER_SPECS_EXPANDED, "C030C02FC028C027C014130113021303003500380039002F00320033", 0); There was another change that added SNI support, but that was backported to the old version, so I don't think it nets out as a difference between what I had available to test. And of course the cert is fixed now, so I couldn't easily test more if I wanted to. Anyone (Wai? Charles?) have any domain knowledge here? Should gsk be categorically rejecting a root certificate that claims to be PKIX-compliant, or only if TLSv1.3 is supported? I'm less interested in getting it fixed if it's wrong, since there's obvious significant risk of breaking a lot of existing, working connections-plus as folks move to TLSv1.3 they'll fix it anyway-than I am in feeling that we can confidently tell customers who hit this "Yes, that's a requirement of [TLSv1.3? TLS in general, but IBM only enforces it for 1.3? something else?]", and not that it's a peculiarity of our implementation. Put another way, the surprise (after reading the RFC and thinking I understand it!) is that it breaks when it does-that a non-BC certificate ever works. Should it? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
