ERR_BAD_SSL_CLIENT_AUTH_CERT: Fix Client Certificate Errors

ERR_BAD_SSL_CLIENT_AUTH_CERT means the server asked your browser to prove its identity with a client certificate and the certificate the browser offered could not be used. Chrome shows "Your connection was interrupted" or "This site can't provide a secure connection" with "ERR_BAD_SSL_CLIENT_AUTH_CERT." This only happens on sites that use mutual TLS, such as corporate portals, banking and government tools, VPN gateways and some APIs.

In ordinary HTTPS only the server presents a certificate. In mutual TLS the server also requests a client certificate during the handshake. If the certificate is missing its private key, expired, rejected by the server's trust list, or not accessible (for example a smart card that is not inserted), the handshake ends in this error.

If you are the user

Work through these in order:

1. Check the certificate exists. In Chrome, go to Settings, Privacy and security, Security, Manage certificates. On Windows this opens the system certificate manager (Personal store). On macOS it opens Keychain Access. Look for your client certificate under your own certificates.
2. Check it has a private key. In Keychain Access, the certificate should expand to show a key. On Windows, the certificate details should say "You have a private key that corresponds to this certificate." A certificate imported without its key (a .cer instead of a .p12 or .pfx) will fail.
3. Check the dates. An expired or not-yet-valid certificate is rejected. Ask the issuer for a new one.
4. Check the smart card or token. If the key is on a hardware token, plug it in, unlock it with the PIN, and make sure the reader middleware is installed.
5. Clear the SSL state. On Windows, Internet Options, Content, Clear SSL state. Then close and reopen the browser so it does not reuse a cached bad choice.
6. Re-import the certificate from the original .p12 or .pfx file, and mark the key as non-exportable only if your policy requires it.
7. Pick the right certificate in the prompt. If you have several, the browser shows a selection dialog; choosing one issued by the wrong CA will fail.
8. Try another browser or profile. Firefox keeps its own certificate store unless configured otherwise.

If you run the server

The browser can only offer a certificate that matches the CA list the server announces in its CertificateRequest. Common server-side causes:

• The server's trusted client CA bundle is missing the issuer of the user's certificate or an intermediate.
• The CA bundle was updated and no longer includes the old issuer.
• Certificate revocation checking (CRL or OCSP) fails for the client certificate, so the server rejects it.
• The server requires TLS 1.2 or 1.3, and the client certificate uses an algorithm not allowed in the cipher or signature settings.

Test with OpenSSL

openssl s_client -connect portal.example.com:443 -servername portal.example.com \
  -cert client.crt -key client.key -CAfile ca-bundle.pem </dev/null 2>&1 | grep -E "Acceptable client certificate CA names|Verify return code|alert"

The "Acceptable client certificate CA names" list shows the CAs the server will accept. If your certificate's issuer is not in that list, the browser will not offer it, and you have the cause. A tlsv13 alert certificate required or bad certificate alert shows the server rejecting what was sent.

nginx example

server {
    listen 443 ssl;
    ssl_client_certificate /etc/nginx/client-ca.pem;
    ssl_verify_client on;
    ssl_verify_depth 2;
}

ssl_client_certificate lists the CAs that sign valid client certificates and is also what gets announced to clients. Include intermediates your users' certificates chain through. Reload and re-test. The server log ($ssl_client_verify in a log format) tells you why a certificate failed.

Apache example

SSLVerifyClient require
SSLVerifyDepth 2
SSLCACertificateFile /etc/ssl/client-ca.pem

Behind a CDN or load balancer

Mutual TLS may need to be enabled at the edge, and the CA list configured there. A CDN that terminates TLS will not forward the user's certificate to your origin unless the product is set up for it. Check the vendor's documentation.

Optional versus required

If only some paths need a client certificate, use ssl_verify_client optional and enforce it per location, so visitors to public pages are not forced into a certificate prompt. Each prompt on a public site will frighten ordinary users.

Check from the outside

The SSL Checker and SSL Chain Debugger show the server's own certificate and chain. Use the TLS Version Checker to confirm the protocol versions on offer, and the Port Checker to make sure the port is reachable. Keep in mind that external tools usually cannot present a client certificate, so a mutual TLS endpoint may report a handshake failure there that is entirely normal.

Next steps

• Read SSL and TLS certificate errors explained.
• Compare with ERR_SSL_PROTOCOL_ERROR.
• See Your connection is not private for server-certificate warnings.
• Learn about key pairs.

FAQ

Why does only one browser show the error?

Chrome and Edge use the operating system certificate store, while Firefox uses its own by default. A certificate installed in one may be absent from the other.

Do I need the private key?

Yes. Without the matching private key the browser cannot complete the handshake. Always import a .p12 or .pfx bundle, not just the public certificate.

Can a regular website cause this?

Only if it requests client certificates, which is unusual for public sites. If a normal site shows it, the server is misconfigured.

Is this error a security risk?

No. It is the handshake refusing to proceed without valid credentials.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.