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

SSL check report

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:

enter image description here

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.

  • why the downvote?
    – Udo G
    Commented Dec 23, 2018 at 14:49
  • 1
    I'm voting to close this question as off-topic because the OP is asking something he can't influence himself. He said he can't modify anything server-side, so this probably belongs to superuser I think, as it describes a problem having no solution client-side. Commented Dec 23, 2018 at 14:51
  • 2
    I am specifically asking for a client-side solution. I can't influence the server, but I have full control over the client O/S (Ubuntu) and I want this specific O/S installation to trust the certificate just like other O/S (Windows) do. It's not about fixing the HTTPS site for others.
    – Udo G
    Commented Dec 23, 2018 at 14:54
  • 1
    The question is about using/administering a *nix system and applications packaged therein
    – Udo G
    Commented Dec 23, 2018 at 15:01
  • 1
    You don't control the server, but you still can report the problem to the person who does control the server. Commented Dec 23, 2018 at 17:09

1 Answer 1


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.

  • 1
    It's not my server, so can't modify anything server-side. I tried to use the CA bundle from curl.haxx.se/docs/caextract.html (since Firefox trusts the certificate) and pass it using --cacert cacert.pem but CURL still does not accept the certificate.
    – Udo G
    Commented Dec 23, 2018 at 14:41
  • 1
    It is your server. Run echo q | openssl s_client -showcerts -connect betriebsheft.vog.it:443 and you will see only one certificate being presented by your server. There should be two - the end-entity cert (which is presented) and the issuing CA - the Alpha SSL - SHA256 - G2 certificate. The latter isn't being sent by the server, but should. Commented Dec 23, 2018 at 15:36
  • 2
    @garethTheRed : I understand that the server does not present all certificates, but the server is not under my control (that's what I meant with "not my server"). I'm just trying to access an API on an foreign server. Under Windows, none of my browsers complain about the certificate, only Linux/Debian/Ubuntu does.
    – Udo G
    Commented Dec 23, 2018 at 15:42
  • @A.B: thanks a lot! Installing all the root certificates from that page solved the issue. However, I'd like to understand why that manual step is necessary.
    – Udo G
    Commented Dec 23, 2018 at 15:50
  • 2
    The missing intermediate cert (as mentioned by @garethTheRed) can be found there: support.globalsign.com/customer/portal/articles/… . OP initially only tried to add the root cert which was probably already in place, thus achieving nothing.
    – A.B
    Commented Dec 23, 2018 at 16:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .