Loading page
About this tool
Scores a self-signed or private-CA TLS setup by context and trust model, and says exactly what it protects against and what it does not.
Self Signed Certificate Risk Explainer scores a TLS setup on where it runs and how clients are meant to trust it, then lists what the certificate actually guarantees. TLS provides confidentiality and authentication; a self-signed certificate provides the first and none of the second, so an on-path attacker can substitute its own certificate undetected. The output separates the cases where that genuinely does not matter — a CI fixture, a localhost server — from the cases where it teaches a habit that costs you later.
Open Self Signed Certificate Risk Explainer on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
The same certificate scores 5 on localhost and 100 on a public production host, because the exposure is what differs.
A yes/no table for eavesdropping, machine-in-the-middle, browser trust, third-party clients and Certificate Transparency.
Every finding names the specific remedy — SANs, a Network Security Config, DNS-01 issuance, or automated renewal.
It encrypts the connection but proves nothing about who is on the other end, so it stops passive eavesdropping and does not stop an active machine-in-the-middle. That is acceptable when the client already knows exactly which certificate to expect — a pinned certificate or your own CA — and unacceptable when a human is asked to judge the warning instead.
Usually not. The W3C Secure Contexts specification treats http://localhost, http://127.0.0.1 and http://[::1] as potentially trustworthy origins, so service workers, getUserMedia, the Clipboard API and WebCrypto's SubtleCrypto all work over plain HTTP there. Add local TLS only to reproduce HTTPS-specific behaviour such as Secure cookies or mixed-content rules, and use a local CA like mkcert rather than a bare self-signed certificate.
Because the host has sent a Strict-Transport-Security header. Browsers remove the bypass link for HSTS hosts, so an untrusted certificate makes the site unreachable rather than merely warned about. Either serve a certificate that chains to a trusted root, or stop sending HSTS on that host while it is untrusted.
Publicly trusted certificates are capped at 398 days under the CA/Browser Forum Baseline Requirements, in force since 1 September 2020. Ballot SC-081, adopted in 2025, reduces the maximum to 200 days in March 2026, 100 days in March 2027 and 47 days in March 2029, which makes automated renewal a requirement rather than a convenience. Private CAs set their own limits, but Apple platforms reject server certificates with unusually long lifetimes regardless of who issued them.