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.
Answer "Where is the certificate used?" — localhost, CI or test fixture, a device on your own LAN, an internal service, staging, or a public production site.
Answer "How are clients meant to trust it?" — a bare self-signed leaf, a pinned certificate, or a private CA in the trust stores — and tick everything under "Which of these are true?".
Read the Risk score out of 100, the yes/no list under "What this certificate actually gives you", and each Finding's fix; Copy assessment saves the write-up.
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.