Who do we trust? CAs, trust stores and self-signed certificates

A certificate is signed by a CA. That CA’s certificate is signed by another CA, and so on, until you reach a certificate that signed itself: a root certificate. So why trust the root?

Not because it signed itself. Anyone can make a self-signed certificate in one command, with any name they like, including “Very Trustworthy Root CA”. A root is trusted for one reason only: it is already on a list inside your device or your software. That list is called a trust store.

Who decides what goes on the list?

• Browser and operating-system makers run root programs. Mozilla, Google (for Chrome), Apple and Microsoft each decide which public CAs to include. A CA must pass yearly audits and follow strict rules to stay in.
• Your organisation’s IT team can add its own roots to company devices, for example for internal websites.
• You, when you install a root on your own computer.

Here is the catch: there is no single list. Your phone, your laptop, the Java application on a server and the Docker container next to it can each have a different trust store. The same website can be trusted by one of them and rejected by another, and both are behaving correctly.

A self-signed certificate on a server, one that no CA vouched for, is rejected everywhere it has not been installed. The warning does not mean the encryption is weak. It means nobody your device trusts has confirmed that the key belongs to that name, so you could be talking to anyone, including someone in the middle.

What is a trust anchor?

Path validation in RFC 5280 section 6.1 starts from a trust anchor: a CA name and public key that the client accepts without further proof. Trust anchors are usually distributed as self-signed root certificates, but the self-signature adds no trust. It shows only that the file is intact and was made by whoever holds the root’s private key.

Everything else follows from the anchor. A client accepts a server certificate only if it can build a chain of valid signatures from that certificate up to one of its anchors (chapter 13).

Who decides which roots are public?

Four root programs cover almost every device:

• the Mozilla Root Store Policy, used by Firefox and, through the NSS library, by many Linux distributions;
• the Chrome Root Program, whose root store Chrome uses on Windows, macOS, ChromeOS, Linux and Android (Apple’s rules prevent it on iOS);
• the Apple Root Certificate Program, for macOS, iOS and Safari;
• the Microsoft Trusted Root Program, for Windows.

Each program requires the CA to follow the CA/Browser Forum’s Baseline Requirements, to pass independent audits, and to report incidents. When a CA breaks the rules badly, the programs remove it (chapter 18).

Which trust store does my software use?

This is where most “it works on my machine” problems come from:

Three details catch people out:

• Node.js reads NODE_EXTRA_CA_CERTS “only when the Node.js process is first launched”, and ignores it completely when code passes its own ca option (Node.js CLI docs). Since Node 23.8, --use-system-ca adds the operating system’s roots.
• Python requests does not use the operating system’s store. It uses certifi, so a root installed on Windows or in /etc/ssl is invisible to it (Requests docs).
• Minimal container images often contain no CA bundle at all, so every HTTPS call fails with x509: certificate signed by unknown authority until you install the ca-certificates package.

Swipe sideways to see the whole diagram.

What do self-signed errors look like?

There are two cases, with different messages:

• The server sends only a self-signed certificate. OpenSSL reports verify error:num=18:self-signed certificate, and Node.js reports DEPTH_ZERO_SELF_SIGNED_CERT.
• The server sends a chain that ends in a root the client does not trust. OpenSSL reports verify error:num=19:self-signed certificate in certificate chain, curl says SSL certificate problem: self-signed certificate in certificate chain, and Node.js says SELF_SIGNED_CERT_IN_CHAIN.

When the root is not sent at all, the same root cause shows up as “unable to get local issuer certificate” instead. In every case, the fix is to make the client trust the right root, not to switch checking off.

Why do private roots exist?

Organisations run their own CAs for internal names, devices and staff (chapter 22). A private root works exactly like a public one, but only inside trust stores where someone installed it. That is the point: an internal CA should not be able to issue certificates that the whole internet trusts. The cost is distribution. Every device, runtime and container that talks to internal services needs that root.

What is a TLS-inspection proxy?

Many companies route web traffic through a proxy that decrypts and inspects it. The proxy holds a private root that is installed on every company laptop. When you open https://example.com, the proxy connects to the real site, checks its certificate, then gives your laptop a new certificate for example.com, issued on the spot by the proxy’s root. Your browser accepts it, because the OS store contains that root.

Tools with their own trust store do not. Node.js, Python requests, Java, git and containers on the same laptop fail with “unable to get local issuer certificate” or “self-signed certificate in certificate chain”, while the browser works. The fix is to add the company root to those tools’ stores. Keep two facts in mind: anyone who controls a root in your store can read your TLS traffic, so install only roots your organisation controls; and the proxy now makes the trust decisions for you. Chrome, for example, honours locally added roots for TLS over TCP but not for QUIC, the transport of HTTP/3 (Chrome Root Store FAQ).

Which store is my client using?

Ask each runtime. These commands ran on a Windows laptop in Git Bash; on Linux the paths differ:

openssl version -d
python -c "import ssl; print(ssl.get_default_verify_paths())"
python -c "import certifi; print(certifi.where())"
node -p "require('tls').rootCertificates.length"

OPENSSLDIR: "/mingw64/etc/ssl"
DefaultVerifyPaths(cafile=None, capath=None, openssl_cafile_env='SSL_CERT_FILE', openssl_cafile='C:\\Program Files\\Common Files\\SSL/cert.pem', openssl_capath_env='SSL_CERT_DIR', openssl_capath='C:\\Program Files\\Common Files\\SSL/certs')
C:\Users\…\Python313\Lib\site-packages\certifi\cacert.pem
150

Four answers, four different places: OpenSSL’s own folder, Python’s OpenSSL defaults (plus the Windows store, which ssl loads on Windows), certifi’s bundle for requests, and 150 roots compiled into this Node.js 23 binary. For Java, keytool -list -cacerts lists the JDK’s roots.

What happens with a private root?

We ran a test server whose chain ends in a private root, “Keystone Demo Root CA”, and sent the whole chain, root included. Nothing on the laptop trusts that root yet:

openssl s_client -connect 127.0.0.1:8443 -servername www.example.com </dev/null

depth=2 C=BE, O=Keystone Demo, CN=Keystone Demo Root CA
verify error:num=19:self-signed certificate in certificate chain
...
Verify return code: 19 (self-signed certificate in certificate chain)

Node.js and Python give the same verdict in their own words:

SELF_SIGNED_CERT_IN_CHAIN: self-signed certificate in certificate chain
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1028)

A server that presents only a self-signed certificate, with no chain, fails slightly differently:

verify error:num=18:self-signed certificate
DEPTH_ZERO_SELF_SIGNED_CERT: self-signed certificate; if the root CA is installed locally, try running Node.js with --use-system-ca

Now give Node.js the root, and only the root, as an extra trusted certificate:

NODE_EXTRA_CA_CERTS=root.crt node -e "const s=require('tls').connect({host:'127.0.0.1',port:8443,servername:'www.example.com'},()=>{console.log('OK, authorized:',s.authorized);s.end()});s.on('error',e=>console.log(e.code+':',e.message))"

OK, authorized: true

Verification is still fully on. The client now simply knows one more anchor.

How do I add a private root?

First, check that the file is the root you expect. Compare its fingerprint with the value your IT team publishes through a channel you trust, as the keytool documentation also advises:

openssl x509 -in corp-root.crt -noout -subject -fingerprint -sha256

Then add it to every store your clients use. The file must be the PEM root certificate, never a private key:

# Debian and Ubuntu: the file name must end in .crt
sudo cp corp-root.crt /usr/local/share/ca-certificates/corp-root.crt
sudo update-ca-certificates

# Red Hat, Fedora and similar
sudo cp corp-root.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# macOS
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain corp-root.crt

# Java (JDK 17 and older, and Debian/Ubuntu packages, ask for the cacerts password "changeit"; newer JDK builds such as Temurin 18+ have none)
keytool -importcert -cacerts -alias corp-root -file corp-root.crt

# Node.js, for processes started from this shell
export NODE_EXTRA_CA_CERTS=/path/to/corp-root.crt

# Python requests: point it at a bundle that contains the root
export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt

# Windows, as administrator: the computer's Trusted Root store
Import-Certificate -FilePath .\corp-root.crt -CertStoreLocation Cert:\LocalMachine\Root

On managed fleets, distribute roots with Group Policy, Intune or an MDM profile rather than by hand, and remember to bake them into container images.

Which errors point here?

An untrusted or missing root produces most of the classic messages:

• browsers: NET::ERR_CERT_AUTHORITY_INVALID and SEC_ERROR_UNKNOWN_ISSUER;
• tools: curl’s self-signed chain error, SELF_SIGNED_CERT_IN_CHAIN, npm’s UNABLE_TO_GET_ISSUER_CERT_LOCALLY and Go’s x509: certificate signed by unknown authority;
• runtimes: Java’s PKIX path building failed, Python’s CERTIFICATE_VERIFY_FAILED and .NET’s The remote certificate is invalid.

If the root is trusted but the error persists, the server is probably not sending its intermediate. That is the next chapter.

Try it: Chain checkerOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste the chain

Try a sampleChoose a sample…A complete chain: leaf, intermediate and rootA server that forgets its intermediateA chain in the wrong orderA self-signed root CA

-----BEGIN CERTIFICATE----- MIIFxDCCA6ygAwIBAgIQV3/H8mpwNp5raCafwOtSezANBgkqhkiG9w0BAQsFADB7 MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UE CxMeU2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSgwJgYDVQQDEx9QS0kg WmVybyB0byBIZXJvIFNhbXBsZSBSb290IENBMCAXDTI1MDEwMTAwMDAwMFoYDzIw NTAwMTAxMDAwMDAwWjB7MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8g dG8gSGVybzEnMCUGA1UECxMeU2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVk MSgwJgYDVQQDEx9QS0kgWmVybyB0byBIZXJvIFNhbXBsZSBSb290IENBMIICIjAN BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAnYTGHkYMca54QPkZcZENin3BHB3t uKdHkDZeKZvJHWqpfXpcZfusLvtJFeTrwWlEDBJuV20vmhaLeV29QeYKaIkm1Ul2 qCkrLUpWn/W9CPosfVqMd1nOrd+Ka9iPSeKlW3YX1P5WqQEjieJhBzT9comdj8qN /PynceTDcLa2mgYw7QhU8trBoLzhYqIJFfoUBk+7lahae8b9G5wKCbDicRM8/ATt 0dO9jCxi6RxJpkKl24ULgNOuFP9gG4nubWA8+BaMeM0LU64wNciFofgM2g/3iHHn zmcoe1z80C7WN+GuzNkWkN8D/tcqrbua0O5fREKKw6PyyxwQsjeMghpxLb0h1KeA ihpQMVgpWbhRkkpvF5odkF9vTJP89Z2y+8cgnUMyTpXATrt8KgC5LdWo5mlTNXC/ MvbCUb1Vz9bvcEx2y29tUeLIAUmyBzhF7zgMUPAOtDbLLCuxgR78T2TWaXB/8WBT XL44Wk5rOe7U+KuBr/t12AcZjaq0AGiNsvfd1P+IFbRivElegpdrM+S3arjOjptP M9sUl9Hc+cszaTpEVcQFFxcIyvq5HVjTlZr4vLKdqlhSkQB9hZUFuWNpnUZEYEnA 1vn/GkHNTJ6pv8XxdNXkFeRaUv3ajCn7CQ3UP/EXJqzBw5fl6aa9lqKTS5kF9rgw EIhwNaSd2O557KUCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFIVx1Hy1TuED0pMkxEcdM+DWWPGiMA0GCSqGSIb3DQEB CwUAA4ICAQBMdaOOM84aoItvumQ/sNzOhXvmLwboTb3oe67wda9TvPMSf2aP3JtP UWsR/9UbZgNE9M41p2+XZlVpsGP1BLEvi5ZwfMWmR876Mw1Zkt8ouY3DWN08egnm IdV2vKwDHhDE93IQ12fjNc8iuMCasoYiXTsmXx3R/+PkNbeBAupZEk6EwTr75PCY IJ2cheL7jQ06xeCCZv815rG+63jGk3tys7A+nUXKqOp9oN/dkEhi+YWiHG9UJ2w/ BDZCFUUoJBia7C3+hcXZAVxtWwTy0A5T/plEsqGcdfCMFA4cOFstthyS/Wnnuw8y cpSiXdUAQbLkJ+CGavr6MXVmDicmnV9p3Pv9EbpGPV8UlxwvoQMf+ajEE4EAaJkN Gc85wOC7Y7wwWkBnzjiyLztqRqOFdHEdM13V+2Gw2545Jk8o2gRizBQ6Ey6rlt2u YdYFqFFQhe2H+VqvJiLKefkN1mVQhvhfAvuoxZWIsDtyJWGs12L06xMj3wG98kne mUJjPzze3swZU39eiaC1MBs6U0oLZE6ZqubmjJd/ppmGyK+7o2SMi0juouvw6rcA J9eUJQLNpiVKmiwzKvPejASpunK5B5JO3Y7NAb4SVU22ItR73bBiRAugPwVajlBN RGcjMkDSiW07/dhN6GgjsNAzXHcTR7/nbILOAWbhBstNFK1mgejlbQ== -----END CERTIFICATE-----

Every certificate the server sends, leaf first. The output of openssl s_client -showcerts -connect example.com:443 works as it is: we ignore the text around the certificates.

Check the chainClearChoose a file

Paste the chain your server sends, from openssl s_client -showcerts. The checker shows where the chain ends and whether that root is publicly trusted.

Common mistakes

• “A root is trusted because it is self-signed.” A root is trusted only because it is already in the trust store. Anyone can make a self-signed certificate.
• “Self-signed means weak encryption.” The encryption can be just as strong. Self-signed means that nobody your device trusts has vouched for the name.
• “Every device trusts the same roots.” Browsers, operating systems, Java, Node.js, Python and containers each have their own stores, with different contents and update cycles.
• “I installed the root in Windows, so all my tools trust it.” Node.js, Python requests, Java and many containers ignore the Windows store unless you configure them.
• “-k is fine for internal services.” Internal networks have attackers too, and the setting tends to reach production. Trust the private root instead.
• “A private root only affects our internal sites.” A root in your store can vouch for any name, including your bank’s. Install only roots you control, and prefer CAs with name constraints (chapter 22).

Check yourself

Check yourself

Why does your laptop trust a public root CA certificate?

1. Because the root certificate is self-signed
2. Because it ships in your operating system's or browser's trust store
3. Because its key is longer than other keys

Show answer

Answer B Because it ships in your operating system's or browser's trust store

What happened

It is trusted because it is in the trust store.

Why

A self-signature proves nothing about trust: anyone can make one. Root programs decide which roots ship in the store.

The rule

A root is trusted only because it is already in the trust store.

Check yourself

Your company inspects TLS with a proxy. Chrome works, but npm install fails with UNABLE_TO_GET_ISSUER_CERT_LOCALLY. What is the best fix?

1. Turn off strict SSL checking in npm
2. Add the company's root certificate to Node's trust, for example with NODE_EXTRA_CA_CERTS
3. Reinstall Chrome

Show answer

Answer B Add the company's root certificate to Node's trust, for example with NODE_EXTRA_CA_CERTS

What happened

Give Node.js the company root, so it can verify the proxy's certificates.

Why

Chrome trusts the root through the operating system store. Node.js uses its own bundled list, which lacks the company root.

The rule

Fix trust errors by adding the right root to the client's store, never by turning verification off.

Check yourself

A developer adds verify=False to fix CERTIFICATE_VERIFY_FAILED when calling an internal API. What is the risk?

1. None, because the traffic is still encrypted
2. Anyone who can intercept the traffic can pose as the API and read or change the data
3. The API will refuse the connection

Show answer

Answer B Anyone who can intercept the traffic can pose as the API and read or change the data

What happened

The client now accepts any certificate, including an attacker's.

Why

Encryption without verification protects you only from passive listeners. A man-in-the-middle simply presents its own certificate.

The rule

Keep verification on and trust the right root instead.

Go deeper

• RFC 5280, section 6.1: path validation and the role of trust anchors.
• Mozilla Root Store Policy and Chrome Root Program: the rules public CAs must follow to be included.
• Chrome Root Store FAQ: where Chrome’s roots come from and how locally added roots are treated.
• Apple Root Certificate Program and Microsoft Trusted Root Program: the other two major root programs.
• Node.js: NODE_EXTRA_CA_CERTS and --use-system-ca: adding roots to Node.js.
• Python ssl and Requests: CA certificates: where Python finds its roots.
• Java keytool: the cacerts keystore and importing trusted certificates.
• curl: --cacert and --insecure: giving curl a CA bundle, and why skipping verification is unsafe.

In the gameLevel 12: Who do we trust?Registry of Roots, Keystone. In development

The crash course covers trust stores in lesson 6, Chains and trust stores.