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

From: Dick Brooks via curl-users <curl-users_at_lists.haxx.se>
Date: Sun, 29 Dec 2024 08:03:51 -0500

Jeff,

Thanks for the deep research on this matter. It certainly does appear that the subscribers certificate should be the first one delivered in the sequence.

I'm going to update libcurl to see if the results match Windows 10 behavior on a Windows 11 machine.

Thanks,

Dick Brooks
   
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and report! ™
Risk always exists, but trust must be earned and awarded.™
https://businesscyberguardian.com/
Email: dick_at_businesscyberguardian.com
Tel: +1 978-696-1788


-----Original Message-----
From: Jeffrey Walton <noloader_at_gmail.com>
Sent: Saturday, December 28, 2024 6:49 PM
To: dick_at_businesscyberguardian.com; curl-users - the curl tool <curl-users_at_lists.haxx.se>
Subject: 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

 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.html

Received on 2024-12-29