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
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
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
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
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
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".
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
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
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
(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
(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
11 matches
Mail list logo