"unable to get local issuer certificate" is one of the most common SSL error messages developers encounter, and it appears — worded slightly differently — across git, Python, Node.js, and many other tools, because they're all describing the exact same underlying problem: an incomplete certificate chain that the specific tool's trust store can't complete on its own.
Why this specific error is so common across so many tools
Browsers are unusually forgiving about incomplete chains because they aggressively cache intermediate certificates they've seen from prior browsing across many different sites — if a browser has recently seen the same intermediate from a different site using the same CA, it can silently complete an otherwise-incomplete chain without ever surfacing an error. Command-line tools and language-specific HTTP libraries generally don't do this kind of cross-site intermediate caching, which is exactly why the same server misconfiguration that goes unnoticed in a browser shows up immediately as a hard failure in git, curl, Python, or Node.
Confirming it's genuinely a server-side chain issue
openssl s_client -connect yourdomain.com:443 -showcertsThis is the definitive check, independent of any tool's own trust store or caching behavior — if the output shows only your leaf certificate with no intermediate following it, that confirms the server itself isn't presenting a complete chain, and every tool hitting this error is correctly reporting a genuine server-side gap rather than a client-side misconfiguration.
The fix: install the complete chain on the server
Since this is a server-side issue in the vast majority of cases, the actual fix is installing the CA's intermediate bundle alongside your certificate in your server's SSL configuration — not attempting to work around it in every individual client tool that happens to encounter it. Fixing it once, at the server, resolves it for git, curl, Python, Node, and every other client simultaneously.
Git-specific workarounds to avoid
Setting GIT_SSL_NO_VERIFY=true or git config http.sslVerify false disables certificate verification entirely for git operations — a common but inappropriate workaround for what's actually a fixable server-side chain problem. This should be reserved for clearly controlled, temporary debugging against a known environment, never left in place as a permanent configuration, since it removes real protection against traffic tampering.
The rare case where it's genuinely a client-side trust store issue
If the OpenSSL check above shows a genuinely complete chain from the server, but a specific tool still reports this error, the issue is more likely that specific tool's own trust store being outdated or misconfigured — Python's certifi package needing an update, or an older Java installation's bundled trust store lacking a newer root, are both covered in their own dedicated troubleshooting guides in this category.
Why this specific error message points so precisely at one root cause
This error message is unusually specific compared to most TLS errors — it means the client successfully received a certificate but couldn't trace it back to a trusted root, almost always because an intermediate certificate is missing from what the server sent, making the fix (installing the complete chain) usually straightforward once you know exactly what the message means.
How this error can appear on some clients but not others for the identical server
Because some clients cache or bundle commonly-seen intermediate certificates and can complete a chain even when a server doesn't send it directly, this exact error can appear on a strict client (many API libraries, older tools) while a browser with a more complete built-in cache shows no problem at all for the identical server configuration.
What to check first when this error appears in a programming language's HTTP library
Checking whether the specific library exposes a way to provide a custom CA bundle or additional trust anchors (most do, via a ca_certs or similar parameter) is usually the fastest fix — pointing the library at a current, complete CA bundle resolves the large majority of cases where the library's own default trust store is outdated or incomplete.
What specifically happens during chain validation that produces this exact wording
A client validates a certificate by walking up the chain, checking each certificate's signature against the next, until it either reaches a trusted root or runs out of certificates to check — this specific error fires precisely at the point where the client has exhausted the chain without reaching anything in its trust store, which is why the wording specifically references the local issuer being unavailable.
How to distinguish this error from a genuinely expired or revoked certificate
This specific error relates only to chain completeness, not to a certificate's validity period or revocation status — a certificate can be perfectly valid, unexpired, and unrevoked while still triggering this exact error purely because the chain connecting it to a trusted root is incomplete.
Why some CDNs and hosting platforms are more prone to this specific misconfiguration
Platforms that generate certificates automatically but don't automatically bundle the correct intermediate alongside them, or that have a more complex multi-layer proxy architecture, are more prone to accidentally serving an incomplete chain than a simple, directly-configured single server — worth being particularly attentive to chain completeness specifically when troubleshooting a CDN or platform-fronted domain.
What role operating system certificate stores play versus application-specific ones
Some applications use the operating system's certificate store directly, while others (many Python and Node.js installations, for instance) bundle or reference their own separate trust store independent of the OS — understanding which category your specific failing application falls into determines whether fixing the OS trust store actually resolves the issue or whether an application-specific fix is needed instead.
How to fix this permanently rather than working around it for a single request
The permanent, correct fix is always installing the complete certificate chain on the server side — client-side workarounds (disabling verification, manually trusting a specific certificate) address only your own single client's symptom while leaving the underlying server misconfiguration in place, still affecting every other client connecting to that same server.
Why disabling certificate verification is never the right fix despite being the fastest workaround
Disabling verification entirely removes TLS's core security guarantee, that you're actually connecting to who you think you're connecting to, turning encryption into a much weaker guarantee against a man-in-the-middle — this should never be treated as an acceptable production fix regardless of how much faster it resolves the immediate symptom.
A quick checklist for resolving this error definitively
Confirm the server sends a complete chain via OpenSSL's s_client, check whether your specific client has its own separate trust store needing an update, and if the server-side chain is genuinely incomplete, fix it there rather than working around it client-side — three steps that resolve the overwhelming majority of instances of this specific error.
Why this remains one of the most searched TLS error messages for good reason
This error's precise, technical wording combined with how frequently an incomplete chain misconfiguration actually occurs makes it one of the most commonly searched TLS error messages online — understanding it thoroughly, as covered throughout this guide, resolves a disproportionately large share of real-world TLS troubleshooting situations.