verify error:num=21:unable to verify the first certificate

Where you see it

In openssl s_client output when you test a server. It almost always appears right after error 20 at depth 0. The code is X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE in the OpenSSL verification options documentation.

$ openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null
Connecting to 192.0.2.20
CONNECTED(000001BC)
depth=0 CN=shop.example.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=shop.example.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN=shop.example.com
verify return:1
---
Certificate chain
 0 s:CN=shop.example.com
   i:C=US, O=Example CA, CN=Example Issuing CA R1
---
...
Verification error: unable to verify the first certificate
...
Verify return code: 21 (unable to verify the first certificate)

Node.js reports the same situation as UNABLE_TO_VERIFY_LEAF_SIGNATURE with the message “unable to verify the first certificate”.

What it means

The “first certificate” is the server’s own certificate, the leaf certificate. To check its signature, OpenSSL needs the certificate of the CA that signed it: normally an intermediate certificate that the server sends along. OpenSSL could not find that issuer, so it could not verify even the first link of the certificate chain. Under “Certificate chain” you typically see only one entry, 0 s:.

Likely causes

The server sends only its own certificate

By far the most common cause. The server was configured with the certificate file the CA issued (cert.pem, server.crt) instead of the full chain.

Confirm: count the certificates sent.

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

1 means the intermediate is missing.

Find the intermediate. Your CA’s documentation lists it, and most certificates also say where to download it:

openssl x509 -in server.crt -noout -ext authorityInfoAccess

Authority Information Access: 
    CA Issuers - URI:http://ca.example.net/issuing-ca-r1.cer
    OCSP - URI:http://ocsp.example.net

Download the “CA Issuers” file. It is often in DER (binary) format; convert it to PEM:

curl -sS -o issuing-ca.cer http://ca.example.net/issuing-ca-r1.cer
openssl x509 -inform DER -in issuing-ca.cer -out issuing-ca.pem

Check that it really is the issuer before you use it:

openssl verify -partial_chain -trusted issuing-ca.pem server.crt

server.crt: OK means the intermediate signed your certificate.

Fix: serve the certificate followed by the intermediate, leaf first:

cat server.crt issuing-ca.pem > fullchain.pem

• nginx: ssl_certificate /etc/ssl/shop.example.com/fullchain.pem; (with certbot, point it at fullchain.pem).
• Apache 2.4.8 and later: SSLCertificateFile with the full chain file.
• IIS: import the intermediate into the computer’s “Intermediate Certification Authorities” store, then rebind the site.
• Load balancers and CDNs: paste the intermediate into the “certificate chain” field when you upload the certificate.

Reload and check again: you should see 1 s: with the intermediate, and Verify return code: 0 (ok) when the root is trusted.

The server sends the wrong intermediate

Sometimes a chain file holds an intermediate from an older certificate or another CA. Compare the issuer of entry 0 with the subject of entry 1 in the -showcerts output: they must be identical. If not, download the correct intermediate as above and rebuild the chain file.

Check yours

Try it: Chain checkerOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste the chain

Try a sampleChoose a sample…A complete chain: leaf, intermediate and rootA server that forgets its intermediateA chain in the wrong orderA self-signed root CA

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

Every certificate the server sends, leaf first. The output of openssl s_client -showcerts -connect example.com:443 works as it is: we ignore the text around the certificates.

Check the chainClearChoose a file

Paste the output of openssl s_client -showcerts. The checker shows that the chain stops after the first certificate and which issuer it needs.

Learn why

• Certificate chains and path validation: what “the first certificate” is and how the path is built.
• Related: verify error:num=20 and curl: unable to get local issuer certificate.

In the gameLevel 13: The chainChain Bridge, Keystone. In development