curl (60) SSL certificate problem

Exit code 60 is four different errors #

curl returns 60 — CURLE_PEER_FAILED_VERIFICATION — for any failure of certificate verification. Searching for the number alone mixes four unrelated problems together. Find your phrase in this table first:

One more message also exits 60 but is not printed as a “certificate problem” at all:

curl: (60) SSL: no alternative certificate subject name matches target host name 'example.com'

That is a hostname mismatch, and nothing about the chain is wrong.

First: which CA bundle is curl reading? #

Almost every code-60 investigation is shortened by this one line. curl prints the bundle it was compiled to use in its verbose handshake output:

curl -v https://example.com 2>&1 | grep -iE "CAfile|CApath"

*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs

Three things override that path, in increasing order of precision:

export CURL_CA_BUNDLE=/path/to/ca-bundle.crt   # every curl invocation in the shell
curl --cacert /path/to/root-ca.crt https://example.com   # this request only
curl --capath /etc/ssl/certs https://example.com         # a directory of hashed certs

unable to get local issuer certificate #

The most common of the four. curl could not find the CA that signed the certificate it was handed. Ask the server what it sends and count the certificates:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
| grep -c "BEGIN CERTIFICATE"

One certificate from a public CA means the server is misconfigured — it is not sending its intermediates — and every non-browser client will fail against it. Two or more means the chain is fine and the root is missing from curl’s bundle, which is normal for a private or corporate CA.

The full diagnosis and both fixes are on unable to get local issuer certificate. To make curl accept a private root without touching the system bundle:

curl --cacert /etc/ssl/certs/corp-root-ca.crt https://internal.example.com

Self-signed certificate #

The chain terminates in a certificate that signed itself, so there is no CA to appeal to. Confirm by comparing subject and issuer — on a self-signed certificate they are identical:

openssl x509 -in self-signed.crt -noout -subject -issuer

subject=CN=localhost
issuer=CN=localhost

For development and internal services this is expected, and the correct response is to trust that specific certificate rather than to stop verifying:

curl --cacert self-signed.crt https://localhost:8443

For anything reachable from the internet, a self-signed certificate means no client will trust it by default. Get a free certificate from a public CA instead.

Hostname does not match #

The certificate is valid, correctly signed and in date — it was simply issued for a different name. curl checks the Subject Alternative Name extension, and since RFC 6125 the Common Name is not consulted at all by modern clients. List the names the certificate is actually valid for:

openssl x509 -in certificate.crt -noout -ext subjectAltName

X509v3 Subject Alternative Name:
  DNS:example.com, DNS:www.example.com

If the name you requested is absent, the certificate needs reissuing with the right SAN entries. A certificate carrying only a Common Name and no SAN extension fails this check against every current client, however correct the CN looks.

Fixing it for libcurl consumers #

curl is a library long before it is a command, so the same failure surfaces under other names:

What not to do #