The server refuses a client certificate yet present.
Probable causes
- CA client
- EKU
- or the United Nations
Verifications.
- Limit the impact. — Identify whether an endpoint, service, or whole site is affected.
- Collect evidence. — Keep the exact error message, timestamp, and associated logs.
- Test the simplest hypothesis first. — Compare the affected system with a known-good path.
- Correct the confirmed cause and validate the result. — Apply one controlled change at a time and retest.
Commands
openssl s_client -connect example.com:443 -cert client.crt -key client.keySolutions.
- Correct the confirmed cause rather than the symptom.
- Document the change and its result.
- Establish monitoring if the fault can recur.
When to escalate?
Escalate if the impact expands, data are at risk, or remediation requires an irreversible change.
mTLS certificate focus
Mutual TLS adds client-certificate validation to the normal TLS handshake. A rejection can therefore come from trust, certificate validity, key usage, revocation checks or from a proxy that terminates TLS before the backend sees the client identity.
What to verify
- Confirm that the client presents the intended certificate and possesses the matching private key.
- Check validity dates, issuing chain and whether the server trusts the issuing CA.
- Verify the certificate is suitable for client authentication and that revocation checking can reach the required CRL or OCSP source when enforced.
- Inspect reverse-proxy, load-balancer or API-gateway configuration to determine where mTLS is actually validated.
Resolution path
Correct the trust chain, client-certificate selection or gateway policy rather than disabling client authentication. Replace expired or incorrectly issued certificates through the normal PKI process.
Validation
Repeat the handshake with the same endpoint and client identity, then confirm the backend receives the expected authenticated client context.