[Interest] Problems with Qt 5.15.6 on windows when discovering details of a Bluetooth LE service

[Michael Heiser | SYSTRONIK Elektronik und Systemtechnik GmbH]

Hello Specialists,

I have problems regarding crashes or application hangs on windows 10
with QT 5.15.6 and Bluetooth LE and our own peripherals.
We have investigated this on old and also on
newer pc hardware. When doing a lowEnergyService discoverDetails() the CPU on
each core goes for seconds to 100% which could cause a deadlock in our app on
old hardware. On newer hardware the process of discoverDetails() goes often
good.
After the connect and the service discovery on our bluetooth peripheral with
lowenergyscanner when clicking on the service I can reproduce the high CPU
load. It needs about 5 seconds to query all the Characteristics of the
service, while querying the CPU load is that high on all cores.

By the way we have in this specifical BLE service 13 characteristics and
before reading the characteristics of this custom service we query
DeviceInformation service with 9 characteristics.

With Qt 5.12 the query of the same service of our peripheral was okay. So what
do you suggest to do?

I need to go on with Qt 5.15.6 because we have to launch a recent update on
Android within the same code base and I have already made the necessary
changes to QML files.

Android and IOS by the way are working super. Do you have any advice how to go
on? What I definitely not want is to have two source bases Qt 5.15.6 for
mobile and Qt 5.12.11 for Windows.

Mit freundlichen Grüßen  |  With best regards

Michael Heiser
Softwareentwicklung

Phone: +49 (0) 7558 / 9206-53
Email:   hei...@systronik.de
Web:www.systronik.com

[cid:image001.png@01D7BB4F.489D5540]





SYSTRONIK Elektronik u. Systemtechnik GmbH, Gewerbestr. 57, D-88636 Illmensee
Registergericht Ulm - HRB 710423, Sitz der Gesellschaft Illmensee, USt-IdNr. DE 
811 264 405
Geschäftsführer: Dipl.-VW Elmar Fritz, Ing. Ramon J. van Tuijl, Dipl.-Ing. (FH) 
Richard Skoberla

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder die E-Mail irrtümlich erhalten 
haben, informieren
Sie bitte sofort den Absender und löschen Sie die E-Mail. Das unerlaubte 
Kopieren sowie die unbefugte Weitergabe der E-Mail ist nicht gestattet.

This e-mail may contain confidential and / or privileged information. If you 
are not the intended recipient or the e-mail may contain error, inform you 
immediately ask the sender and delete the e-mail. Unauthorized copying, 
unauthorized disclosure of e-mail is strictly forbidden.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] SSL & Let's Encrypt certificate expiration

[Thorsten Glaser]

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

[Thorsten Glaser]

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

[Hamish Moffatt via Interest]

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

[Hamish Moffatt via Interest]

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

[Thiago Macieira]

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

[maitai]

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

[Thorsten Glaser]

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

[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@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

[Thorsten Glaser]

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

[Thiago Macieira]

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

[Thiago Macieira]

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] QtCreator 5.0.1 bug

[Mike Chinander]

QtCreator 5.0.2 is supposed to fix this.
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/dist/changes-5.0.2.md?h=5.0

On Wed, Oct 6, 2021 at 9:51 AM Nuno Santos 
wrote:

> Hi,
>
> Is just me or we can’t cancel builds on the latest QtCreator?
>
> When I choose to cancel a build, the build stops, but I can’t trigger a
> new build unless I close QtCreator and start it over again.
>
> Is anyone else having this problem?
>
> Regards,
>
> Nuno
> ___
> 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

[Interest] QtCreator 5.0.1 bug

[Nuno Santos]

Hi,

Is just me or we can’t cancel builds on the latest QtCreator? 

When I choose to cancel a build, the build stops, but I can’t trigger a new 
build unless I close QtCreator and start it over again.

Is anyone else having this problem?

Regards,

Nuno
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] SSL & Let's Encrypt certificate expiration

[Hamish Moffatt via Interest]

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

[Christophe Thomas]

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