Re: Missing SSL/https root cert(s)? (RESOLVED)
On Thu, May 20, 2021 at 01:20:08PM +0100, Darac Marjal wrote: > A great place to start is the SSL Labs Server Test - > https://www.ssllabs.com/ssltest/analyze.html?d=ojs.lub.lu.se - > This will perform various handshakes with a HTTPS server and report all > kinds of useful information, including a summary "Grade". Ah, great, thanks to you and to those further down the reply chain! When I set up our first machine to use a GEANT cert, I wasn't able to get their "certificate w/ chain" to work, but the "certificate only" was fine in firefox, so I assumed (...without bothering to actually look in the file) that the "certificate only" download also included the chain and went with that, unaware that firefox is "helpful" enough to find the chain for itself. So now I revisited that and, apparently, the "certificate w/ chain" download has the certificate order backwards in the pem, so I needed the "certificate w/ issuer after" download instead. Now that I've gotten that straightened out, everything appears to be working as it should. -- Dave Sherohman
Re: Missing SSL/https root cert(s)?
On Fri, 21 May 2021 06:02:10 + Bonno Bloksma wrote: > Hi Celejar, > > >>> 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: > > > 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/ > > Thanks for answering this post as full as you did. I did not know about > AIA fetching and it now solves something I had noticed before but never > found out why. > Now I know. :-) Hey, I had never heard of it either - I was just intrigued by the puzzle the OP presented, so I dug around a bit ;) > I understand finding the balance between a proper configured (web) > server and trying to make users don't have problems with misconfigured > servers. The same discussion has been going on with what a mail > server/client should accept and try to interpret when the sender does > not follow the proper rules. > > Met vriendelijke groet, > Bonno Bloksma > senior systeembeheerder Celejar
RE: Missing SSL/https root cert(s)?
Hi Celejar, >>> 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: > 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/ Thanks for answering this post as full as you did. I did not know about AIA fetching and it now solves something I had noticed before but never found out why. Now I know. :-) I understand finding the balance between a proper configured (web) server and trying to make users don't have problems with misconfigured servers. The same discussion has been going on with what a mail server/client should accept and try to interpret when the sender does not follow the proper rules. Met vriendelijke groet, Bonno Bloksma senior systeembeheerder
Re: Missing SSL/https root cert(s)?
On Thu, 20 May 2021 13:20:08 +0100 Darac Marjal 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 - > 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
Re: Missing SSL/https root cert(s)?
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 - 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
Missing SSL/https root cert(s)?
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. 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? -- Dave Sherohman
