[Interest] SSL & Let's Encrypt certificate expiration

[maitai]

OK, this is a SSL/TLS specialists debate and I am not, I just have 
simple questions.

What I see:
On Linux 16.04/Qt 5.11.3/SSL 1.0.2g

If I force the loading of systemCa into the default SSL configuration 
all is OK

     QSslConfiguration def = QSslConfiguration::defaultConfiguration();
     def.setCaCertificates(QSslConfiguration::systemCaCertificates());
     QSslConfiguration::setDefaultConfiguration(def);


If I remove these lines it reports certificate expired and it does not 
work. Can someone explain this?

My problem as you can guess is that I cannot reproduce it except on this 
old Ubuntu 16.04 VM.

The fact is that we do have some (5% ?) of users running latest/updated 
W10 versions with a 5.15.6 build and SSL 1.1.1 hitting the same issue. 
There is one case on Raspberry too. Some of same have cured magically 
after a while without doing anything. Some others are still locked.I 
have send a patch version to one of them (Windows 10, etc) containing 
the code above. It worked. But now for this user all is working 
including regular version and even older ones, so I don't know if I 
trigger something or if just in between something else changed on LE or 
Windows side. And I just have a suspect Android report too.

I have many questions, but the first one is how these loading of 
systemCaCertificates() can work on the 16.04 VM machine?

--Philippe.




Le 06-10-2021 18:55, Thorsten Glaser a écrit :
> On Wed, 6 Oct 2021, Thiago Macieira wrote:
> 
>> If OpenSSL has any path to a still-valid root certificate, then it can 
>> ignore
>> the others. That's one way of dealing with expirations: you add a new 
>> link in
>> the chain that will continue to be valid when the other path(s) 
>> aren't. You
>> can also prune the tree that isn't necessary any more -- I looked into 
>> what
>> Let's Encrypt has been giving me for months and it hasn't included the
>> expiring certificate in the certchain.pem collection.
> 
> You don’t add root certificates to the chain the server delivers to the
> client though, which creates a problem if the depth changes, like with
> LE:
> 
> LE before:
> 
> server cert ← R3 intermediate ← X1 intermediate ← X3 root
> └─────────────────────────────────────────────┘
> 
> Only those within the bracket are shipped by the server.
> 
> Now X1 is also a root. The client has no way to know that
> *EXCEPT* if it has the X1 certificate in its *root* store
> ahead of time (with a self-signature), because otherwise,
> the X1 certificate shipped by the server has an Issuer that
> is not X1, so it’s obviously not a root certificate (in the
> role the certificate has in that chain).
> 
> Older OpenSSL versions now also fail with this unless patched
> to add the workaround from later OpenSSL versions, namely, that
> if a certificate of the chain is also part of the local root
> store (now a root/intermediate trusted store), it’s accepted.
> 
> This means LE’s transition *cannot* work with lazy loading,
> specifically because the client *cannot* know that there even
> *is* anything to load, because the depth changed.
> 
> The situation would have been different if X1 would now be
> signed by another root, but that would mean every user would
> have needed to get the certificate chain updated at the same
> time. That’s the less likely to succeed variant.
> 
> New LE certificates still ship the X1-signed-by-X3 in their
> chain and fullchain. I’ve reported this to LE, but apparently
> they continue doing so, against the spec (which says root
> certificates shall not be shipped as part of the chain) because
> old Android devices apparently don’t check root certificates’
> expiry date, so the X1-signed-by-X3 continues to work for them.
> 
> On my own servers I’ve adapted my dehydrated hook to remove the
> faulty intermediate, but of course this depends on server admins
> to DTRT, plus it’ll apparently cause more trouble for Android…
> 
> tl;dr: don’t lazy-load the root certificate store, you may never
> know when you’re going to need which certificates.
> 
> bye,
> //mirabilos
> --
> Infrastrukturexperte • tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
> Telephon +49 228 54881-393 • Fax: +49 228 54881-235
> HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander 
> Steeg
> 
>                         
> ****************************************************
> /⁀\ The UTF-8 Ribbon
> ╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr 
> verpassen:
>  ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
> ╱ ╲ header encryption!
>                         
> ****************************************************
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest