Envars (was: RFC3280 (and 5280), "Basic Constraints" set to Critical)

2023-12-18 Thread Phil Smith III
Now that we've gotten to clarify on the Basic Constraints thing (TL;DR: the RFCs require it; System SSL does not, prior to TLSv1.3; for LE at least, an ENVAR can override it), I have a follow-on question: Can I set an environment variable outside of LE and have it apply to the LE enclave? Ou

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-14 Thread Phil Smith III
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

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-14 Thread Phil Smith III
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

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-11 Thread Rick Troth
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 say

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-11 Thread Phil Smith III
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

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-10 Thread Phil Smith III
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".

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-10 Thread Peter Sylvester
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 know

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-09 Thread Phil Smith III
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 mess

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-09 Thread Peter Sylvester
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 produ

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-08 Thread Rick Troth
(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 (henc

RFC3280 (and 5280), "Basic Constraints" set to Critical

2023-12-08 Thread Phil Smith III
(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_extensio