An Untrusted Chain Is a Reason to Investigate
When Ledger Live reports self signed certificate in certificate chain, do not add the presented certificate to trusted roots simply because the message mentions a certificate. The app now uses Ledger Wallet branding. The secure connection has not passed its expected trust check, and changing that trust decision requires more evidence than a successful page load.
The wording can appear in environments using inspection gateways, proxies, or security products that substitute certificates. It is not enough to identify which component is responsible, and it does not by itself prove that Ledger’s service certificate was self-signed.
Separate the Certificate You See From the Intended Server
A certificate chain links a server’s identity to an authority the client trusts. An untrusted self-signed certificate encountered during that process can stop verification. OpenSSL’s verification documentation explains why chain building and trust anchors matter; a trusted root is a deliberate security decision rather than a missing wallet setting.
Do not confuse a corporate gateway certificate with a hardware-wallet genuine-check result. Those checks address different systems. Resolving network access does not justify overriding an explicit device authenticity rejection.
Use the Request as the Unit of Comparison
Record the exact feature, complete error, approximate time, and whether a proxy or VPN was active. Compare one harmless request, such as opening the management view, on a trusted permitted alternative connection. Retain the same application and hardware so the result remains interpretable.
For example, if account refresh and app-catalog access both fail only on office Wi-Fi, that pattern supports investigating shared network policy. If only one provider panel fails everywhere, include that provider rather than describing the entire application as offline. Neither pattern proves a specific certificate should be trusted.
Handle Managed Inspection With the Administrator
Ask whether TLS inspection is expected for this application and whether a supported approved connection is available. Provide the observed issuer or sanitized certificate information only through the organization’s normal diagnostic process. Let the administrator verify the gateway configuration and the application’s supported trust behavior.
Do not download a repair root from a search ad, install a random configuration profile, or alter trust stores until the alert disappears. The Ledger issuer-certificate article identifies network intermediaries as relevant; it does not make an unknown authority legitimate.
Check the Personal Host Without Broad Exceptions
If the error also occurs away from the managed network, note security products that inspect encrypted traffic, recent updates, and any matching event. Ask the responsible vendor for a remedy tied to that event. A broad antivirus exclusion or disabled firewall is not a certificate-chain diagnosis.
Keep the operating system and official wallet client maintained. Verify replacements through the publisher’s distribution page. Do not lower TLS security or use a startup command that suppresses validation. Such a change can conceal the failure instead of establishing the server’s identity.
Confirm the Outcome Without Signing Anything
Repeat the original read-only request after the supported configuration repair. Record whether validation succeeds and the intended feature responds. If the error remains, stop before authorizing financial activity and send the scoped result to official support.
Are All Self-Signed Certificates Malicious?
No. Their presence can be intentional in private systems. The relevant question is whether this authority is appropriate and trusted for this connection under the application’s supported configuration.
Can a Correct Clock Make an Unknown Issuer Trustworthy?
No. Time checks and issuer trust are different conditions. Do not backdate the computer or assume an accurate date validates an otherwise untrusted chain.
Does This Require My Recovery Phrase?
Certificate troubleshooting uses connection evidence. Recovery words, hardware PINs, and payments to a validation address have no legitimate role in repairing the chain.