Csdrhrt

There is a server with a broken SSL chain, as reported by this SSL check:

I know this is a problem that should be solved on the server itself, but sometimes this is hard to have fixed (I'm not the admin of the server).

The thing is, that Chrome/Mozilla/Edge on Windows trust the site certificate anyway:

However, in a Gnu/Linux deployment (Ubuntu 18.04 in Docker) the certificate is not trusted:

curl: (60) SSL certificate problem: unable to get local issuer certificate

I tried update-ca-certificates and even imported the Globalsign Root certificate. update-ca-certificates reported a duplicate certificate in that case. Anyway, nothing works.

How to reproduce

Using Docker:

docker run -it ubuntu:18.04



# within container:

apt-get update

apt-get -y install curl

curl https://betriebsheft.vog.it  # <---- "unable to get local issuer certificate"

How can I make Gnu/Linux trust this certificate?

PS: The same certificate is deployed correctly on another server.

The real fix for this is to ensure that your server presents all certificates in the chain and not just the end-entity (server) certificate.

Point your server administrator to RFC 5246 Section 7.4.2 which clearly states that This message conveys the server's certificate chain to the client.

If your admin refuses/can't do this for some reason, your alternative option is to try and get curl to work with the malformed handshake.

According to a message on the Curl mailing list:

Can someone confirm if cURL supports (or not) intermediate certificate?

Yes it does.
All ca certificates have a certificate chain going up to the root. The ca
bundle you use with curl needs to consist of the certs for the entire chain.

/ daniel.haxx.se

You should be able to add the Root CA and all intermediates certificates to a bundle and point curl to it using the --cacert <file> option.

As your browsers work, you can access the correct CA certificates from there. On the certificates tab (different for each browser, but I'm sure you'll figure that one out), view the certificate chain. Double-click the Root CA first Globalsign Root CA - G1 and on the Details tab, click on Copy to file.... Save it as root.cer. Do the same with the AlphaSSL CA - SHA256 - G2 and save it as issuing.cer. Join the two together in a single file (e.g. chain.cer) and use that as the argument to -cacert.

As kindly pointed out by @A.B. the missing certificate can also be found here.

Your browsers work because they cache CA certificates. If you've navigated to a correctly configured website at some point in the past, whose certificate was issued by the same CA as your server's certificate, it will be cached by the browser. When you subsequently visit your incorrectly configured site, your browser will use the CA certificates in its cache to build the chain. To you, it seems like everything is fine, although behind the scenes, the server is mis-configured.

Note that on Windows, IE/Edge and Chrome share the same cache, while Firefox uses its own.

In addition to the above, IE/Edge and Chrome (as they share the same crypto stack) will use an extension within certificates called the AuthorityInformationAccess. This has a caIssuer option which provides a URL from which the end-entity certificate's CA certificate can be downloaded. Therefore, even if one of these browsers hasn't cached the missing certificates from previous browsing, it can fetch it if required. Note that Firefox doesn't do this, which is why sometimes Firefox can show certificate errors when IE/Edge and Chrome seem to work.