Fix certificate verify failed and unable to get local issuer certificate
“certificate verify failed” and “unable to get local issuer certificate” are trust-validation failures, not instructions to turn TLS checks off. Compare the actual client, endpoint, served chain, hostname, time and trust store, then repair the demonstrated server or client boundary.
Restore an authenticated TLS connection with a verified server identity and an approved trust chain, preserving enough evidence to distinguish a missing intermediate from a client-store, hostname, clock or interception problem.
- Ubuntu Server 24.04 LTS
- OpenSSL 3.x; check packaged options
- curl and Python Supported distribution packages; identify the actual TLS backend
- Authorized endpoint Use only an endpoint and diagnostic request you are authorized to inspect. Record its DNS name, port, protocol and the affected application's owner.
- Original client context Identify the process, runtime version, host or container, proxy route and configured trust store. A browser on another machine is a comparison, not the failing client.
- Trusted CA source Obtain any proposed private root certificate and its expected SHA-256 fingerprint from an independently authenticated organizational channel, not the failed connection.
- Recovery access Preserve the existing server-chain and trust configuration. Agree on rollout and rollback before changing trust for an entire host or restarting a service.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A client-specific certificate failure record with a demonstrated trust or identity cause.
- A scoped repair whose success does not rely on weakening TLS validation.
- Separate missing intermediates from missing client trust anchors.
- Keep hostname, time, purpose and client-store evidence distinct.
- Verify the affected application's real connection and deployment lifecycle.
Architecture
How the parts fit together
Trace the connection from the actual client through its route to the TLS terminator, then compare the presented chain against the approved trust input.
- Capture the exact failure and client context.
- Compare identity, validity, served certificates and approved trust.
- Repair the demonstrated owner boundary.
- Verify valid connections and controlled rejection behavior.
Assumptions
- Examples are illustrative; no customer endpoint, private PKI or production trust store was modified while preparing this Guide.
- Commands use Linux shell syntax and packaged OpenSSL 3.x; check local option support before running.
- The installation branch is Ubuntu-specific. macOS, Windows and application-specific stores require their own documented procedures.
Key concepts
- Leaf certificate
- The certificate identifying the service; its DNS identity and validity must match the connection.
- Intermediate certificate
- An issuing certificate used to build a path; possession of it does not make it a trusted root.
- Trust anchor
- A root or explicitly approved trust input accepted through an independent policy decision.
- Verification context
- The real client's trust source, expected identity, purpose, time and any additional policy checks.
Fill these once. Every matching command and configuration block updates immediately; values stay in this page only.
Security and production boundaries
- Never solve this error with --insecure, verify=False, disabled hostname checking or a global TLS-verification bypass.
- Do not authenticate a new root using only material received through the connection that failed verification.
- Public certificates can reveal internal names; logs, paths and session details still need appropriate handling.
Stop before continuing if
- Stop when the issuer or proxy is unexpected and its authority cannot be independently verified.
- Stop before overwriting an existing trust file or reloading a service without an approved recovery path.
- Stop when a probe used another endpoint, client context or verification policy and cannot explain the original error.
command
Record the exact verification failure and client context
Start with the original exception and timestamp. Preserve the first certificate error, not only a final connection-failed summary. Record whether the failure concerns the destination server, an HTTPS proxy, or mutual-TLS client authentication; these are different verification directions.
Why this step matters
The same error label can arise at several trust boundaries, so retain the exact failing client and transaction before selecting a repair.
What to understand
Choose a documented read-only requestPath and do not include tokens in the URL. This command sends one GET; even GET endpoints can have application effects, so confirm the route is appropriate. Keep the original application's error separately because curl may use a different TLS library, proxy or CA configuration.
Do not dump environment variables, connection secrets, cookies or private keys into a public ticket. Record only the names and approved paths of relevant settings. A corporate proxy or endpoint-security product may present a different issuer on a particular network; unexpected interception is a security question, not an invitation to trust that issuer.
System changes
- Sends one approved GET and reads tool versions and time. No verification settings or trust stores are changed.
Syntax explained
--connect-timeout 5 --max-time 15- Bounds connection establishment and the complete diagnostic transfer.
--output /dev/null --write-out- Discards the response body while reporting HTTP status; 000 means no HTTP response was obtained, not an HTTP error code.
Values stay on this page and are never sent or saved.
date -u --iso-8601=seconds; openssl version; curl --version; curl --connect-timeout 5 --max-time 15 --silent --show-error --output /dev/null --write-out 'http_code=%{http_code}\n' 'https://{{tlsHost}}:{{tlsPort}}{{requestPath}}'Illustrative client evidence: curl: (60) SSL certificate problem: unable to get local issuer certificate http_code=000 Python application: ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed These messages do not by themselves identify which certificate or store is wrong.
Checkpoint: Failing trust boundary identified
Continue whenThe original error, client context, endpoint and request are recorded without secrets.
Stop whenThe connection is unauthorized, its proxy route is unknown, or the proposed probe would expose credentials.
command
Inspect what the server sends while enforcing verification
Connect with the intended DNS name explicitly supplied as both SNI and the verification identity. Retain the certificate list and first verification reason. The list printed by showcerts is what the peer sent; it is not proof that a valid chain was built.
Why this step matters
A correctly selected endpoint and explicit verification identity make certificate evidence comparable without accepting an untrusted handshake.
What to understand
The examples target direct TLS, such as HTTPS. SMTP, LDAP and other STARTTLS services need their documented protocol negotiation; sending a direct-TLS probe to a plaintext port gives unrelated evidence. Preserve a timeout as a timeout rather than calling it a certificate failure.
Do not infer success from CONNECTED, a printed cipher or an exit status after a truncated test. Require a completed successful verification result and an application check. Redact session identifiers and internal certificate names before sharing logs. A different IP, address family or load-balancer member can present a different chain, so retain the tested route.
System changes
- Opens one bounded TLS diagnostic connection. It does not install certificates or change the server.
Syntax explained
-servername and -verify_hostname- Selects the virtual TLS host and independently checks the expected DNS identity.
-verify_return_error- Stops on certificate verification failure instead of continuing as a diagnostic-only client.
timeout 15 and </dev/null- Bounds a non-interactive probe; timeout or early closure is not a successful validation result.
Values stay on this page and are never sent or saved.
timeout 15 openssl s_client -connect '{{tlsHost}}:{{tlsPort}}' -servername '{{tlsHost}}' -verify_hostname '{{tlsHost}}' -verify_return_error -showcerts </dev/nullIllustrative failure: depth=0 CN=api.example.net verify error:num=20:unable to get local issuer certificate Verification error: unable to get local issuer certificate Inspect the peer-supplied list and the client's intended trust anchors separately.
command
Check the leaf identity, validity and issuer without trusting it
Obtain the leaf certificate as a PEM file from the captured public certificate data or the server owner's configuration inventory. leafCertificate must contain the intended leaf, not a private key or a concatenation whose first object is an unrelated CA. Inspect its names and validity, then compare them with the original connection.
Why this step matters
A trusted issuer cannot compensate for the wrong endpoint identity or validity window, so those checks precede trust-store changes.
What to understand
Compare the exact requested hostname with the subjectAltName entries. A certificate for one service does not become valid for an arbitrary alias because both addresses reach the same machine. Request an appropriately issued replacement through the owner when identity is wrong; do not suppress hostname checking.
Confirm the host's time source before changing its clock. A large manual clock jump can affect authentication, databases and jobs. Record the old observation and escalate a clock-policy failure to the platform owner. Certificate expiry calls for renewal and controlled deployment, not installation of the expired leaf as a trusted root.
System changes
- Reads a local public certificate file and UTC time. It does not alter the certificate or clock.
Syntax explained
-noout -ext subjectAltName- Shows certificate metadata and DNS identities without re-emitting the PEM body.
-fingerprint -sha256- Provides a stable comparison value; a fingerprint displayed by an untrusted source is not independent authentication.
Values stay on this page and are never sent or saved.
openssl x509 -in '{{leafCertificate}}' -noout -subject -issuer -serial -dates -fingerprint -sha256 -ext subjectAltName; date -u --iso-8601=secondsIllustrative comparison: subject=CN=api.example.net issuer=CN=Example Issuing CA X509v3 Subject Alternative Name: DNS:api.example.net A request for a different name, an expired certificate or an incorrect system clock needs its own repair.
command
Distinguish missing intermediates from missing trust anchors
Use an independently approved root bundle, the leaf PEM and a separate PEM containing candidate intermediate certificates. A root bundle is an explicit trust decision; an intermediate bundle is untrusted chain-building input. Do not promote every certificate sent by the server into the trusted root set.
Why this step matters
An explicit offline comparison separates the candidate issuing chain from the trust anchors approved by the organization.
What to understand
Obtain intermediate material from the certificate issuer's authenticated distribution channel or the service owner. Cross-signed and rotated chains can offer more than one path; select the supported path for the intended clients rather than deleting certificates until one tool succeeds.
A local OK result validates the specified files under the selected options. It does not establish that every load-balancer node serves those files, that revocation requirements are satisfied, or that the affected runtime uses this root store. If no intermediate is required, omit -untrusted instead of inventing a dummy file. Keep the actual client validation policy as the acceptance criterion.
System changes
- Performs offline verification of public certificate files; no global trust or server policy is changed.
Syntax explained
-CAfile with -no-CApath -no-CAstore- Uses the specified approved trust file without adding default directory or store inputs for this comparison.
-untrusted- Supplies candidate intermediate certificates without declaring them trust anchors.
-purpose sslserver- Checks the selected certificate for TLS server use as well as the requested hostname.
Values stay on this page and are never sent or saved.
openssl verify -purpose sslserver -verify_hostname '{{tlsHost}}' -CAfile '{{approvedCaBundle}}' -no-CApath -no-CAstore -untrusted '{{intermediateBundle}}' '{{leafCertificate}}'Illustrative comparison: With the approved root but without the required intermediate: unable to get local issuer certificate With that same approved root and the correct intermediate: leaf.pem: OK This supports a chain-completeness hypothesis; verify the actual server after its configuration is corrected.
Checkpoint: Demonstrated certificate or store mismatch
Continue whenEvidence identifies the missing or incorrect chain element, identity, time or client trust source.
Stop whenThe proposed root's provenance is unverified or the conclusion depends on disabling verification.
command
Inspect the affected runtime instead of assuming browser trust applies
For a Python application, run this read-only inspection with its actual interpreter and launch context. It identifies Python/OpenSSL default lookup locations, not every library's effective configuration. Compare explicit SSLContext settings and the application's HTTP library with the process owner's help.
Why this step matters
Trust is applied by the actual client runtime, which can differ from the interactive shell, browser and host image.
What to understand
Use the service's real interpreter; a global python3 result is not evidence about a virtual environment. The standard library's default paths do not prove that a third-party HTTP client uses them. Read the library's configured verification settings without printing secrets, and keep hostname verification and certificate validation enabled.
For containers, distinguish the host's trust from the image's CA files and the running process's store. A change made interactively inside a disposable container can disappear on replacement; implement the approved certificate in the controlled image or documented runtime mount and verify a replacement instance. Java, Node.js and native OS clients need their own documented store checks rather than this Python command.
System changes
- Reads interpreter and default SSL configuration. No application settings or certificate stores are modified.
Syntax explained
sys.executable- Identifies the interpreter actually running this probe.
ssl.get_default_verify_paths()- Reports default OpenSSL trust lookup locations; it does not enumerate all custom library contexts.
python3 -c 'import ssl,sys; print(sys.executable); print(ssl.OPENSSL_VERSION); print(ssl.get_default_verify_paths())'Illustrative evidence: /opt/example/venv/bin/python3 OpenSSL 3.x DefaultVerifyPaths(cafile=..., capath=..., openssl_cafile_env=..., ...) An application may still pass its own cafile or context; inspect that configuration separately.
decision
Repair the owner of the demonstrated failure
For a public endpoint with a missing intermediate, correct the certificate chain at the server, ingress or load balancer that terminates TLS. For a private service with a valid chain, distribute only the organization's authenticated trust anchor to the intended client scope. Keep those repairs separate.
Why this step matters
The narrowest owner-approved change preserves the security boundary and provides a testable explanation of the original failure.
What to understand
An NGINX certificate file normally supplies the leaf followed by its intermediate certificates. Test the owned configuration before a controlled reload and inspect the resulting connection, not merely the file on disk. Do not ship the CA private key to a web server. When the issue is hostname, expiry or clock, fix that demonstrated cause instead of broadening trust.
For an approved private CA on Ubuntu, first verify its fingerprint out of band and confirm its CA role. Then use the explicit installation step below only if system-wide trust is intended. Prefer an application-specific documented CA bundle when the trust decision should be limited to one workload. Unknown interception, a surprise new issuer or an unreviewed root calls for security-owner investigation.
System changes
- This decision executes no repair. Server reloads, certificate deployment and trust changes require an owner-approved scope and rollback.
Change-plan example: Cause: one ingress revision omitted the issuing intermediate. Change: restore the reviewed leaf-plus-intermediate chain through the ingress owner. Controls: same DNS identity, same client store and every relevant endpoint member. Rollback: previous owned certificate configuration, without weakening verification.
command
Install an authenticated private root only when host-wide trust is approved
This is a conditional Ubuntu branch, not a required fix for every verification error. approvedRootCertificate must be a single authenticated PEM CA certificate. Confirm the fixed destination is unused or preserve its existing owned contents before running; do not overwrite an unrelated trust anchor.
Why this step matters
Trust-store changes can authorize a CA for many clients, so installation is gated on provenance and the intended scope.
What to understand
The .crt file must contain a PEM certificate, one certificate per file, and no private key. Retain the authenticated fingerprint, owner, intended services and removal procedure. Do not copy a server leaf from an unverified connection into this directory to make an error disappear.
Some applications load trust at startup or use separate stores. Follow the specific application's documented reload or rollout behavior with traffic and state impact considered. A successful update-ca-certificates command does not update every language runtime or container. Do not use a global verification-disable environment variable while waiting for a rollout.
System changes
- Adds or replaces the specifically reviewed local CA file and regenerates the system trust store. This can affect multiple applications.
Syntax explained
install -o root -g root -m 0644- Installs public CA material with administrator ownership and readable certificate permissions, not secret-key permissions.
update-ca-certificates- Regenerates Ubuntu's managed system trust output from its configured sources.
Values stay on this page and are never sent or saved.
sudo install -o root -g root -m 0644 '{{approvedRootCertificate}}' /usr/local/share/ca-certificates/oneliners-approved-private-root.crt && sudo update-ca-certificatesIllustrative approved change: Updating certificates in /etc/ssl/certs... 1 added, 0 removed This is installation evidence, not proof that the affected application now validates its peer.
verification
Verify the original client and keep rejection behavior intact
Repeat the original operation from the same application context with all verification enabled. Record the served identity and certificate chain after the change, and check the intended endpoint members. A successful tool probe is a prerequisite, not a substitute for application acceptance.
Why this step matters
Recovery must preserve both legitimate connectivity and the client's ability to reject an unintended peer.
What to understand
Use a controlled non-production fixture for negative checks; do not redirect production traffic to a hostile endpoint or change public DNS to test rejection. Preserve the test identity and expected reason. Revocation and organizational policy checks remain requirements where the real client applies them.
If only one workstation succeeds, compare actual route, client store and deployment revision before declaring recovery. Establish certificate-expiry and rollout checks with an owner, and test a replacement container or service instance when the repair changed immutable deployment inputs.
System changes
- Sends one approved read-only request. Negative tests require a separately controlled fixture.
Syntax explained
No verification override- Uses the client's configured normal verification path, so an insecure bypass cannot masquerade as the final test.
Values stay on this page and are never sent or saved.
curl --connect-timeout 5 --max-time 15 --silent --show-error --output /dev/null --write-out 'http_code=%{http_code}\n' 'https://{{tlsHost}}:{{tlsPort}}{{requestPath}}'Acceptance record example: The original application succeeds using its intended trust source. The endpoint identity and deployment match the approved change. A controlled test with an untrusted CA or wrong hostname is still rejected. No --insecure, verify=False or global TLS-verification bypass was introduced.
Checkpoint: Authenticated connection restored
Continue whenThe original client succeeds with the intended identity and trust policy; controlled invalid peers remain rejected.
Stop whenThe result depends on a different client, disabled validation, an unapproved root or only one unverified endpoint member.
Finish line
Verification checklist
curl --connect-timeout 5 --max-time 15 --silent --show-error --output /dev/null 'https://{{tlsHost}}:{{tlsPort}}{{requestPath}}'The baseline curl probe validates normally, and the original application's independently recorded operation also succeeds.timeout 15 openssl s_client -connect '{{tlsHost}}:{{tlsPort}}' -servername '{{tlsHost}}' -verify_hostname '{{tlsHost}}' -verify_return_error </dev/nullThe intended endpoint completes certificate verification; a timeout or early close is inconclusive. The owner also records controlled wrong-hostname/untrusted-CA rejection in a non-production fixture.Recovery guidance
Common problems and safe checks
unable to get local issuer certificate
Likely causeThe client cannot build a path through the available intermediates to an accepted trust anchor.
Compare the peer-supplied list with the issuing chain.Verify local files against an authenticated root bundle.Inspect the actual client's store.
ResolutionRepair the missing server intermediate or distribute the approved root to the intended client scope, according to the demonstrated cause.
certificate verify failed only inside a container
Likely causeThe image or runtime has different trust inputs from the host.
Identify the actual image revision and process configuration.Compare its CA source with the approved deployment input.
ResolutionUpdate the controlled image or documented mount and verify a replacement instance; do not rely on an interactive one-container modification.
Browser succeeds but the application still fails
Likely causeThe clients use different routes, cached chains, stores or policies.
Compare the exact endpoint and issuer seen by both clients.Identify the application's TLS backend and configured trust source.
ResolutionRepair the application's demonstrated configuration or the incomplete endpoint chain rather than making every client accept arbitrary certificates.
Reference
Frequently asked questions
Does certificate verify failed always mean the certificate expired?
No. It can reflect chain-building, trust, identity, time or policy failures. Preserve the specific verification reason and inspect those boundaries separately.
Should I fix unable to get local issuer certificate by trusting the server leaf?
No. Establish whether an intermediate is missing or the client lacks an authenticated approved root. Trusting an arbitrary leaf changes the trust policy rather than explaining the failure.
Why does openssl s_client print CONNECTED even when verification fails?
A transport connection is not certificate acceptance. Use explicit verification-error handling and the expected hostname, then confirm the original application result.
Can I disable TLS validation temporarily?
That can expose credentials and data to an unintended peer. Use a controlled non-production diagnostic fixture and repair the demonstrated trust or identity problem with validation enabled.
Will updating Ubuntu's CA store fix every application?
No. Runtimes, containers and explicitly configured libraries may use another store or need a controlled reload. Verify the actual process and deployment inputs.
Recovery
Rollback
Restore the specifically changed certificate or trust input through its owner; never restore connectivity by disabling verification.
- Preserve the failed and successful certificate fingerprints, client context and configuration revision.
- Restore the previous server chain or the previous contents of the exact local CA file. If the file was newly added, remove only that reviewed file through the normal configuration workflow and regenerate the system trust store.
- Use the documented service reload or controlled rollout, then verify the original client and relevant unrelated workloads.
- If the previous configuration reintroduces the original failure, keep it visible and use an owner-approved service mitigation rather than accepting untrusted peers.
Evidence