Unable to Verify the First Certificate (UNABLE_TO_VERIFY_LEAF_SIGNATURE): Fix

The message is OpenSSL verification error 21, X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE. OpenSSL's manual: «No signatures could be verified because the chain contains only one certificate and it is not self-signed and the X509_V_FLAG_PARTIAL_CHAIN flag is not set» (X509_STORE_CTX_get_error). «The first certificate» is the server's own (leaf) certificate, depth 0 in the chain.

Node.js is where most people meet it: Error: unable to verify the first certificate with code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE', raised by https, fetch, axios, npm and anything else on Node's TLS stack (Node.js X509 error codes). Recent Node versions append a hint to try --use-system-ca when the root is installed locally; for this particular error the hint rarely helps, because what is missing is an intermediate the server should have sent, not a root.

It is a server configuration problem in the vast majority of cases. The client did its job: it received one certificate, signed by an issuer it does not have, and refused to guess.

The reason browsers keep working is Authority Information Access (AIA) fetching: the leaf names a URL where its issuer can be downloaded, and Chrome uses it. Node.js, curl, Python and Go verify with what the server sends plus their trust store and do not download anything. A chain that is only browser-complete is broken for every API client.

The last row is a Node.js trap. The Node.js documentation notes that neither the built-in roots nor NODE_EXTRA_CA_CERTS are used when the ca option is set explicitly on a TLS or HTTPS client. Passing ca: [intermediate] therefore replaces Node's whole root list instead of adding to it.

See what the server sends:

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

One certificate is the problem. Save the leaf and read where its issuer lives:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 > leaf.pem
openssl x509 -in leaf.pem -noout -issuer -ext authorityInfoAccess

The CA Issuers - URI: line is the download address of the intermediate. Fetch it, convert it to PEM if it is DER, and check that it really signed the leaf before you deploy anything:

curl -sS -o issuer.der 'http://ca.example.net/issuer.crt'
openssl x509 -inform DER -in issuer.der -out issuer.pem
openssl verify -partial_chain -CAfile issuer.pem leaf.pem
leaf.pem: OK
cat leaf.pem issuer.pem > fullchain.pem

Prefer the chain file your CA or ACME client already gives you (Certbot writes fullchain.pem); rebuild it by hand only when that file is lost.

1. nginx: ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; with the leaf first and intermediates after it, then nginx -t && systemctl reload nginx.
2. Apache 2.4.8 and later: put the leaf and intermediates in the file named by SSLCertificateFile.
3. Load balancers and CDNs: upload the certificate together with its chain field; a bare leaf reproduces this error for every non-browser client.
4. Your own Node.js client talking to a private CA: trust the root, not the intermediate, and keep the defaults by using the environment variable rather than ca:

   NODE_EXTRA_CA_CERTS=/etc/ssl/private-root.pem node app.js

5. Do not ship a workaround such as rejectUnauthorized: false or NODE_TLS_REJECT_UNAUTHORIZED=0; both accept any certificate from anyone.

node -e "require('https').get('https://example.com/', r => console.log(r.statusCode)).on('error', e => console.log(e.code))"
# 200
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
# 2

Check from outside as well: the SSL/TLS checker lists every certificate your server sends and shows whether the chain reaches a trusted root.

• unable to get local issuer certificate — error 20, curl's report of the same gap
• self-signed certificate in certificate chain — complete chain, untrusted root
• ERR_TLS_CERT_ALTNAME_INVALID — trusted chain, wrong host name
• NET::ERR_CERT_AUTHORITY_INVALID — the browser's untrusted-issuer error
• Trust anchor for certification path not found — the Android wording
• Incomplete certificate chain — background and checks