Self-Signed Certificate
Severity: High
Last updated August 9, 2026.
What it means
The certificate presented by this domain was signed by itself, or by a private CA, rather than by a Certificate Authority that browsers and operating systems trust out of the box. Browsers cannot build a trust chain to a root they recognize, so they show a warning even though the connection may still be encrypted.
Why it matters
Self-signed certificates in production defeat the identity-verification purpose of TLS: encryption without trusted identity verification does not protect against an attacker presenting their own self-signed certificate for the same domain. Visitors are trained to distrust the browser warning this produces, which also damages credibility even for legitimate internal or staging use that leaked into a public-facing hostname.
What Nivaronix checks
Nivaronix checks whether the certificate's issuer matches its own subject (a signature of self-signing) and whether the chain resolves to a CA present in standard trust stores. This is a certificate-trust check, not a scan for server-side vulnerabilities.
Example evidence
Illustrative example, not a live scan result. Run the checker below to see your own domain's actual status.
Illustrative example only — not a live scan result.
Certificate: CN=internal-app.example.com
Issuer: CN=internal-app.example.com (self-issued)
Trust chain: does not resolve to a public root CA
Status: SELF-SIGNED — NOT TRUSTED BY BROWSERSHow to fix it
- Do not use self-signed certificates on any publicly reachable production hostname.
- Generate a certificate from a real Certificate Authority — Let's Encrypt (free, automatable via ACME) covers the vast majority of use cases.
- If the certificate is managed by a CDN or load balancer (Cloudflare, AWS ACM, etc.), enable their managed TLS certificate feature instead of uploading a self-signed one.
- Reserve self-signed certificates for genuinely internal, non-public services, and keep them off any hostname that resolves publicly.
How to verify the fix
Re-run the SSL/TLS checker against the domain and confirm the certificate now chains to a trusted public root. In a browser, the padlock should show with no interstitial warning.
FAQ
Is a self-signed certificate still encrypted?
Yes — the connection is encrypted the same way any TLS connection is. What's missing is trusted identity verification: nothing confirms the certificate actually belongs to who it claims to, because no browser-trusted CA vouched for it. Encryption without verified identity doesn't stop an attacker from presenting their own self-signed certificate for the same domain.
Is it ever okay to use a self-signed certificate?
Internal tools and local development environments that never face the public internet are the normal use case — the risk this finding describes is specifically a self-signed certificate on a public-facing hostname, where real visitors hit a trust warning. A staging or internal subdomain that leaked into public DNS is the most common way this finding shows up unexpectedly.
How do I replace a self-signed certificate?
Issue a certificate from a publicly trusted CA instead — Let's Encrypt is free and automatable via ACME clients like Certbot, and most hosting platforms and CDNs (Cloudflare included) provision one automatically once a domain is pointed at them. Install it in place of the self-signed one and confirm the issuer chain resolves to a public root.
Why does my browser trust it but a script or API client doesn't?
A browser may have a locally trusted root added by an IT department or a prior manual override, which makes the warning disappear only on that machine. A fresh API client, mobile app, or a colleague's browser has no such override, so it sees the same self-signed certificate and rejects the connection outright — the browser trusting it locally isn't evidence the certificate is actually valid.
Check your certificate now
Free, no signup required.