Solving “tlsv1 alert unknown ca” Error in cURL: Client Certificate Authentication Issues


1 views

The error curl: (35) error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca occurs during SSL/TLS handshake when using client certificate authentication. This is a server-side rejection indicating the Certificate Authority (CA) that signed your client certificate isn't trusted by the server.

This is a TLS protocol alert sent by the server to your cURL client. The server examines your client certificate's chain of trust and rejects the connection because it doesn't recognize the CA that issued your certificate.

To inspect your certificate chain:

openssl x509 -in my.pem -text -noout
openssl verify -CAfile server_ca_bundle.crt my.pem

Look for the "Issuer" field in your certificate. The last CA in the chain (the root CA) is what the server doesn't recognize.

Missing Intermediate Certificates

Your PEM file might only contain the end-entity certificate. Bundle it with intermediates:

cat client_cert.pem intermediate1.pem intermediate2.pem > combined.pem
curl -E combined.pem https://some.site

Server Doesn't Trust Your CA

If the server explicitly doesn't trust your CA, you'll need to:

  1. Obtain a certificate from a CA the server trusts
  2. Ask server administrators to add your CA to their trust store

Debugging with OpenSSL

For deeper inspection:

openssl s_client -connect some.site:443 -cert my.pem -key my.key -CApath /etc/ssl/certs/

If you control both client and server, consider these certificate handling methods:

# Using a custom CA bundle
curl --cacert custom_ca_bundle.crt -E my.pem https://some.site

# For testing purposes only (disables CA verification)
curl -k -E my.pem https://some.site
  • Always include the full certificate chain in your PEM file
  • Use certificates from widely-recognized CAs for public services
  • For internal systems, ensure consistent CA trust across all components
  • Regularly update CA certificate bundles on both client and server

The error message curl: (35) error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca occurs during TLS handshake when:

  • The server doesn't recognize the Certificate Authority (CA) that issued your client certificate
  • The TLS alert is sent from the server to your client (curl)
  • The specific CA in question would be the issuer of your my.pem certificate

This is a server-side rejection of your client certificate chain. The server maintains a list of trusted CAs, and your certificate's issuer isn't in that list. Here's what's happening:

Client (curl) --- ClientHello ---> Server
Client <--- ServerHello, CertificateRequest --- Server
Client --- Certificate (my.pem) ---> Server
Client <--- Alert (unknown_ca) --- Server

To inspect your certificate chain:

openssl x509 -in my.pem -text -noout
# Look for "Issuer" field

# For full chain verification:
openssl verify -show_chain -CAfile server-trusted-cas.crt my.pem

Option 1: Get a certificate from a CA the server trusts

# Example using Let's Encrypt (if trusted by server)
certbot certonly --standalone -d yourdomain.com

Option 2: Provide the full certificate chain

# Combine cert + intermediate CA certs
cat client.crt intermediate1.crt intermediate2.crt > fullchain.pem
curl -E fullchain.pem https://some.site

Option 3: Configure server to trust your CA (if you control server)

# For Apache:
SSLCACertificateFile /path/to/your-ca.crt

# For Nginx:
ssl_client_certificate /path/to/your-ca.crt;

Enable verbose output in curl:

curl -v -E my.pem https://some.site

Test with OpenSSL directly:

openssl s_client -connect some.site:443 -cert my.pem -key my.key -state -debug

For internal PKI systems, you might need to:

# Download company root CA
wget https://internal-ca/root.crt

# Combine with your cert
cat client.crt company-intermediate.crt root.crt > full_client.pem

# Use with curl
curl --cacert root.crt -E full_client.pem https://internal-api.example.com
  • Never bypass certificate verification (--insecure is dangerous)
  • Keep your CA certificates updated
  • Consider certificate pinning for critical services

Remember that this error fundamentally indicates a trust chain issue that must be properly resolved rather than worked around.