SSL certificate not trusted: fix the chain and self-signed certificates

What SSL certificate not trusted means

A browser or client trusts a certificate only if it can build a chain from your certificate, through one or more intermediate certificates, up to a root certificate already stored in its trust store. Roots come with the operating system or browser. Intermediates are meant to be sent by your server, together with your own certificate, every time a connection is made.

example.com            (your certificate, the leaf)
  issued by  Example CA R1        (intermediate, sent by your server)
    issued by  Example Root CA     (root, already on the visitor's device)

When any link is missing or unknown, the result is a not trusted warning. Browsers show it as NET::ERR_CERT_AUTHORITY_INVALID in Chrome and SEC_ERROR_UNKNOWN_ISSUER in Firefox. Command-line tools such as curl and git report SSL certificate problem: unable to get local issuer certificate. Vulnerability scanners list it as a finding called SSL Certificate Cannot Be Trusted, usually rated medium.

This is a different problem from a certificate issued for the wrong name or one that has expired, although scanners sometimes report them together. Name problems are covered in the hostname mismatch guide, and the SSL errors guide covers the wider set.

Why your SSL certificate is not trusted

Why is my SSL certificate self-signed?

Few people set out to use a self-signed certificate. It usually appears because the server is using a placeholder. Plesk and cPanel create a default certificate for new domains until a real one is issued. Linux web servers often ship with a test certificate, such as ssl-cert-snakeoil.pem on Debian and Ubuntu. And if the server cannot match the request to your site, for example because the site has no configuration for IPv6 or the request carries the wrong server name, it falls back to the default site and its certificate. In each case the cure is a real certificate on the right site configuration, not trust settings on visitors' devices.

Why it works in your browser but not for others

Some browsers can fetch a missing intermediate by themselves, using an address in the certificate, or remember intermediates from other sites. That hides a broken chain on your desktop. curl, git, payment providers, monitoring services, many apps and security scanners do not do this, so they report the certificate as untrusted.

How to diagnose an untrusted certificate

Use openssl from any machine. Always include -servername, so the server knows which site you want:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Look at two parts of the output. The Certificate chain block lists each certificate sent, numbered from 0. Number 0 is your certificate; number 1 should be its issuer. If only 0 is listed, the intermediate is missing. Then look at the verify result near the end:

Print the issuer and subject of what the server sends:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

If the subject and issuer are the same, it is self-signed. If the issuer names your control panel or a test name, the server is serving a default certificate. Repeat the test over IPv6 with -6 if the domain has an AAAA record, because a separate configuration there is a common source of default certificates.

curl is a quick second check, because it does not fill in missing intermediates:

curl -sS -o /dev/null https://example.com/ && echo trusted

Fixing the intermediate chain on your server

The fix for a missing intermediate is to configure the server with a file that contains your certificate followed by the intermediate certificates, in that order. You do not need to include the root.

Building the chain file

If your CA sent separate files, join them, leaf first:

cat example_com.crt Example_CA_R1.crt > example_com_fullchain.crt

Let's Encrypt already provides this as fullchain.pem. Use that, not cert.pem.

nginx

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Apache

From Apache 2.4.8, put the full chain in SSLCertificateFile. On older versions, use SSLCertificateChainFile for the intermediates.

SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Test the configuration and reload rather than restart, so live connections are not dropped:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

Plesk and cPanel

In Plesk, Let's Encrypt certificates are installed with their chain. For a certificate bought elsewhere, upload the intermediate into the CA certificate field when you add the certificate on the SSL/TLS Certificates screen. In cPanel, paste the intermediate into the Certificate Authority Bundle box under Install an SSL Website.

IIS

On Windows, import the intermediate into the Intermediate Certification Authorities store of the local computer, then rebind the site. The IIS bindings guide covers the binding side.

Replacing a self-signed or default certificate

A self-signed certificate cannot be made trusted by changing your server; it has to be replaced. For any public site, a free certificate from Let's Encrypt is enough:

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot --apache -d example.com -d www.example.com

In Plesk, open the domain, choose SSL/TLS Certificates and install a Let's Encrypt certificate covering the domain and its www alias. In cPanel, run AutoSSL. If the panel cannot issue one, the certificate cannot be issued guide explains the usual DNS and validation problems.

If the new certificate is installed but the self-signed one still appears, the request is reaching another site configuration. Check that every IP address the domain resolves to, including IPv6, has a matching configuration, and that the server name in that configuration matches the host visitors use.

Fixing unable to get local issuer certificate

The unable to get local issuer certificate message comes from the client. It means the client could not find the issuer of the certificate it was given, either because the server did not send it or because the client's own trust store does not contain the root.

Work out which side it is with the openssl chain test above. If the chain is complete and verifies with code 0 elsewhere, the problem is on the machine running curl, git, PHP or Python:

• Out-of-date CA bundle. Update the operating system's CA certificates package, for example sudo apt install --only-upgrade ca-certificates on Debian or Ubuntu.
• Git on Windows. Git can use its own bundle instead of the Windows store. git config --global http.sslBackend schannel makes it use the Windows store.
• Company proxy. An inspecting proxy replaces certificates with its own. Its root must be added to the client's trust store by whoever manages the network.

Never fix this by turning verification off with options such as -k or sslVerify false. That removes the check entirely.

The fix, step by step

Edge cases worth knowing

• Behind a CDN. Visitors see the CDN's certificate, so the site looks fine, while the origin may still have a self-signed one. That matters if the CDN is set to validate the origin, and scanners testing the origin will report it.
• Mail and other ports. Scanners test every TLS service, not just the website. A self-signed certificate on a mail or panel port, such as 8443 for Plesk, triggers the same finding.
• Internal systems. For hosts only staff use, a private CA is fine as long as its root is deployed to every device that connects. Do not use it for anything public.
• Extra certificates in the chain. Sending the root, or an old cross-signed intermediate, is rarely harmful but can confuse old clients. Use the chain your CA currently recommends.

Keeping the chain trusted

• Always configure servers with full chain files, and keep the chain with the certificate when you move or copy it.
• After each renewal, run the openssl s_client check against the live site and confirm a verify return code of 0.
• Include certificate checks in monitoring, testing with a client that does not fill in intermediates, such as curl.
• When moving hosts, check the new server's default site and IPv6 configuration before switching DNS. The hosting migration guide covers the checks.