tlsv1 alert unknown ca
The peer doesn't trust the certificate's CA
Seen in OpenSSL, curl, nginx and Postfix logs, mutual TLS clients (SSL alert number 48)
The other side sent an unknown_ca alert (alert 48): it received a certificate chain it could not trace to a CA it trusts.
Common causes
- In mutual TLS, the server does not trust the CA that issued the client certificate.
- In server logs, a client rejected the server certificate, usually because the intermediate is missing or the client trust store is old.
- A private or corporate CA used on one side but not installed on the other.
How to fix it
- Work out which side sent the alert: the side logging it is the one that was rejected.
- For mutual TLS, add the client certificate issuing CA to the server trust list (nginx ssl_client_certificate).
- For server certificates, serve the full chain (leaf plus intermediates) and update client CA bundles.
Got a different message? Paste it into the error explainer.
Related errors
- unable to get local issuer certificate · The client can't find the certificate's issuer
- unable to verify the first certificate · The intermediate certificate is missing
- certificate has expired · The server certificate has expired
- self signed certificate in certificate chain · The chain ends in an untrusted root
- curl: (51) SSL: no alternative certificate subject name matches target host name · The certificate doesn't match the hostname
- curl: (35) SSL connect error · The TLS handshake failed
- sslv3 alert handshake failure · The server rejected the TLS handshake
- tlsv1 alert protocol version · The peer does not accept this TLS version
- no peer certificate available · The handshake failed before a certificate arrived
- Unable to establish SSL connection. · wget could not complete the TLS handshake
- ERROR: cannot verify example.com's certificate · wget doesn't trust the server's certificate
- Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames · The certificate doesn't cover this hostname