Solved QSslSocket how to dump an expired certificate?
-
Hi,
a server I'm connecting to seems to have an expired certificate.Here is my code to handle it and continue the connection:
void Connection::onSslErrors(const QList<QSslError> &errors){ QTextStream &ostream = NntpProxy::acquireLog(iLogPrefix); ostream << "Error SSL Socket:\n"; for(int i=0;i<errors.size();i++) ostream << "\t- #" << errors[i].error() << " : " << errors[i].errorString() << "\n"; NntpProxy::releaseLog(); if (errors.size() == 1 && errors.first().error() == QSslError::CertificateExpired){ static_cast<QSslSocket*>(iSocket)->ignoreSslErrors(); QTextStream &ostream = NntpProxy::acquireLog(iLogPrefix); ostream << "Ignored SSL Certificate:\n"; ostream << errors.first().certificate().toText(); NntpProxy::releaseLog(); } else emit socketError("SSL error..."); }
I'm getting this log:
[2021/10/19 22:44:14] [Thread 0x7fe6d8f17700] NntpConnection[13] Serv[0] Error SSL Socket: - #6 : The certificate has expired [2021/10/19 22:44:14] [Thread 0x7fe6d8f17700] NntpConnection[13] Serv[0] Ignored SSL Certificate:
So the certificate is not dumped, I get nothing with
QSslError::certificate().toText()
Where would be a good place and how can I dump the SSL certificate?
-
well I've dumped both local and peer certificate instead of the one attached to the
QSslError
:ostream << "SSL Peer Certificate: \n" << static_cast<QSslSocket*>(iSocket)->peerCertificate().toText(); ostream << "SSL Local Certificate: \n" << static_cast<QSslSocket*>(iSocket)->localCertificate().toText();
But they don't look expired...
SSL Peer Certificate: Certificate: Data: Version: 3 (0x2) Serial Number: 04:66:b3:fb:70:06:33:7d:f8:6c:d8:d5:2d:7a:74:f7:68:87 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=R3 Validity Not Before: Sep 27 15:21:15 2021 GMT Not After : Dec 26 15:21:14 2021 GMT ... SSL Local Certificate: Certificate: Data: Version: 3 (0x2) Serial Number: f2:e7:4b:2c:57:fb:87:14 Signature Algorithm: sha256WithRSAEncryption Issuer: C=FR, ST=Some-State, L=Paris, O=XXXX Validity Not Before: Dec 2 21:50:15 2015 GMT Not After : Nov 29 21:50:15 2025 GMT ...
any idea why I got this
QSslError::CertificateExpired
? -
Hi,
Did you check the intermediate certificates ?
-
I'm not an expert on SSL handshake... I thought there was just one certificate each side for all the negociation.
How can I print them (intermediate ones) and find out the one that is expired so I could report it to the provider (server)?
That's a shame that the certificate linked to theQSslError
is empty... -
You should use the OpenSSL command directly for that.
See this stack overflow answer to see how to do it.
-
ok thanks,
following your link I managed using openssl to get twice the same certificate and still the same validity dates:Validity Not Before: Sep 27 15:21:15 2021 GMT Not After : Dec 26 15:21:14 2021 GMT
still don't understand why Qt raises me a
QSslError::CertificateExpired
... :$ -
Did you get the full chains of certificates up to the CA ?
-
@SGaist not sure how to do it. I've tried several commands from your link but I ended up with just one certificate.
If you want to give it a try I'm targettingnews.usenetserver.com:563
echo "" | openssl s_client -connect news.usenetserver.com:563 -prexit 2>/dev/null
gives me twice the same certificate.
I got the full details (validity dates) usingecho | openssl s_client -servername news.usenetserver.com -connect news.usenetserver.com:563 2>/dev/null | openssl x509 -text
-
@mbruel said in QSslSocket how to dump an expired certificate?:
Hi,
a server I'm connecting to seems to have an expired certificate.Here is my code to handle it and continue the connection:
void Connection::onSslErrors(const QList<QSslError> &errors){ QTextStream &ostream = NntpProxy::acquireLog(iLogPrefix); ostream << "Error SSL Socket:\n"; for(int i=0;i<errors.size();i++) ostream << "\t- #" << errors[i].error() << " : " << errors[i].errorString() << "\n"; NntpProxy::releaseLog(); if (errors.size() == 1 && errors.first().error() == QSslError::CertificateExpired){
So the certificate is not dumped, I get nothing with
QSslError::certificate().toText()
The if clause that calls QSslCertificate::toText() isn't taken because there are two certificates (based on the posted output), but the code checks
errors().size() == 1
.Where would be a good place and how can I dump the SSL certificate?
Have you tried QSslSocket::peerCertificateChain rather than QSslSocket::peerCertificate?
-
Check certificate chain:
$ openssl s_client -showcerts -verify 5 -connect news.usenetserver.com:563 < /dev/null
At the top, you'll see that there are 3 certificates involved, listed from root to your desired target:
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = usenetserver.com verify return:1
In the command output you'll have also the 3 certificates dumped. If you copy and save such information to text files, removing the EOL chars (just to have a whole line between markers ----- BEGIN CERTIFICATE ------ and ----- END CERTIFICATE ------ you can have details from each certificate:
$ openssl x509 -inform pem -in usenetserver.cer -noout -text | grep -i after Not After : Dec 26 15:21:14 2021 GMT $ openssl x509 -inform pem -in lets_encrypt_R3.cer -noout -text | grep -i after Not After : Sep 15 16:00:00 2025 GMT $ openssl x509 -inform pem -in lets_encrypt_Root.cer -noout -text | grep -i after Not After : Sep 30 18:14:03 2024 GMT
So yes, none of the certificates in the chain seem to be expired.
You may want to check Qt source code (I haven't) just in case the current code is not able to follow a chain of certificates -
@jeremy_k said in QSslSocket how to dump an expired certificate?:
Have you tried QSslSocket::peerCertificateChain rather than QSslSocket::peerCertificate?
No I didn't but just tried. I made a simple project: testSslSock
The syntax is simple 3 args to connect to a Host with SSL.
In fact, I'm getting the sameQSslError::CertificateExpired
whatever the host...I've to precise that this is happening on Qt v5.8.0 with QMake v3.1 and libssl.so.1.0.0. It's NOT happening on my normal env with Qt5.15 and libssl 1.1.
This wasn't happening before... Like one or 2 months ago...
The code didn't change and wasn't recompile.
This error just started to happen.
Any idea?
(PS: it's an app running on an old Debian 8.11)cf my output:
$ ./testSslSock news.usenetserver.com 563 1 > Starting connection to news.usenetserver.com:563 > Connected to server > Starting SSL Handshake Error SSL Socket: - #6 : The certificate has expired Ignored SSL Certificate: nb Certificates: 3 Certificate: Data: Version: 3 (0x2) Serial Number: 04:66:b3:fb:70:06:33:7d:f8:6c:d8:d5:2d:7a:74:f7:68:87 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=R3 Validity Not Before: Sep 27 15:21:15 2021 GMT Not After : Dec 26 15:21:14 2021 GMT Subject: CN=usenetserver.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:b7:ec:24:29:a9:36:a7:f0:c5:e2:f1:30:23:79: 29:e0:24:71:e0:d2:4d:90:92:0d:cb:3e:76:f8:3e: 04:ae:3f:45:ea:f3:9f:b9:44:b0:aa:9b:85:2f:37: b0:e0:24:9c:97:1b:da:48:b0:b8:4c:93:48:9d:f0: bc:c0:17:42:f8:1a:79:02:e7:16:53:9a:80:c3:aa: 8c:34:9f:5a:0a:72:c5:5b:32:9d:e0:41:b8:65:c6: 62:d3:6c:d0:ad:e8:c5:32:4b:f3:91:41:5f:df:95: 0d:3b:e3:cb:8d:0a:bc:f4:1c:94:d7:4c:83:96:17: 62:89:1c:55:d0:b0:90:31:39:f3:60:6a:74:9f:77: 35:ae:b4:f6:79:39:68:98:2d:f7:c6:76:d4:a4:4c: a4:e4:e9:78:7c:dc:0f:f0:8b:31:9b:99:4e:bd:92: c7:64:97:2b:09:0a:33:ad:b0:c0:8d:a0:6a:7a:3e: 34:5a:b8:d9:04:93:3a:1c:7f:fc:a2:6d:9b:8e:34: ee:2d:a6:e8:ee:59:af:5d:56:71:b2:21:75:84:99: d9:37:e2:33:67:fd:b0:76:7f:db:c6:cc:3a:09:1b: 01:ac:b4:27:b6:1c:c8:38:4a:21:79:cd:26:e8:5c: 08:43:fb:1a:61:40:1d:f7:bb:83:4c:24:a9:7f:88: 00:24:fb:16:51:33:48:50:43:5e:95:e3:15:29:95: b6:4f:f6:99:ea:20:97:fb:42:ad:76:b5:57:62:18: 57:89:5c:5c:cf:61:09:b6:e3:4b:98:1b:3b:de:e0: c5:09:72:fe:4c:f4:e5:f0:0d:b9:ba:04:0e:95:3e: 83:81:90:9b:ee:ba:83:84:7d:a1:7c:35:bd:c9:23: 99:ab:cb:f2:76:31:3e:14:38:05:03:c9:f8:c6:8c: 88:e1:6b:c6:2d:46:65:e6:43:96:ec:90:e6:54:24: e8:cf:d7:d9:ee:b5:66:92:6c:8b:4d:0b:b1:db:10: 71:b2:8f:ce:03:04:71:ed:ea:c2:0f:76:bd:c9:1e: e1:89:b3:76:2c:c0:08:9b:bd:95:f1:ce:ce:35:8a: 4b:83:50:60:6c:5a:e5:80:8d:84:e0:2d:1a:20:67: 15:7a:96:b3:8a:81:e9:ec:ed:6e:49:8d:8f:0c:44: bf:07:2c:9e:7e:72:b9:f7:9a:69:ed:1e:47:75:76: f8:db:56:7c:00:3e:33:cc:cf:d1:a6:3e:74:59:ef: b6:94:24:f0:30:37:f4:b1:25:4d:0a:69:c9:1b:b7: f0:9c:ee:db:a4:2f:31:5e:51:c3:ad:ab:dd:01:07: a0:3e:43:9e:d4:b3:d8:aa:e4:45:d7:76:64:e0:f8: 71:68:b1 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: 11:EF:B4:08:87:43:98:9F:81:17:0A:B6:CB:67:5B:A5:3F:3E:33:04 X509v3 Authority Key Identifier: keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6 Authority Information Access: OCSP - URI:http://r3.o.lencr.org CA Issuers - URI:http://r3.i.lencr.org/ X509v3 Subject Alternative Name: DNS:*.ams.usenetserver.com, DNS:*.eu.usenetserver.com, DNS:*.fr7.usenetserver.com, DNS:*.iad.usenetserver.com, DNS:*.usenetserver.com, DNS:usenetserver.com X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.44947.1.1.1 CPS: http://cps.letsencrypt.org 1.3.6.1.4.1.11129.2.4.2: ......v.D.e......@....(.......1.?.3........|(.|v.....G0E. ....p.......c....+yd,...z.2.iN...!........%t|..%TU.:.h........l..E..w.}>.....Uh$....R.y+..x...j.h.~".....|(.}......H0F.!...n.7...@Jz..K..... .........YA..!...1.....x....rT.>.s#7...y....... Signature Algorithm: sha256WithRSAEncryption 77:4c:78:16:c3:9d:5b:31:4b:47:06:63:30:98:c4:0e:e1:09: d7:39:74:b1:57:fa:27:03:74:73:3a:81:52:b7:41:1a:7c:d6: 7a:b4:e1:7c:cf:cd:0a:79:46:d0:21:6a:bb:49:6d:97:df:43: e4:b0:ac:dc:62:ea:ed:0a:e6:b8:5c:df:64:34:ba:fb:f5:e4: 51:f4:4a:ad:eb:0c:67:c6:04:e1:84:54:6a:3d:77:3a:bb:64: b4:40:3a:33:ca:bd:6e:7d:11:06:41:86:5e:df:8a:ae:d4:ee: d2:0c:e7:f8:d8:e3:eb:6a:c2:78:fd:df:f4:67:96:68:dd:51: ef:96:c3:ec:7c:7c:b0:85:c7:c2:97:21:34:34:95:fd:f8:91: 5f:7b:8b:d8:00:0b:bc:a9:8d:d4:87:5f:68:f3:26:ac:26:eb: b5:71:8d:0d:cc:c5:fe:72:fa:e2:c1:95:3c:ed:57:8c:cb:e9: b5:51:ff:35:f1:46:2e:32:9b:eb:8e:6c:f4:93:66:bf:67:44: 02:b9:bb:14:1a:dc:4b:e0:25:1a:b7:f9:f4:9c:96:90:6c:c1: bb:62:54:9c:eb:86:b0:db:71:16:31:76:bc:7c:4e:9c:33:12: af:49:7d:97:57:7e:4b:41:b6:98:db:12:d4:0c:17:2a:ae:6b: a9:13:03:a4 Certificate: Data: Version: 3 (0x2) Serial Number: 91:2b:08:4a:cf:0c:18:a7:53:f6:d6:2e:25:a7:5f:5a Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1 Validity Not Before: Sep 4 00:00:00 2020 GMT Not After : Sep 15 16:00:00 2025 GMT Subject: C=US, O=Let's Encrypt, CN=R3 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:bb:02:15:28:cc:f6:a0:94:d3:0f:12:ec:8d:55: 92:c3:f8:82:f1:99:a6:7a:42:88:a7:5d:26:aa:b5: 2b:b9:c5:4c:b1:af:8e:6b:f9:75:c8:a3:d7:0f:47: 94:14:55:35:57:8c:9e:a8:a2:39:19:f5:82:3c:42: a9:4e:6e:f5:3b:c3:2e:db:8d:c0:b0:5c:f3:59:38: e7:ed:cf:69:f0:5a:0b:1b:be:c0:94:24:25:87:fa: 37:71:b3:13:e7:1c:ac:e1:9b:ef:db:e4:3b:45:52: 45:96:a9:c1:53:ce:34:c8:52:ee:b5:ae:ed:8f:de: 60:70:e2:a5:54:ab:b6:6d:0e:97:a5:40:34:6b:2b: d3:bc:66:eb:66:34:7c:fa:6b:8b:8f:57:29:99:f8: 30:17:5d:ba:72:6f:fb:81:c5:ad:d2:86:58:3d:17: c7:e7:09:bb:f1:2b:f7:86:dc:c1:da:71:5d:d4:46: e3:cc:ad:25:c1:88:bc:60:67:75:66:b3:f1:18:f7: a2:5c:e6:53:ff:3a:88:b6:47:a5:ff:13:18:ea:98: 09:77:3f:9d:53:f9:cf:01:e5:f5:a6:70:17:14:af: 63:a4:ff:99:b3:93:9d:dc:53:a7:06:fe:48:85:1d: a1:69:ae:25:75:bb:13:cc:52:03:f5:ed:51:a1:8b: db:15 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Subject Key Identifier: 14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6 X509v3 Authority Key Identifier: keyid:79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E Authority Information Access: CA Issuers - URI:http://x1.i.lencr.org/ X509v3 CRL Distribution Points: Full Name: URI:http://x1.c.lencr.org/ X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.44947.1.1.1 Signature Algorithm: sha256WithRSAEncryption 85:ca:4e:47:3e:a3:f7:85:44:85:bc:d5:67:78:b2:98:63:ad: 75:4d:1e:96:3d:33:65:72:54:2d:81:a0:ea:c3:ed:f8:20:bf: 5f:cc:b7:70:00:b7:6e:3b:f6:5e:94:de:e4:20:9f:a6:ef:8b: b2:03:e7:a2:b5:16:3c:91:ce:b4:ed:39:02:e7:7c:25:8a:47: e6:65:6e:3f:46:f4:d9:f0:ce:94:2b:ee:54:ce:12:bc:8c:27: 4b:b8:c1:98:2f:a2:af:cd:71:91:4a:08:b7:c8:b8:23:7b:04: 2d:08:f9:08:57:3e:83:d9:04:33:0a:47:21:78:09:82:27:c3: 2a:c8:9b:b9:ce:5c:f2:64:c8:c0:be:79:c0:4f:8e:6d:44:0c: 5e:92:bb:2e:f7:8b:10:e1:e8:1d:44:29:db:59:20:ed:63:b9: 21:f8:12:26:94:93:57:a0:1d:65:04:c1:0a:22:ae:10:0d:43: 97:a1:18:1f:7e:e0:e0:86:37:b5:5a:b1:bd:30:bf:87:6e:2b: 2a:ff:21:4e:1b:05:c3:f5:18:97:f0:5e:ac:c3:a5:b8:6a:f0: 2e:bc:3b:33:b9:ee:4b:de:cc:fc:e4:af:84:0b:86:3f:c0:55: 43:36:f6:68:e1:36:17:6a:8e:99:d1:ff:a5:40:a7:34:b7:c0: d0:63:39:35:39:75:6e:f2:ba:76:c8:93:02:e9:a9:4b:6c:17: ce:0c:02:d9:bd:81:fb:9f:b7:68:d4:06:65:b3:82:3d:77:53: f8:8e:79:03:ad:0a:31:07:75:2a:43:d8:55:97:72:c4:29:0e: f7:c4:5d:4e:c8:ae:46:84:30:d7:f2:85:5f:18:a1:79:bb:e7: 5e:70:8b:07:e1:86:93:c3:b9:8f:dc:61:71:25:2a:af:df:ed: 25:50:52:68:8b:92:dc:e5:d6:b5:e3:da:7d:d0:87:6c:84:21: 31:ae:82:f5:fb:b9:ab:c8:89:17:3d:e1:4c:e5:38:0e:f6:bd: 2b:bd:96:81:14:eb:d5:db:3d:20:a7:7e:59:d3:e2:f8:58:f9: 5b:b8:48:cd:fe:5c:4f:16:29:fe:1e:55:23:af:c8:11:b0:8d: ea:7c:93:90:17:2f:fd:ac:a2:09:47:46:3f:f0:e9:b0:b7:ff: 28:4d:68:32:d6:67:5e:1e:69:a3:93:b8:f5:9d:8b:2f:0b:d2: 52:43:a6:6f:32:57:65:4d:32:81:df:38:53:85:5d:7e:5d:66: 29:ea:b8:dd:e4:95:b5:cd:b5:56:12:42:cd:c4:4e:c6:25:38: 44:50:6d:ec:ce:00:55:18:fe:e9:49:64:d4:4e:ca:97:9c:b4: 5b:c0:73:a8:ab:b8:47:c2 Certificate: Data: Version: 3 (0x2) Serial Number: 40:01:77:21:37:d4:e9:42:b8:ee:76:aa:3c:64:0a:b7 Signature Algorithm: sha256WithRSAEncryption Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 Validity Not Before: Jan 20 19:14:03 2021 GMT Not After : Sep 30 18:14:03 2024 GMT Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:ad:e8:24:73:f4:14:37:f3:9b:9e:2b:57:28:1c: 87:be:dc:b7:df:38:90:8c:6e:3c:e6:57:a0:78:f7: 75:c2:a2:fe:f5:6a:6e:f6:00:4f:28:db:de:68:86: 6c:44:93:b6:b1:63:fd:14:12:6b:bf:1f:d2:ea:31: 9b:21:7e:d1:33:3c:ba:48:f5:dd:79:df:b3:b8:ff: 12:f1:21:9a:4b:c1:8a:86:71:69:4a:66:66:6c:8f: 7e:3c:70:bf:ad:29:22:06:f3:e4:c0:e6:80:ae:e2: 4b:8f:b7:99:7e:94:03:9f:d3:47:97:7c:99:48:23: 53:e8:38:ae:4f:0a:6f:83:2e:d1:49:57:8c:80:74: b6:da:2f:d0:38:8d:7b:03:70:21:1b:75:f2:30:3c: fa:8f:ae:dd:da:63:ab:eb:16:4f:c2:8e:11:4b:7e: cf:0b:e8:ff:b5:77:2e:f4:b2:7b:4a:e0:4c:12:25: 0c:70:8d:03:29:a0:e1:53:24:ec:13:d9:ee:19:bf: 10:b3:4a:8c:3f:89:a3:61:51:de:ac:87:07:94:f4: 63:71:ec:2e:e2:6f:5b:98:81:e1:89:5c:34:79:6c: 76:ef:3b:90:62:79:e6:db:a4:9a:2f:26:c5:d0:10: e1:0e:de:d9:10:8e:16:fb:b7:f7:a8:f7:c7:e5:02: 07:98:8f:36:08:95:e7:e2:37:96:0d:36:75:9e:fb: 0e:72:b1:1d:9b:bc:03:f9:49:05:d8:81:dd:05:b4: 2a:d6:41:e9:ac:01:76:95:0a:0f:d8:df:d5:bd:12: 1f:35:2f:28:17:6c:d2:98:c1:a8:09:64:77:6e:47: 37:ba:ce:ac:59:5e:68:9d:7f:72:d6:89:c5:06:41: 29:3e:59:3e:dd:26:f5:24:c9:11:a7:5a:a3:4c:40: 1f:46:a1:99:b5:a7:3a:51:6e:86:3b:9e:7d:72:a7: 12:05:78:59:ed:3e:51:78:15:0b:03:8f:8d:d0:2f: 05:b2:3e:7b:4a:1c:4b:73:05:12:fc:c6:ea:e0:50: 13:7c:43:93:74:b3:ca:74:e7:8e:1f:01:08:d0:30: d4:5b:71:36:b4:07:ba:c1:30:30:5c:48:b7:82:3b: 98:a6:7d:60:8a:a2:a3:29:82:cc:ba:bd:83:04:1b: a2:83:03:41:a1:d6:05:f1:1b:c2:b6:f0:a8:7c:86: 3b:46:a8:48:2a:88:dc:76:9a:76:bf:1f:6a:a5:3d: 19:8f:eb:38:f3:64:de:c8:2b:0d:0a:28:ff:f7:db: e2:15:42:d4:22:d0:27:5d:e1:79:fe:18:e7:70:88: ad:4e:e6:d9:8b:3a:c6:dd:27:51:6e:ff:bc:64:f5: 33:43:4f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign Authority Information Access: CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c X509v3 Authority Key Identifier: keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10 X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.44947.1.1.1 CPS: http://cps.root-x1.letsencrypt.org X509v3 CRL Distribution Points: Full Name: URI:http://crl.identrust.com/DSTROOTCAX3CRL.crl X509v3 Subject Key Identifier: 79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E Signature Algorithm: sha256WithRSAEncryption 0a:73:00:6c:96:6e:ff:0e:52:d0:ae:dd:8c:e7:5a:06:ad:2f: a8:e3:8f:bf:c9:0a:03:15:50:c2:e5:6c:42:bb:6f:9b:f4:b4: 4f:c2:44:88:08:75:cc:eb:07:9b:14:62:6e:78:de:ec:27:ba: 39:5c:f5:a2:a1:6e:56:94:70:10:53:b1:bb:e4:af:d0:a2:c3: 2b:01:d4:96:f4:c5:20:35:33:f9:d8:61:36:e0:71:8d:b4:b8: b5:aa:82:45:95:c0:f2:a9:23:28:e7:d6:a1:cb:67:08:da:a0: 43:2c:aa:1b:93:1f:c9:de:f5:ab:69:5d:13:f5:5b:86:58:22: ca:4d:55:e4:70:67:6d:c2:57:c5:46:39:41:cf:8a:58:83:58: 6d:99:fe:57:e8:36:0e:f0:0e:23:aa:fd:88:97:d0:e3:5c:0e: 94:49:b5:b5:17:35:d2:2e:bf:4e:85:ef:18:e0:85:92:eb:06: 3b:6c:29:23:09:60:dc:45:02:4c:12:18:3b:e9:fb:0e:de:dc: 44:f8:58:98:ae:ea:bd:45:45:a1:88:5d:66:ca:fe:10:e9:6f: 82:c8:11:42:0d:fb:e9:ec:e3:86:00:de:9d:10:e3:38:fa:a4: 7d:b1:d8:e8:49:82:84:06:9b:2b:e8:6b:4f:01:0c:38:77:2e: f9:dd:e7:39 > Socket encrypted! > Disconnected
-
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
DST Root CA X3 will expire on September 30, 2021. That means those older devices that don’t trust ISRG Root X1 will start getting certificate warnings when visiting sites that use Let’s Encrypt certificates.
Qt 5.8 with OpenSSL 1.0 qualifies as an older device in this case.
-
@jeremy_k said in QSslSocket how to dump an expired certificate?:
0, 2021. That means those older d
hum thanks for the link.
What should you do? For most people, nothing at all! We’ve set up our certificate issuance so your web site will do the right thing in most cases, favoring broad compatibility. If you provide an API or have to support IoT devices, you’ll need to make sure of two things: (1) all clients of your API must trust ISRG Root X1 (not just DST Root CA X3), and (2) if clients of your API are using OpenSSL, they must use version 1.1.0 or later. In OpenSSL 1.0.x, a quirk in certificate verification means that even clients that trust ISRG Root X1 will fail when presented with the Android-compatible certificate chain we are recommending by default.
I guess it's openssl lib the faulty then!
But I don't understand why/how this expired certificate is affecting an app as it is not used anymore in the certificates chain... where/how is thisDST Root CA X3
certificate used? is it embedded in openssl? -
There was a discussion that went into details on the qt-interest mailing list. https://lists.qt-project.org/pipermail/interest/2021-October/037642.html in particular.