Self-Signed Certificate Checker

Check if a certificate is self-signed or CA-issued

About Self-Signed Certificates

A self-signed certificate is a certificate where the issuer and subject are identical — the certificate signs itself rather than being signed by a trusted Certificate Authority (CA). Self-signed certificates are commonly used for internal testing, development environments, and private networks where a CA-issued certificate is not required. However, browsers and public clients do not trust self-signed certificates by default. Our Self-Signed Certificate Checker helps you quickly determine if a server is using a self-signed or CA-issued certificate.

How to Use

Enter the domain name of the server you want to check.
Optionally change the port number (default is 443).
Click Check to fetch and analyze the server's certificate.
Review the result to see whether the certificate is self-signed or CA-issued, along with issuer and subject details.

Use Cases

Development Environment Validation: Confirm that internal services are using self-signed certificates as expected.
Security Auditing: Identify production servers that may be incorrectly using self-signed certificates.
Network Discovery: Scan your internal network to classify servers by certificate type.
Testing & QA: Verify that test environments are isolated from production CA trust chains.

Frequently Asked Questions

A self-signed certificate is a TLS certificate where the issuer and subject are the same entity. Unlike CA-issued certificates, it is not signed by a trusted third party. Browsers will display a security warning when encountering a self-signed certificate.

Self-signed certificates are appropriate for internal development, testing environments, lab networks, and private services where the clients trust the certificate directly. For public-facing production services, always use a CA-issued certificate.

Self-signed certificates provide the same level of encryption as CA-issued certificates. However, they lack the trust chain that allows browsers to automatically verify authenticity. The security depends on how the certificate is distributed and trusted by clients.

The cryptography is exactly as strong as a purchased one; the difference is trust. A self-signed certificate proves nothing because the signer is the subject, so any attacker can produce one that says anything. It has value only when the signer is already trusted: inside a closed environment where you install the certificate on every machine that connects, the trust relationship is established out of band and the cryptography is sound. On the public internet, without a client-side trust step, it offers encryption and no authentication at all.

Because the warning is about authentication, not secrecy. Your traffic is genuinely encrypted and nobody can read it, but the browser cannot confirm it is talking to you rather than to an impostor presenting its own certificate. That is the entire point of the certificate authority system, and a self-signed certificate opts out of it. The usual reasons people accept the warning anyway are a certificate generated once for a lab machine and never used for anything real, which is the one situation where ignoring it is defensible.

Self-signed means a certificate was signed with the private key belonging to its own subject, which is the normal case for a root. Self-issued means the subject name equals the issuer name but the certificate was signed by a different key — it is technically not self-signed despite looking identical. It arises during certificate rollover, where a certificate authority issues a new certificate for itself so it can retire an expiring one. The distinction matters if you run a private authority: a self-issued certificate still needs the previous one to remain trusted.

Only in one realistic situation: if the server is presenting a root certificate directly rather than a leaf. That happens with misconfigured appliances and appliances that terminate TLS with whatever they have on disk. Seeing a result here for a name you expect to be publicly issued is therefore worth investigating rather than dismissing — check the serial number and issuer name shown against what the authority should have issued, because a root served on port 443 will be rejected by every browser regardless.

Create it once, then install it as a trusted root on every client that will connect — a domain-joined Windows machine through Group Policy, macOS through a configuration profile, Linux through the system trust store, and mobile devices through an installed profile. That is the missing step that turns it from meaningless into usable, and skipping it is why internal tools so often end up with certificate warnings disabled globally. A private certificate authority does the same thing for many internal hostnames, and is the better answer past about three services.

How the Check Works

The test is a comparison, not a verification. Understanding which it is explains both what the result means and what it does not.

1Complete a handshake and read the certificate the server presents, with verification off so a self-signed certificate is readable at all — a verifying client would refuse to return it.
2Read the subject and issuer names from the parsed certificate.
3Compare them. Identical means self-signed. Different means the certificate was issued by a separate authority.

No signature is checked. A certificate whose issuer name merely happens to equal its subject name would be reported as self-signed even though something else signed it. In practice that combination is close to impossible for a publicly issued certificate, but it is the reason to treat this as a fast classification rather than a proof.

Tips & Best Practices

•Never use self-signed certificates in production environments
•Use self-signed certificates only for development and testing
•Replace self-signed with Let's Encrypt certificates for free trusted certificates
•Check all public-facing servers periodically for accidental self-signed deployment

Technical Details

Analysis: Issuer/subject comparison, signature verification, trust chain validation
Types: Self-signed, public CA-issued, private CA-issued, intermediate CA-issued
Trust: Cross-references against browser trust stores
Output: Certificate type determination with use case recommendations