Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
Oh. It does say: "If TLS V1.3 is negotiated for a secure connection, certificate validation is done according to RFC 5280 unless explicitly specified." but also still says "The default value is ANY." That seems a tad bit unclear, should be more like: " The default value is ANY, unless TLS V1.3 is negotiated for a secure connection, in which case certificate validation is done according to RFC 5280 unless explicitly specified." In the meantime, I've verified that adding the environment variable fixes it, so I'm good! Thanks again to all. This all harkens back to two long-departed cow-orkers, who said: Hansen's Law: It's always a certificate problem. Weald's Corollary: Even when it's not a certificate problem, it's a certificate problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
Chris Meyer wrote: >I checked with the System SSL folks on this. >It sounds like what you're observing is a difference in default System >SSL certificate validation mode settings Between TLSv1.2 and TLSv1.3. >See the description of the System SSL GSK_CERT_VALIDATION_MODE >parameter in this table: >https://www.ibm.com/docs/en/zos/3.1.0?topic=programming-environment-variables. >Note that the default for TLSv1.2 (and earlier) is ANY, which initally >validates against RFC 2459 which has the relaxed requirements >regarding the critical bit. For TLSv1.3, however, System SSL defaults >to RFC 5280 checking which requires the critical bit to be set. >Based on what you've said in this thread, I'm assuming that you have >not specified a value for GSK_CERT_VALIDATION_MODE, as that would >result in the behavior you described. Ah HAH -- this has to be it! An no, we are not specifying a GSK_CERT_VALIDATION_MODE. All the doc says ANY is and remains the default. Are you saying that the default silently changes when it's TLSv1.3? If so, is that a code bug or a doc bug? It looks like an environment variable can change that setting, too. I'm going to see if I can get someone to replace the certificate with the "bad" one and try that. If that'll get us around it, we'll be good--if some customer hits it, we can say "Add this" and they'll be good to go. As I think I wrote before, I'm not all that worried about that happening, since any real modern root cert SHOULD have BC set correctly, but it would be good to know. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
On 12/11/23 10:13, Phil Smith III wrote: Charles wrote: The critical bit is there to provide upward compatibility for certificates, which are a standard that is implemented in everything >from z/OS to Nest Thermostats to Balckberrys that have not been updated in ten years. The critical bit says "this extension really matters. If you don't know what this extension is all about, if you don't recognize it, if it is a newer standard than your implementation, then you must reject this certificate." So it seems to me to be really fussy pedantry for a TLS implementation (yes, GSK) to say "I recognize that extension, but you were SUPPOSED to set the critical bit, so nanner, nanner, I am rejecting it." OK, I agree, but I still don't know whether that makes it a bug or what. If it's WRONG (*and* if no one has functional dependency on that "wrong" behavior, which we hope they don't) then it's a bug. Alan's comment: While I wouldn't be surprised to find certificate validation fixes in the same release that has TLS 1.3 (it tightened up various security aspects), I would be surprised to find those fixes not applying to older protocols. ...also seems trenchant: even if it IS considered correct behavior, why just for TLSv1.3? And that too. Consistency across protocol levels would be a Good Thing. IBM needs to either make GSK consistent here or splain to you why it's not consistent. Hoping someone from gsk-land in IBM can chime in here. I don't have the ability to open a PMR these days. ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
Charles wrote: >The critical bit is there to provide upward compatibility for >certificates, which are a standard that is implemented in everything >from z/OS to Nest Thermostats to Balckberrys that have not been >updated in ten years. >The critical bit says "this extension really matters. If you don't >know what this extension is all about, if you don't recognize it, if >it is a newer standard than your implementation, then you must reject >this certificate." >So it seems to me to be really fussy pedantry for a TLS implementation >(yes, GSK) to say "I recognize that extension, but you were SUPPOSED >to set the critical bit, so nanner, nanner, I am rejecting it." OK, I agree, but I still don't know whether that makes it a bug or what. Alan's comment: >While I wouldn't be surprised to find certificate validation fixes in >the same release that has TLS 1.3 (it tightened up various security >aspects), I would be surprised to find those fixes not applying to >older protocols. ...also seems trenchant: even if it IS considered correct behavior, why just for TLSv1.3? Hoping someone from gsk-land in IBM can chime in here. I don't have the ability to open a PMR these days. ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
Charles Mills wrote, in part: >Confirming: >The complaint was at the client end. The client is z/OS. The complaint >was that the CA root had a Basic Constraints extension that was not >marked as critical? Yes. And that it only seems to matter to gsk when the client says "I can do TLSv1.3". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
Ok. RFC 5820 is clear (not necessarily cristal clear) but anyway: 1: Read the introduction about extensions. In short and by doing some boolean logic manip: If you know how to treat an extension, the criticality bit is irrelevant for the verification. Since the implementation in question knows about BC, it should never ever look at the critbit in *ANY* cert. It just looks whether it is a CA, and if path length is ok. 2: The verification algorithm is outlined in detail. Look at the input. It is basically a public key+algo + an identity. Not a cert. No extensions, etc. One should be able to use X509 version 1 cert as a container for the root pubkey. On 10/12/2023 04:17, Phil Smith III wrote: Peter Sylvester wrote, in part: T what is suggesting this? If by "this" you mean "what is suggesting 'But this doesn't seem to be true until we add the TLSv1.3 support'" then it's that the old version, which doesn't do TLSv1.3, didn't get the BC error with the You wrote that there is a suggesting to reject non-pkix conformant certs. Where is that? Not in the path verification. Does you product work with TLS 1.2? Yes. Has for years. Both old and new versions. Good. So to recap, my perception is that if the client doesn't say "I can do TLSv1.3", BC doesn't matter; if it does say so, BC matters. I think you should ask IBM about this change in behaviour. I have not followed the CA forum btw. I prefer to go to the beach (200m) or the alpes (25km) :-) best Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
Peter Sylvester wrote, in part: >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. By "when you verify a cert" you mean gsk, and that it shouldn't care about the critical 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? If by "this" you mean "what is suggesting 'But this doesn't seem to be true until we add the TLSv1.3 support'" then it's that the old version, which doesn't do TLSv1.3, didn't get the BC error with the same cert. >SNI is used to identify a server, and in particular, the cert (chain) >to be presented to the client. Right, I know.I was just noting that this was another change between versions, in case there was some interaction. >Does you product work with TLS 1.2? Yes. Has for years. Both old and new versions. So to recap, my perception is that if the client doesn't say "I can do TLSv1.3", BC doesn't matter; if it does say so, BC matters. I feel dense, but I'm not sure what to conclude from what you wrote-whether you're suggesting that gsk is doing something wrong or not. Or maybe you hadn't presented a conclusion yet, pending my answers above! Appreciate the input, hoping for more. .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
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 tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFC3280 (and 5280), "Basic Constraints" set to Critical
(replying via IBM-MAIN; where'd my IBMTCP-L subscription go?) Apologies that I don't have a *solution*. But hopefully this observation is more than just bitch-n-moan. > 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). That would seem to throw the burden on the CAs. Not your problem anymore? As an industry, we have a problem with planned obsolescence. We think it's healthy. (And "we" used to think smoking tobacco was healthy. Go figure.) Some changes as the protocols evolve (and code evolves) carry intentional breakage, trying to force you to get away from old stuff. (Doesn't matter if the risk from the "old stuff" is acceptable, you're a heretic for staying back-level. We're gonna make it hurt.) Linus Torvalds has a reputation for being hard to work with. It's been said that he regularly berates other kernel developers ... publicly ... with invective. But to his credit, it's also been said that he comes down harder on developers who break the non-kernel experience. In one example, if people depend on a bug in your ABI, it's no longer a bug but a feature. Carry this to TCP land: So then we're all happily up-to-date with TLS 1.2 and along comes TLS 1.3 and ... bzzzttt!!! IBM gets an extra hour in detention over this. They're known to follow the rules ... to a fault. I confess that I haven't read "the rules" (e.g., RFC 5280, et al), but there have been significant cases where other systems worked fine but the IBM system did not. (I'm thinking of an certain problem with the AIX TCP stack versus F5 load balancers which Phil might remember.) Other vendors deliver wares which behave more as expected, rightly or wrongly. In trying to help, the question which comes to mind is: where do you see the error? Is it on z/OS or on the other end? And does it really help to fix the root cert? Have you uncovered a bug in TLS 1.3? (And do the TLS 1.3 lords consider it a bug or a feature?) -- R; <>< On 12/8/23 11: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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
