TLS verification errors across tools: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed in chain

What it is

Several TLS clients describe the identical underlying failure - they could not build a chain from the server's certificate to one they already trust - in their own vocabulary. Go's crypto/x509 reports x509: certificate signed by unknown authority (since Go 1.20 prefixed with tls: failed to verify certificate:). Python's ssl module, wrapping OpenSSL, raises [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate, an error documented in the module's own reference. curl reports curl: (60) SSL certificate problem: followed by unable to get local issuer certificate or self-signed certificate in certificate chain, depending on exactly where the chain breaks, as curl's own documentation on SSL certificate problems describes; OpenSSL 1.1.1 spells it self signed. Node.js and openssl s_client report a leaf-only chain from an unknown issuer as unable to verify the first certificate.

Why it matters

The wording hints at, but does not reliably identify, the root cause, and guessing wastes time: a missing intermediate certificate is a server misconfiguration; a self-signed root at the end of the chain is either a legitimately private CA or, in rare cases, live interception; and neither is fixed by disabling verification.

How to apply

• Diagnose first: openssl s_client -connect host:443 -servername host </dev/null, documented by OpenSSL's s_client manual page, prints the certificate chain the server sent (add -showcerts for the full PEM blocks) and a Verify return code: line at the end. If the chain stops at the leaf certificate with no intermediate, the server is failing to send its intermediate bundle. If the last certificate's issuer and subject fields are identical, the chain ends in a self-signed certificate - either your own private/internal CA that the client does not yet trust, or, if you did not expect a self-signed root at all, a sign that traffic may be intercepted.
• Fixes, least to most invasive:
  1. Missing intermediate against an otherwise public CA: fix the server's own certificate bundle to include the full chain; this is not a client-side problem.
  2. Private or internal CA (common behind corporate proxies and some CI runners): install that CA into the trust store the specific failing tool actually reads, since Java's cacerts, Python's certifi bundle, Node's own store and curl/OpenSSL's system store are all separate.
  3. If the chain changed unexpectedly and interception is suspected, treat it as a security event: verify the certificate out of band before proceeding, not by disabling the check.
• Unsafe: curl -k/--insecure, Python's verify=False, NODE_TLS_REJECT_UNAUTHORIZED=0, or git -c http.sslVerify=false. Each disables the exact check that would catch a genuine machine-in-the-middle, and none of them should become a standing fix.

Pitfalls

• Fixing the trust store for one tool (the OS) while another tool (a JVM, a Python venv) keeps its own separate bundle and keeps failing.
• Treating a temporary interception (a corporate TLS-inspecting proxy) as permission to disable verification everywhere rather than trusting only that proxy's specific CA.