What is a self-signed certificate?
Every certificate is signed by an issuer. In a self-signed certificate the issuer and the subject are the same, and the signature comes from the certificate's own private key. No certificate authority has checked who created it or vouched for the name inside. The encryption it enables is just as strong as with a CA-issued certificate; what is missing is identity assurance. A client cannot tell a legitimate self-signed certificate from one an attacker generated with the same name, unless someone configured that client in advance to trust that exact certificate.
How to create one
A self-signed certificate takes a single OpenSSL command:
openssl req -x509 -newkey rsa:3072 -sha256 -days 365 -noenc -keyout nas.key -out nas.crt -subj "/CN=nas.lab.internal" -addext "subjectAltName=DNS:nas.lab.internal"
The -x509 option tells OpenSSL to output a finished certificate instead of a signing request. Inspecting the result with openssl x509 -in nas.crt -noout -subject -issuer shows identical subject and issuer lines, the giveaway of a self-signed certificate:
subject=CN=nas.lab.internal
issuer=CN=nas.lab.internal
On Windows, the PowerShell cmdlet New-SelfSignedCertificate does the same job and places the certificate in the local certificate store.
Where self-signed certificates fit
- Labs, development and test systems used only by the people who built them
- The first-boot web interface of a switch, firewall, printer or hypervisor, until a proper certificate replaces it
- Service-to-service connections where both ends are configured to trust, or pin, one specific certificate
- Root CA certificates, which are always self-signed and are trusted only because they were placed in the trust store deliberately
The risks
Browsers reject self-signed certificates by default: Chrome shows NET::ERR_CERT_AUTHORITY_INVALID and Firefox shows MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT. The larger damage is to user behavior. Staff who click past a warning on the intranet every morning will click past the same warning when an attacker is intercepting their connection with a forged certificate. Self-signed certificates also have no revocation path: if the private key leaks, there is no CA to revoke it, so every client that trusted it has to be changed by hand. For internal sites that many people use, the better answer is a certificate from an internal CA whose root is pushed to managed devices through Group Policy or MDM.
Self-signed vs. internal CA vs. third-party CA certificates
| Type | Signed by | Trusted by | Best fit |
|---|---|---|---|
| Self-signed | Its own key | Only clients configured for it | Labs, initial device setup |
| Internal CA | The organization's own CA | Managed devices that hold the internal root | Intranet, VPN, Wi-Fi, smart cards |
| Third-party (public) CA | A commercial or public CA | Nearly every browser and OS by default | Public websites, APIs, mail servers |
Self-signed certificate on the CompTIA Security+ exam
Self-signed certificates appear in SY0-801 objective 1.3 alongside third-party certificates, as part of choosing the right cryptographic solution. Wording such as "lab", "test environment" or "development server with no outside users" makes a self-signed certificate acceptable, and often the cheapest correct answer. "Customers see a security warning" or "employees keep getting certificate errors on an internal site" points away from self-signed and toward a public CA or an internal CA with its root deployed. Watch for distractors such as telling users to accept the warning, or swapping the self-signed certificate for a wildcard, which changes name coverage but not trust.