This is one of the most common sources of SSL confusion: a certificate that shows a perfectly valid padlock in Chrome, but fails with a certificate error the moment the same domain is accessed from curl, a Python script, a mobile app, or an API integration. The cause is almost always the same, and it isn't a difference in security — it's a difference in forgiveness.
Why Chrome specifically is so forgiving
Chrome, like most major browsers, maintains its own cache of intermediate certificates it's encountered while browsing, and uses a feature (AIA chasing, or Authority Information Access fetching) to actively retrieve a missing intermediate from the CA directly if the server didn't provide it and the browser doesn't already have it cached. This means a browser can often silently work around a server misconfiguration that would cause other, less forgiving clients to fail outright.
Why most non-browser clients don't do this
curl, most language-specific HTTP libraries (Python's requests, Node's built-in https module), and many mobile app SSL implementations don't perform this same kind of proactive intermediate fetching or cross-session caching — they expect the server to present a complete chain in the handshake itself, and fail immediately if it doesn't, rather than attempting to independently retrieve a missing piece.
Confirming this is what's happening
openssl s_client -connect yourdomain.com:443 -showcertsRun this and count what comes back — if you see only your leaf certificate with no intermediate following it, that's definitive confirmation of the gap, independent of what Chrome happens to be masking. This is the single most reliable way to settle this question rather than debating whose behavior is "more correct."
The fix, and why it benefits every client at once
Install the complete CA-provided intermediate bundle alongside your certificate in your server's SSL configuration. Once fixed at the server level, every client — Chrome, curl, Python, mobile apps, API integrations — receives the complete chain directly and stops depending on any individual client's own forgiveness or caching behavior to work around the gap.
Why this specific bug is so persistent in the wild
Because the person who initially installs a certificate is very often testing it in their own regular desktop browser — which, per the mechanism above, may already have the relevant intermediate cached from other browsing — an incomplete chain frequently goes completely unnoticed at install time, only surfacing later when a mobile user, an API integration, or a less forgiving client encounters the same certificate for the first time with no cached workaround available.
What SNI support gaps specifically explain about this exact symptom pattern
Some older or more minimal API client libraries don't send SNI at all, or send it incorrectly, causing a server hosting multiple sites on one IP to serve the wrong (or a default) certificate to that specific client — a browser, which reliably sends SNI correctly, receives the intended certificate without issue in the exact same scenario.
How to reproduce a browser's more lenient chain-completion behavior for testing purposes
Some testing tools and libraries support explicitly loading a supplementary intermediate certificate cache, mimicking a browser's more forgiving chain-completion behavior — though the more reliable fix remains ensuring your server sends the complete chain directly, rather than relying on any specific client's caching leniency.
Why updating an outdated client library often resolves this class of issue entirely
Older API client libraries sometimes bundle their own outdated CA certificate lists or have less complete SNI and chain-handling logic — updating to a current library version often resolves this entire class of issue automatically, since library maintainers regularly update bundled trust data and connection handling logic.
What TLS library version differences across programming languages contribute to this pattern
Different programming languages' standard TLS libraries (OpenSSL bindings, native implementations) have historically varied in strictness and default behavior around chain validation and SNI — this variation across languages and their specific library versions is a meaningful contributor to why the exact same server can behave differently depending on which specific client library is connecting.
How to test using the exact same library and version your production API client uses
Writing a minimal test script using your exact production language and library version, rather than testing only with command-line curl or a browser, reproduces the actual conditions your production traffic experiences — critical for confirming a fix actually addresses your specific client's behavior rather than a different tool's potentially more lenient handling.
Why this discrepancy is a common source of confusing, hard-to-reproduce production incidents
Because a developer's first instinct when debugging is often to check the URL in a browser, which frequently works fine due to browsers' more forgiving chain-completion behavior, this exact class of issue commonly gets initially dismissed as unrelated to the certificate — only correctly diagnosed once someone specifically tests with the actual failing client or library.
What a minimal reproduction script looks like for isolating this exact issue
A minimal script using your exact production language, with nothing beyond a basic TLS connection attempt and no other application logic, isolates whether the issue is genuinely TLS-related or actually caused by some other application-level factor coincidentally correlated with the TLS connection.
How enterprise proxy and inspection software can introduce this exact symptom independently
Corporate network security software that performs TLS inspection can sometimes present its own intercepting certificate to specific traffic types while leaving others untouched, producing a symptom that looks identical to a server-side chain issue but actually originates from network-level inspection software specific to the environment the API client happens to run in.
Why documenting the specific fix once resolved helps the whole team avoid repeat confusion
Recording the specific symptom, root cause, and fix once this issue is resolved, in a shared team knowledge base or runbook, means the next person who encounters the same confusing works-in-browser-fails-in-API pattern can resolve it quickly by reference, rather than needing to rediscover the same diagnostic process independently.
A quick checklist for resolving this specific class of discrepancy
Confirm the server sends a complete certificate chain (not relying on client-side caching), test with the exact library and version your production client uses, and rule out network-level TLS inspection software specific to the failing client's environment — three checks that resolve most instances of this exact browser-works-client-fails pattern.
Why this pattern will likely keep recurring as long as client TLS implementations vary in strictness
As long as different clients continue implementing varying levels of strictness around chain completeness and validation, this general pattern, working in a lenient client while failing in a strict one, will keep recurring in some form — understanding the underlying cause, not just this specific instance, prepares you for the next time it surfaces in a different context.