Cannot get cURL or wget to validate some SSL certificates

I've noticed that our link checker, which uses cURL, fails more and more often to validate SSL certificates. I'm trying to get to the bottom of this.

https://www.bgetem.de/, for instance, opens just fine on every browser (IE 11, Firefox, Opera, Chrome) on my Windows 7 machine, but cURL (and wget) on my CentOS 6 and Ubuntu 16.04 cannot validate the certificate.

Here is cURL's verbose output from CentOS (Version curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2)

* About to connect() to www.bgetem.de port 443 (#0)
*   Trying 193.104.3.166... connected
* Connected to www.bgetem.de (193.104.3.166) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* Peer's certificate issuer is not recognized: 'CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB'
* NSS error -8179
* Closing connection #0
* Peer certificate cannot be authenticated with known CA certificates

And Ubuntu (Version curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3):

* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 695 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection 0
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Any idea what the problem is and how I can fix it?

Solution 1:

As the error message already explains: the servers certificate cannot be authenticated with the known CA certificates from the CAfile: /etc/pki/tls/certs/ca-bundle.crt (as the server certificate is issued by a CA unknown to your system).

Two fairly common reasons for such a message:

• The certificate is really signed by an unknown CA (for instance an internal CA).
• The certificate is signed with an intermediate CA certificate from one of the well known CA's and the remote server is misconfigured in the regard that it doesn't include that intermediate CA certificate as a CA chain it's response.

Thank you for including the domain name: that allows us to test the SSL server and confirm: the CA chain is incomplete:

As the admin of that server you can/should fix the Chain File to prevent those "extra download" sections in the Certification Path.

If you're not the admin of that server and want to fix that client side: download that intermediate certificate yourself and add it to the local trust store.