Summary: | =app-misc/ca-certificates-20211016.3.72 breaks net-libs/gnutls verifying some certificate chains | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Branko Grubic <bitlord0xff> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | bitlord0xff |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
gnutls emerge info
ca-certificates emerge info |
Description
Branko Grubic
2021-11-28 05:43:27 UTC
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. |