On Thu, 20 May 2021 13:20:08 +0100 Darac Marjal <mailingl...@darac.org.uk> wrote:
> > On 20/05/2021 12:03, d...@sherohman.org wrote: > > Although everything works properly for actual (human) users, a coworker > > has informed me that some of his automated tests are failing with > > invalid https certificate errors. I checked and, sure enough, it's not > > just his tests: > > > > $ curl https://ojs.lub.lu.se > > curl: (60) SSL certificate problem: unable to get local issuer certificate > > $ wget https://ojs.lub.lu.se > > --2021-05-20 12:54:48-- https://ojs.lub.lu.se/ > > Resolving ojs.lub.lu.se (ojs.lub.lu.se)... 130.235.140.198 > > Connecting to ojs.lub.lu.se (ojs.lub.lu.se)|130.235.140.198|:443... > > connected. > > ERROR: The certificate of ‘ojs.lub.lu.se’ is not trusted. > > ERROR: The certificate of ‘ojs.lub.lu.se’ doesn't have a known issuer. > > > > links and lynx both issue similar complaints, and these results are > > consistent across multiple systems using Debian versions 9, 10, and (the > > current pre-release version of) 11. ca-certficates is up-to-date on all > > systems. > > > > Firefox and Chromium, however, both say the certificate is 100% valid, > > and I am not aware of any users having reported certificate issues with > > the site. > > > > The cert in question is issued by GEANT eScience SSL CA 4, which in turn > > is signed by USERTrust RSA Certification Authority. > > /usr/share/ca-certificates/mozilla does not have any GEANT certs, but > > there is a USERTrust_RSA_Certification_Authority.crt, so it would appear > > that it should work properly. > > > > We have... several... servers all with GEANT-based certificates and this > > behavior is consistent across all those certs. There are also a handful > > of machines with LetsEncrypt or TERENA certificates which are recognized > > by all tools; this problem seems limited to those issued by GEANT. > > > > > > So, the obvious practical question: What do I need to do to get the > > command-line tools to recognize GEANT certs? curl is the one that > > really matters, but a solution that fixes them all in one fell swoop > > would, of course, be ideal. > > A great place to start is the SSL Labs Server Test - > https://www.ssllabs.com/ssltest/analyze.html?d=ojs.lub.lu.se&latest - > This will perform various handshakes with a HTTPS server and report all > kinds of useful information, including a summary "Grade". > > The most obvious thing I notice from that is that SSL Labs warns that > your certificate chain is incomplete. This probably ties in with the > curl error of "The certificate doesn't have a known issuer". HTTPS > certificates are usually *not* signed directly by the Certificate > Authority. I don't know the details but I think it's to do with the fact > that the CA certificate is very precious so it's usually kept offline. > That CA certificate is used to sign "Intermediate" certificates which > are more easily revoked. However, the Intermediate certificates tend to > be rather more numerous. > > Anyway, the upshot of this is that you have two pieces of a chain: At > the bottom of the chain is the certificate which your web server is > using to encrypt the traffic. At the top of the chain is the Certificate > Authority certificate. This is what web clients know about. To "join the > dots", you need to configure the web server to send your individual > certificate AND the intermediate certificate that it was signed by. You > COULD send the whole chain - in that way you're saying "This is me, and > I'm signed by this intermediate and the intermediate is signed by this > CA", but that's generally considered redundant information. If the > client already has the CA certificate, then it just wastes bandwidth by > sending the CA certificate. > > So, why do Firefox and Chromium work? I'm not sure, but I could > speculate. Firstly, it's possible that they've already seen the > intermediate certificate somewhere else. The certificates are identified > by name and by a hash so, if the web browser already has that > intermediate in its cache, then it can build a trust path to a known CA > through that. Secondly, they may be fetching the intermediate > certificate on demand - Firefox and Chromium are much more geared > towards fetching multiple resources in parallel; curl and friends > probably just fetch what you asked for. To elaborate on / add to this: there's also something called Authority Information Access (AIA), which allows the client to locate a missing intermediate certificate on its own: https://www.thesslstore.com/blog/aia-fetching/ Chrome supports this, although Firefox apparently doesn't: https://bugzilla.mozilla.org/show_bug.cgi?id=399324 curl doesn't: https://github.com/curl/curl/issues/2793 See further: https://security.stackexchange.com/questions/199963/certificate-works-in-chrome-firefox-but-not-with-curl-unable-to-get-local-is https://unix.stackexchange.com/questions/559526/downloading-from-a-public-server-ssl-certificate-problem-unable-to-get-local-i > > And the broader question: Why do GUI browsers recognize the > > certificate, but command-line tools and text-mode browsers do not? > > Shouldn't they all be looking at the same certificates, as provided by > > the ca-certificates package? Celejar
