The unknown_ca alert (TLS alert code 48) is sent when a valid certificate chain was received, but the root Certificate Authority at the top of the chain is not present in the peer's trust store. Unlike bad_certificate (which indicates a structural problem), unknown_ca means the certificate chain is well-formed but terminates at a CA that the peer does not trust. This is the TLS-level equivalent of the browser's ERR_CERT_AUTHORITY_INVALID. It is extremely common in server-to-server communications where one service presents a certificate signed by a private CA, internal CA, or a CA whose root is not in the other service's trust bundle.
Organizations often run their own Certificate Authorities for internal services. If a service presents a certificate signed by this internal CA to a client that does not have the internal CA in its trust store, the unknown_ca alert is sent.
The server is only sending the leaf certificate without intermediates. The client cannot build a chain to a trusted root because the intermediates that link the leaf to the root are missing. Some implementations report this as unknown_ca rather than a chain-building failure.
The client's trust store (ca-certificates package) is outdated and does not include the root CA that signed the server's certificate. This happens when systems are not regularly updated.
Retrieve the certificate chain and identify the root CA. Determine if it is a public CA (should be in standard trust stores) or a private/internal CA.
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts 2>/dev/null | grep 'issuer='
If the server uses a private CA, install the CA's root certificate in the client's trust store. On Debian/Ubuntu, add it to /usr/local/share/ca-certificates/ and run update-ca-certificates.
sudo cp internal-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates
Configure the server to send the complete certificate chain (leaf + intermediates). The root CA does not need to be included, but all intermediates must be present.
cat leaf.crt intermediate.crt > fullchain.crt
Verify that your DNS CAA records permit the Certificate Authority you are using. Incorrect CAA records can prevent valid certificate issuance.
Check DNS RecordsThe browser does not trust the Certificate Authority that signed the server's SSL certificate.
A certificate in the TLS handshake was corrupt, contained invalid signatures, or could not be parsed.
The certificate was rejected for a reason not covered by other specific TLS certificate alerts.
The TLS handshake could not be completed because the client and server failed to negotiate acceptable security parameters.