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@qt-project.org
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
