Re: [Interest] SSL & Let's Encrypt certificate expiration
On Thu, 7 Oct 2021, Christophe THOMAS wrote: > So without the flag OpenSSL would use another store ? One located > locally or embedded inside OpenSSL? No. If you look at the patch, the flag merely enables that, for any certificate encountered, it first looks whether the Issuer is found in the local root certificate store, and if so, that’s it, chain accepted. Without this, it first traverses the chain up to *its* root, which here is the expired X3, because the X1-signed-by-X3 is in the chain. With this, it sees R3-signed-by-X1 and X1 is in the local trust store, so it stops verifying there. 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
Hello So without the flag OpenSSL would use another store ? One located locally or embedded inside OpenSSL? Christophe > Le 7 oct. 2021 à 01:37, Thorsten Glaser a écrit : > > On Wed, 6 Oct 2021, Hamish Moffatt via Interest wrote: > >> The OpenSSL blog writes that this unfortunately doesn't happen with >> 1.0.2 though - it sees the expired root and gives up. >> https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ > > http://www.mirbsd.org/cvs.cgi/src/lib/libssl/src/crypto/x509/x509_vfy.c.diff?r1=1.5;r2=1.6 > > This is what I applied to MirBSD’s SSL. Apparently, OpenSSL > does not always trust the local store? They seem to be making > it dependent on X509_V_FLAG_TRUSTED_FIRST. > > With this patch, local files in /etc/ssl/certs/ have precedence. > > 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Wed, 6 Oct 2021, Hamish Moffatt via Interest wrote: > The OpenSSL blog writes that this unfortunately doesn't happen with > 1.0.2 though - it sees the expired root and gives up. > https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ http://www.mirbsd.org/cvs.cgi/src/lib/libssl/src/crypto/x509/x509_vfy.c.diff?r1=1.5;r2=1.6 This is what I applied to MirBSD’s SSL. Apparently, OpenSSL does not always trust the local store? They seem to be making it dependent on X509_V_FLAG_TRUSTED_FIRST. With this patch, local files in /etc/ssl/certs/ have precedence. 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Wed, 6 Oct 2021, Thiago Macieira wrote: > On Wednesday, 6 October 2021 09:55:21 PDT Thorsten Glaser wrote: > > 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… > > Can you share the change? I also use dehydrated. Sure: https://github.com/MirBSD/dehydrated/tree/stable/docs/examples I use a setup in which I run dehydrated as unprivileged user _acme and use one of the hookscripts (debian-hook*.sh will probably be closest to what you want) which is then allowed to do passwordless sudo to the corresponding cert script (debian-cert.sh) which first checks the cert and chain received from LE (as user nobody) to avoid installing 0-byte certificate files (which others, who symlink from /var/lib/dehydrated/, have reported) and only then installs them to standard locations. The last commit there just lets it skip that particular entry of the chain. If you have any questions, feel free to respond to me also privately. 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
On 7/10/21 02:53, Thiago Macieira wrote: On Wednesday, 6 October 2021 02:41:39 PDT Hamish Moffatt via Interest wrote: I upgraded to 1.0.2u and added the X1 root directly to Qt. Now the application works. But the instructions from OpenSSL say to also remove the X3 root which I'm not able to do (it's loaded from Windows), so I am puzzled by why this works. I have not done anything special when generating my certificates like requesting the alternate certificate chain. 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. The OpenSSL blog writes that this unfortunately doesn't happen with 1.0.2 though - it sees the expired root and gives up. https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ Hamish ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
On 7/10/21 02:48, Thiago Macieira wrote: On Tuesday, 5 October 2021 17:03:43 PDT Hamish Moffatt via Interest wrote: We have had some difficulty here with Windows 10's "lazy loading" of the root certificates. Unless users have been to a site that uses the ISRG X1 root certificate using Chrome or Edge, they do not have this certificate and it is not available to Qt. As soon as they visit a site that uses the new root in Chrome or Edge, Windows loads the certificate and it works in Qt. Interesting. That means there's an API that they're using that causes Windows to download the certificate, but we don't use it. Can one of you file a bug on this particular issue on Windows? Done, QTBUG-97168. Hamish ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Wednesday, 6 October 2021 09:55:21 PDT Thorsten Glaser wrote: > 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… Can you share the change? I also use dehydrated. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
I vaguely understand that, but that is not my question. My question is why forcing the loading of systemCACertificates() works. --Philippe Le 06-10-2021 20:28, Thorsten Glaser a écrit : On Wed, 6 Oct 2021, maitai wrote: old Ubuntu 16.04 VM. ca-certificates (20160104ubuntu1) does not have the ISRG X1 root: (xenial)# ls -l /etc/ssl/certs/6187b673.0 /etc/ssl/certs/4042bcee.0 ls: cannot access '/etc/ssl/certs/6187b673.0': No such file or directory ls: cannot access '/etc/ssl/certs/4042bcee.0': No such file or directory Make sure to upgrade: # apt-cache policy ca-certificates ca-certificates: Installed: 20160104ubuntu1 Candidate: 20210119~16.04.1 Version table: 20210119~16.04.1 500 500 http://archive.ubuntu.com/ubuntu xenial-security/main amd64 Packages *** 20160104ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status You’ll need to have xenial-security in your sources.list, then you should be getting 20210119~16.04.1 with regular security updates, which you, of course, do regularily, right? ☻ bye, //mirabilos ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Wed, 6 Oct 2021, maitai wrote: > old Ubuntu 16.04 VM. ca-certificates (20160104ubuntu1) does not have the ISRG X1 root: (xenial)# ls -l /etc/ssl/certs/6187b673.0 /etc/ssl/certs/4042bcee.0 ls: cannot access '/etc/ssl/certs/6187b673.0': No such file or directory ls: cannot access '/etc/ssl/certs/4042bcee.0': No such file or directory Make sure to upgrade: # apt-cache policy ca-certificates ca-certificates: Installed: 20160104ubuntu1 Candidate: 20210119~16.04.1 Version table: 20210119~16.04.1 500 500 http://archive.ubuntu.com/ubuntu xenial-security/main amd64 Packages *** 20160104ubuntu1 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status You’ll need to have xenial-security in your sources.list, then you should be getting 20210119~16.04.1 with regular security updates, which you, of course, do regularily, right? ☻ 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
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
Re: [Interest] SSL & Let's Encrypt certificate expiration
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
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Wednesday, 6 October 2021 02:41:39 PDT Hamish Moffatt via Interest wrote: > I upgraded to 1.0.2u and added the X1 root directly to Qt. Now the > application works. But the instructions from OpenSSL say to also remove > the X3 root which I'm not able to do (it's loaded from Windows), so I am > puzzled by why this works. I have not done anything special when > generating my certificates like requesting the alternate certificate chain. 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. The other way is to reissue everything with new roots and update EVERYTHING before the earliest expiration. That's far more work, but clearly has fewer issues. > I have Qt 5.15 (OpenSSL 1.1) applications deployed on Debian 10 and have > not had to do anything to keep that working. Same here for everything on my up-to-date Linux. The only reason I know this is happening is an Android application (Blackberry Hub). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Tuesday, 5 October 2021 17:03:43 PDT Hamish Moffatt via Interest wrote: > We have had some difficulty here with Windows 10's "lazy loading" of the > root certificates. Unless users have been to a site that uses the ISRG > X1 root certificate using Chrome or Edge, they do not have this > certificate and it is not available to Qt. As soon as they visit a site > that uses the new root in Chrome or Edge, Windows loads the certificate > and it works in Qt. Interesting. That means there's an API that they're using that causes Windows to download the certificate, but we don't use it. Can one of you file a bug on this particular issue on Windows? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
On 6/10/21 20:02, Christophe Thomas wrote: Thank you for the hint, I found this link that talks about it: https://community.letsencrypt.org/t/isrg-root-lazy-loading-problem-missing-from-random-updated-windows-10-versions/141550/2 We've also tested on an old linux (ubuntu 16), when trying to connect one test website, openssl is not finalizing the connection due to expired DST Root X3, and we can see that the chain is website cert => ISRG X1 root => DST Root X3 doing the same test with our own software (that uses our own shipped lib for openssl) from scratch we fail and we can see we use the same chain as above. Third test still with our software but forcing loading the ca cert before first connexion (see first email from maitai => def.setCaCertificates(QSslConfiguration::systemCaCertificates());) In this case we still have the same chain reported, but with DST Root X3 expire in 2024 and the connexion is OK Also on this device, we find the ISRG_Root_X3.pem that is expired. We still support an old version of our app shipped with Qt 5.8 and OpenSSL 1.0.1. This stopped working when the X3 root expired, as expected. I upgraded to 1.0.2u and added the X1 root directly to Qt. Now the application works. But the instructions from OpenSSL say to also remove the X3 root which I'm not able to do (it's loaded from Windows), so I am puzzled by why this works. I have not done anything special when generating my certificates like requesting the alternate certificate chain. I have Qt 5.15 (OpenSSL 1.1) applications deployed on Debian 10 and have not had to do anything to keep that working. Hamish ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
Thank you for the hint, I found this link that talks about it: https://community.letsencrypt.org/t/isrg-root-lazy-loading-problem-missing-from-random-updated-windows-10-versions/141550/2 We've also tested on an old linux (ubuntu 16), when trying to connect one test website, openssl is not finalizing the connection due to expired DST Root X3, and we can see that the chain is website cert => ISRG X1 root => DST Root X3 doing the same test with our own software (that uses our own shipped lib for openssl) from scratch we fail and we can see we use the same chain as above. Third test still with our software but forcing loading the ca cert before first connexion (see first email from maitai => def.setCaCertificates( QSslConfiguration::systemCaCertificates());) In this case we still have the same chain reported, but with DST Root X3 expire in 2024 and the connexion is OK Also on this device, we find the ISRG_Root_X3.pem that is expired. So this is a bit puzzling Christophe Le mer. 6 oct. 2021 à 02:06, Hamish Moffatt via Interest < interest@qt-project.org> a écrit : > On 6/10/21 06:13, Thiago Macieira wrote: > > On Tuesday, 5 October 2021 11:45:23 PDT Christophe Thomas wrote: > >> For the cert chain we are currently using the default LE setting so we > >> currently provide the X1 Cross signed with expired X3. > >> > >> Netherless, the issue is that strangely we need to force caCertificate > load > >> in order to have the connexion accepted. > > In the client's system, is the ISRG Root X1 certificate present? Can you > check > > with plain openssl s_client command to see if the problem is OpenSSL? > > > > We have had some difficulty here with Windows 10's "lazy loading" of the > root certificates. Unless users have been to a site that uses the ISRG > X1 root certificate using Chrome or Edge, they do not have this > certificate and it is not available to Qt. As soon as they visit a site > that uses the new root in Chrome or Edge, Windows loads the certificate > and it works in Qt. > > > > Hamish > > ___ > 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
On 6/10/21 06:13, Thiago Macieira wrote: On Tuesday, 5 October 2021 11:45:23 PDT Christophe Thomas wrote: For the cert chain we are currently using the default LE setting so we currently provide the X1 Cross signed with expired X3. Netherless, the issue is that strangely we need to force caCertificate load in order to have the connexion accepted. In the client's system, is the ISRG Root X1 certificate present? Can you check with plain openssl s_client command to see if the problem is OpenSSL? We have had some difficulty here with Windows 10's "lazy loading" of the root certificates. Unless users have been to a site that uses the ISRG X1 root certificate using Chrome or Edge, they do not have this certificate and it is not available to Qt. As soon as they visit a site that uses the new root in Chrome or Edge, Windows loads the certificate and it works in Qt. Hamish ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Tuesday, 5 October 2021 12:28:17 PDT Christophe Thomas wrote: > one trick is that we had to provide the openssl lib with our soft in order > to work on some of our users setup. So we might relly in our app on a > different openssl version than the one installed, making the test with > openssl binary useless I guess. This OpenSSL library you're providing, where is it loading certificates on- demand from? Or is it? You may have misconfigured the path to search certificates from when you built it. Please check if this issue affects only the users using the library you shipped or if it affects the users using the system provided library. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
I can't reproduce the issue, only maitai (and some users) does, we'll check the status of his ca cert. one trick is that we had to provide the openssl lib with our soft in order to work on some of our users setup. So we might relly in our app on a different openssl version than the one installed, making the test with openssl binary useless I guess. Regards, Christophe Le mar. 5 oct. 2021 à 21:16, Thiago Macieira a écrit : > On Tuesday, 5 October 2021 11:45:23 PDT Christophe Thomas wrote: > > For the cert chain we are currently using the default LE setting so we > > currently provide the X1 Cross signed with expired X3. > > > > Netherless, the issue is that strangely we need to force caCertificate > load > > in order to have the connexion accepted. > > In the client's system, is the ISRG Root X1 certificate present? Can you > check > with plain openssl s_client command to see if the problem is OpenSSL? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Tuesday, 5 October 2021 11:45:23 PDT Christophe Thomas wrote: > For the cert chain we are currently using the default LE setting so we > currently provide the X1 Cross signed with expired X3. > > Netherless, the issue is that strangely we need to force caCertificate load > in order to have the connexion accepted. In the client's system, is the ISRG Root X1 certificate present? Can you check with plain openssl s_client command to see if the problem is OpenSSL? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] SSL & Let's Encrypt certificate expiration
Hello, For the cert chain we are currently using the default LE setting so we currently provide the X1 Cross signed with expired X3. Netherless, the issue is that strangely we need to force caCertificate load in order to have the connexion accepted. Regards, Christophe Le mar. 5 oct. 2021 à 19:58, ekke a écrit : > Please check if the certificate at server is correct created and uses ISRG > Root X1 instead of DST Root CA X3 > > ekke > > Am 05.10.21 um 19:29 schrieb maitai: > > Hi all, > > Since the Let's Encrypt root certificate expired, we have a few users > unable to initiate a SSL connexion (most of them on recent Windows 10 > version, app built with qt 5.15.6, but also some linux cases). We are using > OpenSSL 1.1.1. > > After some searches, we found out that the ca-certificates list is empty > in that cases. In some Linux occurrences, the list becomes "loaded" after > around 10 minutes, and all was fine until the user restarts the > application. In some other cases waiting does nothing to fix the issue. > > I must say that most users are OK, it impacted only a few of them, and I > was not able to find a common pattern like Windows version or so. > > What we did finally to fix it is to force the loading of CA-Certificates, > that way, during the initialization of the application: > > QSslConfiguration def = QSslConfiguration::defaultConfiguration(); > def.setCaCertificates(QSslConfiguration::systemCaCertificates()); > QSslConfiguration::setDefaultConfiguration(def); > > And then all is fine. > > > I am still scratching my head about this though. Isn't it supposed to be > useless to do that? Any insight on what is going on there will be > appreciated. > > Thanks > Philippe Lelong. > > ___ > Interest mailing > listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest > > > ___ > 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
Please check if the certificate at server is correct created and uses ISRG Root X1 instead of DST Root CA X3 ekke Am 05.10.21 um 19:29 schrieb maitai: Hi all, Since the Let's Encrypt root certificate expired, we have a few users unable to initiate a SSL connexion (most of them on recent Windows 10 version, app built with qt 5.15.6, but also some linux cases). We are using OpenSSL 1.1.1. After some searches, we found out that the ca-certificates list is empty in that cases. In some Linux occurrences, the list becomes "loaded" after around 10 minutes, and all was fine until the user restarts the application. In some other cases waiting does nothing to fix the issue. I must say that most users are OK, it impacted only a few of them, and I was not able to find a common pattern like Windows version or so. What we did finally to fix it is to force the loading of CA-Certificates, that way, during the initialization of the application: QSslConfiguration def = QSslConfiguration::defaultConfiguration(); def.setCaCertificates(QSslConfiguration::systemCaCertificates()); QSslConfiguration::setDefaultConfiguration(def); And then all is fine. I am still scratching my head about this though. Isn't it supposed to be useless to do that? Any insight on what is going on there will be appreciated. Thanks Philippe Lelong. ___ 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
Re: [Interest] SSL & Let's Encrypt certificate expiration
On Tuesday, 5 October 2021 10:29:09 PDT maitai wrote: > Hi all, > > Since the Let's Encrypt root certificate expired, we have a few users > unable to initiate a SSL connexion (most of them on recent Windows 10 > version, app built with qt 5.15.6, but also some linux cases). We are > using OpenSSL 1.1.1. Being slightly pedantic for future reference: no Let's Encrypt CA certificate expired. What expired was one of the root certificates that signed Let's Encrypt. It's not the only certificate, so Let's Encrypt continues to be valid. > After some searches, we found out that the ca-certificates list is empty > in that cases. In some Linux occurrences, the list becomes "loaded" > after around 10 minutes, and all was fine until the user restarts the > application. In some other cases waiting does nothing to fix the issue. We don't pre-load the CA certificate list and haven't done that for years. We rely on OpenSSL loading exactly the certificates it needs on its own. > I am still scratching my head about this though. Isn't it supposed to be > useless to do that? Any insight on what is going on there will be > appreciated. Needs investigation. I don't understand what's wrong either. In my case, I noticed that one application on my Android phone was complaining of an expired certificate for my server. After debugging a lot, I found that my IMAP server (Cyrus) was including the expired certificate in the list of certificates it sent the client, but the SMTP and HTTPS servers weren't. So I worked to hack the OpenSSL certificate database so it wouldn't send it. It didn't work. As far as I can tell, in this case, the client application found the expired signing certificate in its own database and decided to complain, despite having another path to a valid root certificate. But this points to the possible problem: it might depend on whether the server is including this expired certificate in the connection negotiation or not. You can test with "openssl s_client -connect host:port -showcerts" and decode each one of the ones printed with "openssl x509 -text -noout" to see if the expired one is present or not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
