Progressive Hints

Hint 1 (after 5 min)

Look at the openssl s_client output. The certificate chain shows only depth 0 (the leaf certificate). A proper chain should include the intermediate certificate at depth 1. The error is "unable to verify the first certificate" — this means the server is not sending the intermediate certificate.

Hint 2 (after 10 min)

Browsers (Chrome, Firefox) and curl on macOS work fine because they have mechanisms to fetch missing intermediate certificates automatically (AIA fetching) or have the Let's Encrypt R11 intermediate cached. But strict TLS clients — Java's HttpClient, Python's requests, and Go's net/http — do not fetch missing intermediates. They require the server to present the full chain. This is why 14% of clients fail: it is the programmatic API clients, not browsers.

Hint 3 (after 15 min)

This is an API platform with TLS certificates managed by cert-manager using Let's Encrypt. The certificate was issued successfully and is marked Ready. But the TLS secret stored in Kubernetes (api-tls) contains only the leaf certificate, not the full chain (leaf + intermediate). The nginx ingress controller serves whatever is in the secret. The openssl s_client output confirms only the leaf cert is sent (depth=0 only, no depth=1 intermediate). Browsers compensate automatically, but API clients fail strict chain validation. The cert-manager configuration looks correct — the issue may be in how the secret was created or how the ingress controller reads it.