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. > > 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? >
OpenPGP_signature
Description: OpenPGP digital signature
