Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Strange behavior processing SSL certs between a Windows 11 system running Python 3.13.1 and a Windows 10 system running Python 3.8.5
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jeffrey Walton via curl-users <curl-users_at_lists.haxx.se>
Date: Sat, 28 Dec 2024 18:49:26 -0500
On Sat, Dec 28, 2024 at 4:50 PM Dick Brooks via curl-users
<curl-users_at_lists.haxx.se> wrote:
>
> That certainly fits with the scenario I’m seeing between Win 11 and Win 10 installations.
>
>
>
> Looks like a libcurl update is in order for my software deployment.
>
>
>
> Thank you very much for helping to resolve this.
>
>
>
> Well done, Sir.
For completeness, the RFC's state the web server's certificate comes
first in the order, followed by CA certificates needed to validate the
preceding certificate. If WIndows is not presenting that way, then it
is a WIndows bug.
From RFC 5246, TLS 1.2, Section 7.4.2. Server Certificate:
When this message will be sent:
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon). This message will always immediately follow the
ServerHello message.
...
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
RFC 8446, TLS 1.3, has similar language. But in Section 4.4.2.
Certificate, the RFC says this:
Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
Jeff
Date: Sat, 28 Dec 2024 18:49:26 -0500
On Sat, Dec 28, 2024 at 4:50 PM Dick Brooks via curl-users
<curl-users_at_lists.haxx.se> wrote:
>
> That certainly fits with the scenario I’m seeing between Win 11 and Win 10 installations.
>
>
>
> Looks like a libcurl update is in order for my software deployment.
>
>
>
> Thank you very much for helping to resolve this.
>
>
>
> Well done, Sir.
For completeness, the RFC's state the web server's certificate comes
first in the order, followed by CA certificates needed to validate the
preceding certificate. If WIndows is not presenting that way, then it
is a WIndows bug.
From RFC 5246, TLS 1.2, Section 7.4.2. Server Certificate:
When this message will be sent:
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon). This message will always immediately follow the
ServerHello message.
...
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
RFC 8446, TLS 1.3, has similar language. But in Section 4.4.2.
Certificate, the RFC says this:
Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
Jeff
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-12-29