ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: Fix Client Certificate Signing

The site uses client-certificate authentication (mutual TLS): during the handshake the server asks the browser to prove it holds a certificate's private key by signing handshake data. ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED is Chromium net error -141, and that signing step failed on your device. Chromium's source lists the possible causes: access to the private key was denied, the key is not valid for signing, the key relies on a cached handle that is no longer valid, or the cryptographic provider will not sign arbitrary data. Chrome shows “Access to host was denied” and “There was a problem using your login certificate.”

It is not the server rejecting your certificate. That case, an untrusted, expired or wrong certificate, is ERR_BAD_SSL_CLIENT_AUTH_CERT (“didn't accept your login certificate”). Close relatives on the client side are ERR_SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY (certificate installed without its key), ERR_SSL_CLIENT_AUTH_PRIVATE_KEY_ACCESS_DENIED and ERR_SSL_CLIENT_AUTH_NO_COMMON_ALGORITHMS (the key cannot produce any signature type the server accepts).

• Smart card or USB token problems: the card was removed after the certificate was chosen, the PIN prompt was cancelled or the PIN is locked, or the middleware is outdated.
• Stale key handle. Chromium notes that operating systems do not reliably report a removed smart card. Chrome therefore forgets the remembered certificate after a failed signature and, if it did not already prompt during that request, retries once and asks again. Seeing the error means that retry also failed.
• Key not usable for signing. Imported without the private key, imported as non-exportable into a provider that refuses this kind of signature, or a key restricted to encryption.
• TLS 1.3 and RSA-PSS. TLS 1.3 handshake signatures with RSA keys must use RSA-PSS. Some smart cards, TPM keys and older Windows providers only do PKCS#1 v1.5 signatures, so the same card works on a TLS 1.2 server and fails on a TLS 1.3 one.
• Access denied by the OS: on macOS, declining the Keychain prompt that asks to let the browser sign with the key.

The signature is computed on the visitor's device, so no proxy setting causes this error. The one check that applies: whichever box terminates TLS (Cloudflare with mTLS, a load balancer, nginx) sets the TLS version, and a TLS 1.3-only policy forces RSA-PSS on every client key, so keep TLS 1.2 on client-certificate hosts while legacy tokens are in use:

server {
    listen 443 ssl;
    server_name secure.example.com;
    ssl_protocols           TLSv1.2 TLSv1.3;
    ssl_client_certificate  /etc/nginx/tls/client-ca.pem;
    ssl_verify_client       on;
}

1. Prove the server side works with a file-based test certificate:

   openssl s_client -connect secure.example.com:443 -servername secure.example.com \
     -cert client.pem -key client.key -brief </dev/null
   curl -sv --cert client.pem --key client.key https://secure.example.com/ -o /dev/null

   If this succeeds over both TLS 1.2 (-tls1_2) and TLS 1.3 (-tls1_3), the problem is on the users' key stores or tokens.
2. If only hardware tokens fail under TLS 1.3, keep TLS 1.2 enabled for that hostname and plan a token refresh to models that support RSA-PSS or ECDSA.
3. Ask an affected user for a NetLog (chrome://net-export). The SSL_PRIVATE_KEY_OP event shows the signature algorithm requested and the error returned by the key.
4. Document the supported setup for users: which browsers, which middleware version, and how to import a .p12 with its key.

• Smart card or token: reinsert it, unlock it with the PIN, update the vendor middleware, and do not cancel the PIN dialog.
• Restart the browser fully and choose the certificate again when prompted.
• Check the private key is there. Windows: certmgr.msc > Personal > Certificates; the certificate dialog should say “You have a private key that corresponds to this certificate.” macOS: Keychain Access should show a key under the certificate, and you must allow the browser when prompted. Chrome on Linux: certutil -d sql:$HOME/.pki/nssdb -L lists certificates; import with pk12util -i cert.p12 -d sql:$HOME/.pki/nssdb.
• Reimport from the .p12/.pfx file via Settings > Privacy and security > Security > Manage certificates, so certificate and key are installed together.
• Firefox works but Chrome fails, or the other way round: Firefox keeps its own certificate store by default, so the two browsers may be using different copies of the certificate.

Clearing the cache does not help. If a certificate from a file works but your smart card does not, contact whoever issued the card.

openssl s_client -connect secure.example.com:443 -servername secure.example.com \
  -cert client.pem -key client.key -tls1_3 -brief </dev/null
# CONNECTION ESTABLISHED, then reload the site in Chrome with the token inserted

A successful reload without the error page, after choosing the certificate, confirms the key can sign. To check the server's protocols and certificate chain from outside, use the SSL/TLS checker.

• Mutual TLS (mTLS) — how client-certificate authentication works
• ERR_SSL_KEY_USAGE_INCOMPATIBLE — key usage does not fit the handshake
• SSL handshake failed — the general handshake failure