Troubleshooting2026-08-15•4 min read

Self-Signed Certificates: Trust Errors in Browsers and Apps

· CSR.plus Team

•A self-signed certificate is its own root — nothing trusts it until you install it.
•Use self-signed certs only for local development and internal testing; use a private CA for real internal services.
•Adding a certificate to one trust store (browser) does not fix curl, Java, Python or mobile apps.

Self

Trust model

cert is its own root

Dev/test

OK for

localhost and staging

Private CA

Better option

for real internal services

Many

Stores to update

browser, OS, curl, Java, apps

Why trust errors are expected

A self-signed certificate declares itself as its own root. Every client (browsers, curl, Java, Python, mobile apps) verifies against its own trust store, finds no match, and fails with a trust error. This is correct behavior — the goal is to make the right client trust the right certificate, not to disable checks.

Installing the certificate correctly

Export the certificate PEM, then install it in every store that connects: the OS keychain (macOS/Linux/Windows) for browsers, the curl CA bundle (-cacert file or SSL_CERT_FILE), Java’s cacerts via keytool, Python’s SSL_CERT_FILE or the requests verify parameter, and the trust store of any mobile app. Restart the clients after installing.

The better alternative: a private CA

For real internal services, generate a private CA, install only the CA root in client stores, and issue short-lived leaf certificates signed by it. Clients then trust every internal service without per-host installs, and you avoid the security downgrade of disabling certificate verification (curl -k, verify=False).

FAQ

Is it OK to use curl -k or verify=False?

Only for throwaway local testing. Disabling verification opens you to man-in-the-middle attacks. For anything persistent, install the certificate or use a private CA.