ERR_BAD_SSL_CLIENT_AUTH_CERT high
ERR_BAD_SSL_CLIENT_AUTH_CERT
The server demanded a client certificate during mutual TLS and the browser presented none, an expired one, or one the server doesn't trust.
What you see
This site can’t provide a secure connection example.com didn’t accept your login certificate, or one may not have been provided. ERR_BAD_SSL_CLIENT_AUTH_CERT
What’s actually happening
The connection dies during the handshake and there is no proceed button — client-auth failures aren't user-bypassable. You usually hit this on a corporate intranet, a VPN portal, a bank's admin endpoint, or an internal API gateway that requires a certificate installed in your OS/browser store. Either no certificate-selection prompt appeared, or you picked one and the server still rejected it. Public sites that don't use mTLS never throw this.
Common causes
- No client certificate is installed in the OS keychain / Windows cert store / browser, so the browser had nothing to send when the server sent a CertificateRequest.
- The client cert exists but is expired or not yet valid, or was revoked (CRL/OCSP).
- The cert was issued by a CA that isn't in the server's list of accepted client-CA issuers, so the server rejects it during validation.
- The matching private key is missing or non-exportable, so the browser can't complete the proof-of-possession even though the cert shows up.
- Wrong cert chosen at the selection prompt — multiple certs installed and the user picked one meant for a different endpoint.
How to fix it
- Confirm the site actually wants mTLSTest with `openssl s_client -connect example.com:443 -servername example.com </dev/null` and look for an 'Acceptable client certificate CA names' block. If it's present, the server is requesting a client cert and listing which issuers it trusts — match your cert against that list.
- Check what's installed and whether it's expiredmacOS: open Keychain Access, look under My Certificates for one with a private key (it has a disclosure triangle). Windows: `certmgr.msc` → Personal → Certificates. Confirm the validity dates cover today and that a key is attached. An identity cert with no key won't work.
- Install or renew the client certificateGet the current .p12/.pfx bundle from whoever runs the service (IT, the CA portal) and import it — double-click on macOS to add to login keychain, or use certmgr's Import on Windows. Import the full bundle so the private key comes with it. Restart the browser so it re-reads the store.
- Fix the server's trusted-CA list if you run the serverIf users with legitimate certs get rejected, your terminator's client-CA bundle is stale or wrong. In nginx check `ssl_client_certificate` and `ssl_verify_client`; in Apache `SSLCACertificateFile` and `SSLVerifyClient`. Make sure the issuing CA (and any intermediate) that signed user certs is in that bundle, then reload.
- Clear the cached cert choiceChrome remembers the cert you picked per-session. If you selected the wrong one, fully quit and reopen Chrome (not just the tab) so the selection prompt reappears, then choose the correct identity.
Stop it recurring
Track client-cert expiry the same way you track server certs, and keep the server's accepted-CA bundle in sync whenever the issuing CA rotates.
Related errors