Card 09/ 10
Practice: Diagnosing Four Certificate Errors
Four failed connections, one of them a service whose client certificate was refused; name each cause.
Diagnosing a certificate error starts by reading which check failed. Four connections have failed, each with the message shown. The messages are illustrative. For each, name the cause and the fix.
- A nightly job fails with
curl: (60) SSL certificate problem: certificate has expiredwhen callinghttps://api.example.com. - A browser shows NET::ERR_CERT_COMMON_NAME_INVALID for
https://example.com. The certificate lists only*.example.com. - A Node.js service calling a newly deployed server fails with
unable to verify the first certificate. Chrome opens the same site without a warning. - An orders service calling the payments service, which requires mutual TLS, fails during the handshake with
tlsv1 alert unknown ca. The orders service's certificate was issued this week by a new internal CA.
Show the answers
| Case | Cause | Fix |
|---|---|---|
| Expired | The server's certificate is past its end date, or the job's machine has a wrong clock | Renew the certificate and automate renewal; check the clock |
| Wrong name | A wildcard covers one label below example.com, not example.com itself | Add example.com to the certificate's names |
| Missing intermediate | The server sends only its leaf; Chrome fetched the intermediate itself, Node does not | Configure the server to send the full chain |
| Client certificate refused | The payments service does not trust the new internal CA that issued the orders service's certificate | Add that CA to the payments service's trust store |
Case 4 is the only one where the client's certificate failed. The alert came from the server, and "unknown ca" names the check that failed: the server could not follow the client's chain to a root it trusts.
- Networking
- Security
← → move through sections and cards