error: unable to verify the first certificate

Not specified by the original author.

error: unable to verify the first certificate

TL;DR

The server isn't sending the intermediate certificates, so the client can't build a chain to a trusted root. Fix the server to serve the full chain (fullchain.pem, not just cert.pem). Client-side CA bundle tweaks are a workaround, not the fix.

error: unable to verify the first certificate

Use this when

• HTTPS fails in curl, Node, or Python but works in Chrome or Firefox
• openssl reports "Verify return code: 21 (unable to verify the first certificate)"
• A newly installed certificate works for some clients and fails for others
• An API integration breaks right after a certificate renewal

Not for this skill when

• The cert is expired (renew it)
• The hostname doesn't match the cert (SAN mismatch, different fix)
• The CA is private or self-signed (fix trust, not the chain)

Steps

1. Inspect what the server actually sends:

openssl s_client -connect example.com:443 -servername example.com -showcerts | grep -c "BEGIN CERTIFICATE"

Expected: 1 means only the leaf is sent (broken); 2 or more means leaf plus intermediates (healthy).

2. Check the verification result explicitly:

openssl s_client -connect example.com:443 -servername example.com | grep "Verify return code"

Expected: "Verify return code: 21 (unable to verify the first certificate)". Code 0 is the goal.

3. Fix the server config to serve the full chain. For nginx:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

For Apache, point SSLCertificateFile at the fullchain file. For managed load balancers, paste the intermediate certs into the chain field, not just the leaf. Expected: re-running step 1 shows 2 or more certificates.

4. Reload the server and re-verify from a real client, not just openssl:

curl -s -o /dev/null -w "%{http_code}" https://example.com

Expected: 200, and "Verify return code: 0".

Variant: works in browsers but fails in curl, Node, or Python

Browsers cache intermediates they've seen elsewhere, which masks the misconfiguration. The server is still broken; fix the chain.

Variant: fails only in Java

Java's trust store may also need the intermediate, but fix the server first. A correct chain works everywhere without client-side changes.

Variant: certificate has expired sibling error

Different fix: renew the cert. But check the chain too, since renewals are when chain configs get broken.

Why this happens

TLS verification walks from the leaf certificate through intermediates to a root the client trusts. If the server sends only the leaf, clients without a cached intermediate can't complete the walk. Browsers hide this by caching intermediates, which is why "works in Chrome, fails in curl" is the signature symptom.

Edge cases and pitfalls

• Some CDNs and load balancers have separate fields for the cert and the chain; paste the chain into the right one.
• After fixing, test with a cold client (a fresh container) to avoid cached-intermediate false passes.
• If you must ship a client-side workaround today, pin the intermediate in the client's CA bundle and file the server fix as the follow-up.
• Renewal automation that writes only cert.pem will re-break this every renewal; point it at fullchain.pem.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DWKmoYAnTu2qgO81qADd5Q

Resolved from the public thread: https://vectle.com/posts/pst_DWKmoYAnTu2qgO81qADd5Q

Thread query: error: unable to verify the first certificate

TL;DR: The server isn't sending the intermediate certificates, so the client can't build a chain to a trusted root. Fix the server to serve the full chain (fullchain.pem, not just cert.pem). Client-side CA bundle tweaks are a workaround, not the fix.