On 08/12/2023 17:36, Phil Smith III wrote:
(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
There is a difference between what you must set and what you must verify. 5280/3280 is clear (IMO)
about that.
when you verify a cert, AND you know about the extension, you just verify the extension and don't
care about the critical bit
Since the error message seems to indicate that the extension is known, the verifier has no reason to
checjk the criticality bit.
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).
The RFC path validation does not usea selfsignedroot certificate. The only necessary thing for an
implementation is to have an association between a subject an a public key.
A self signed cert is just handy.
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.
what is suggesting this?
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.
SNI is used to identify a server, and in particular, the cert (chain) to be
presented to the client.
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?
Does you product work with TLS 1.2?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
