Self-signed certificates: what they are and how to create one

A self-signed certificate is a certificate signed by its own key instead of by a certificate authority. The encryption it provides is the same as any other certificate's; what it lacks is anyone independent confirming that the holder is who it claims to be. That is why browsers refuse it on public sites, and why it is still the right tool for development and internal systems.

What makes a certificate self-signed

Certificates normally work through delegation of trust. An authority your browser already trusts signs a certificate, and by doing so states that it verified control of the name; see certificate authorities.

A self-signed certificate skips that step. Its issuer and subject are the same, and the signature is made with its own private key. It is technically valid and cryptographically sound, and means nothing to anyone who does not already know the site: an assertion without a witness.

That is also why browsers refuse rather than warn. An attacker impersonating a site can produce a self-signed certificate just as easily as the real site can, so accepting them would remove the point of certificate verification while leaving the padlock in place.

How to create a self-signed certificate

With OpenSSL, one command creates the private key and the certificate together:

$ openssl req -x509 -newkey rsa:2048 -noenc -keyout key.pem -out cert.pem \
    -days 365 -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost"

The subjectAltName extension is not optional in practice: browsers read names only from it, so a certificate with a common name and no subjectAltName is rejected for a name mismatch even when trusted. List every name the server will answer for. The -noenc option leaves the key unencrypted, which suits a development server and nothing else.

To check the new certificate with OpenSSL:

$ openssl x509 -in cert.pem -noout -subject -issuer -dates -ext subjectAltName

Subject and issuer are identical, which is what self-signed means.

When self-signed is the right choice

• Local development and testing. A laptop, a build server or a staging system reachable only by the people who set it up. Nobody is asked to trust an unfamiliar site.

• Internal services between known machines. Where both ends are configured by the same team and can pin or explicitly trust the certificate.

• Device management interfaces. Network equipment and appliances commonly ship with one. Where the device lets you install your own certificate, do; where it does not, restrict who can reach the interface.

The common feature is that the people connecting can verify what they are connecting to by other means. Where that is not true, a self-signed certificate is the wrong tool, however small the audience seems.

When it is not

Any site a stranger might visit: public websites, customer-facing applications, anything reachable from the internet by someone who cannot verify it independently. The historical reasons for self-signing a public site, cost and effort, are gone: certificates from trusted authorities are free and can be issued and renewed automatically through ACME. The two ways to obtain one are covered in how to get a free SSL certificate. Buying from a paid authority is the third route; all three are compared in how to make an SSL certificate browsers accept.

A self-signed certificate installed "for now" during a launch is one of the more durable temporary measures in infrastructure, and it teaches every visitor that security warnings on your site are normal.

What the browser shows

Chrome and Edge report NET::ERR_CERT_AUTHORITY_INVALID; Firefox reports SEC_ERROR_UNKNOWN_ISSUER or, more specifically, MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT. The Firefox code is useful when diagnosing: it says the certificate is self-signed, rather than issued by an authority the browser does not know, which usually means an incomplete chain and a different fix. That case is covered on ERR_CERT_AUTHORITY_INVALID.

Command-line tools fail the same way, with messages such as self signed certificate or self-signed certificate in certificate chain.

Trusting it on your own machine, or running your own authority

For one developer, adding the certificate to the operating system's trust store, and to Firefox, which keeps its own, removes the warning on that machine only.

For a team, a private certificate authority scales better. You create one root, install it on the devices you manage, and issue certificates from it; every service then works without warnings on those devices and on nothing else, which is exactly the intent. Tools such as mkcert automate this for local development.

Clicking through the warning is the option to avoid. On a network you control it is almost certainly the intended server; on a shared network it is precisely the situation where it might not be, and the warning page cannot tell the two apart. Every internal system that shows the warning trains its users to dismiss it, and the habit does not stay inside the office.

FAQ