I have noticed that net-news/liferea and www-client/epiphany fail to work with https://distrowatch.com while www-client/firefox and www-client/google-chrome work fine. After some investigation I tested gnutls-cli with the same server and it failed, while openssl client worked fine. distrowatch.com uses Let's Encrypt and gnutls-cli is able to verify other Let's Encrypt issued certificates fine (I would say same certificate chain except the server certificate, based on the output and serial numbers (btw. I'm not an expert with crypto and PKI stuff)) I have started a thread on users mailing list[1], and after some testing we found that app-misc/ca-certificates behave differently depending on the version. Only difference from distrowatch.com to others which work with gnutls-cli it seems that it serves server certificate twice. Processed 130 CA certificate(s). Resolving 'distrowatch.com:443'... Connecting to '82.103.129.71:443'... - Certificate type: X.509 - Got a certificate list of 4 certificates. - Certificate[0] info: - subject `CN=distrowatch.com', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x0408fd5a5ae26286bed92e97da0c830f623c, RSA key 2048 bits, signed using RSA-SHA256, activated `2021-09-15 03:49:15 UTC', expires `2021-12-14 03:49:14 UTC', pin-sha256="QoW1tiDGE8S3FLukw86yRL8IfevROPxnx0qwVuu/rUI=" Public Key ID: sha1:fcd2b25ac6ffd73fce3ef65211defd25331dc151 sha256:4285b5b620c613c4b714bba4c3ceb244bf087debd138fc67c74ab056ebbfad42 Public Key PIN: pin-sha256:QoW1tiDGE8S3FLukw86yRL8IfevROPxnx0qwVuu/rUI= - Certificate[1] info: - subject `CN=distrowatch.com', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x0408fd5a5ae26286bed92e97da0c830f623c, RSA key 2048 bits, signed using RSA-SHA256, activated `2021-09-15 03:49:15 UTC', expires `2021-12-14 03:49:14 UTC', pin-sha256="QoW1tiDGE8S3FLukw86yRL8IfevROPxnx0qwVuu/rUI=" - Certificate[2] info: - subject `CN=R3,O=Let's Encrypt,C=US', issuer `CN=ISRG Root X1,O=Internet Security Research Group,C=US', serial 0x00912b084acf0c18a753f6d62e25a75f5a, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-09-04 00:00:00 UTC', expires `2025-09-15 16:00:00 UTC', pin-sha256="jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=" - Certificate[3] info: - subject `CN=ISRG Root X1,O=Internet Security Research Group,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x4001772137d4e942b8ee76aa3c640ab7, RSA key 4096 bits, signed using RSA-SHA256, activated `2021-01-20 19:14:03 UTC', expires `2024-09-30 18:14:03 UTC', pin-sha256="C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=" - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. Initially it looked similar to[2] but it was fixed long time ago, and it seems specific to duplicate RootCA [1] https://archives.gentoo.org/gentoo-user/message/0ae7281c5ebd9c06901c43f3aa4f19cb [2] https://gitlab.com/gnutls/gnutls/-/issues/1131 Reproducible: Always Steps to Reproduce: 1. Install =app-misc/ca-certificates-20211016.3.72 2. gnutls-cli distrowatch.com -p 443 3.
Created attachment 756777 [details] gnutls emerge info
Created attachment 756780 [details] ca-certificates emerge info
I'm seeing a similar but different issue where wget (which uses gnutls) is failing to verify any certificates, but downgrading ca-certificates doesn't work. OpenSSL works fine. No idea why yet.
(In reply to James Le Cuirot from comment #3) > I'm seeing a similar but different issue where wget (which uses gnutls) is > failing to verify any certificates, but downgrading ca-certificates doesn't > work. OpenSSL works fine. No idea why yet. Do you have a different example? distrowatch.com is sending an invalid chain and GNUtls doesn't support branching path building (i.e. when the host is actively sending an invaliding certificate to GNUtls client, it will be rejected whereas OpenSSL, which supports branching path building, will treat sent certificates as hint but will try to find certificate path on its own if a hint cannot be used). Not much we can do on our end. Why does it work with previous version, i.e. =ca-certificates-20210119.3.66? Because =ca-certificates-20210119.3.66 installed the now expired DST Root CA certificate (https://crt.sh/?id=8395) in certificate store and certificate chain validation will stop once an issuer was found in certificate store (the expired root anchor itself won't be validated). In case you care, either mask newer ca-certificate versions as long as you want to support broken endpoints or you could just manually re-add this certificate: > # mkdir /usr/local/share/ca-certificates/le > # wget -O /usr/local/share/ca-certificates/le/DST_Root_CA_X3.crt "https://crt.sh/?d=8395" > # update-ca-certificates (last command should print "1 added, 0 removed; done.") The problem will hopefully go away for this host when it will renew current Let's Encrypt certificate which will expire on 2021-12-14.
(In reply to Thomas Deutschmann from comment #4) > (In reply to James Le Cuirot from comment #3) > > I'm seeing a similar but different issue where wget (which uses gnutls) is > > failing to verify any certificates, but downgrading ca-certificates doesn't > > work. OpenSSL works fine. No idea why yet. > > Do you have a different example? > > distrowatch.com is sending an invalid chain and GNUtls doesn't support > branching path building (i.e. when the host is actively sending an > invaliding certificate to GNUtls client, it will be rejected whereas > OpenSSL, which supports branching path building, will treat sent > certificates as hint but will try to find certificate path on its own if a > hint cannot be used). Not much we can do on our end. > > Why does it work with previous version, i.e. =ca-certificates-20210119.3.66? > > Because =ca-certificates-20210119.3.66 installed the now expired DST Root CA > certificate (https://crt.sh/?id=8395) in certificate store and certificate > chain validation will stop once an issuer was found in certificate store > (the expired root anchor itself won't be validated). > > In case you care, either mask newer ca-certificate versions as long as you > want to support broken endpoints or you could just manually re-add this > certificate: > > > # mkdir /usr/local/share/ca-certificates/le > > # wget -O /usr/local/share/ca-certificates/le/DST_Root_CA_X3.crt "https://crt.sh/?d=8395" > > # update-ca-certificates > > (last command should print "1 added, 0 removed; done.") > > > The problem will hopefully go away for this host when it will renew current > Let's Encrypt certificate which will expire on 2021-12-14. Thanks Thomas, I can confirm that adding a certificate fixed the issue with gnutls-cli and that specific server. So in the end it's just an issue with server side. As far as I'm concerned bug can be closed. Not sure if James's issue is the same or different than this one.
Mine is something else. I've reported it in bug #828001.
Once again, thank you. Closing bug.
