Search
Table of Contents

What Is a Self-Signed Certificate?

3 min. read
Explore Identity Security
Table of Contents

A self-signed certificate is a digital certificate that is signed by the same entity that created it, rather than a trusted Certificate Authority (CA). It uses a private key to validate its own public key, providing encryption for data in transit without third-party identity verification.

Key Points

  • Internal Validation: Self-signed certificates lack third-party endorsement from a recognized Certificate Authority.

  • Cost Efficiency: These certificates are free to generate and require no external administrative approval.

  • Limited Trust: Web browsers do not trust these certificates by default, often triggering security warnings.

  • Visibility Gap: Organizations often lack central oversight for the location and ownership of self-signed assets.

  • Revocation Gaps: Self-signed certificates can technically publish revocation info, but in practice, no infrastructure exists to distribute or check it.

 

Self-Signed Certificates Explained

Digital certificates act as identity cards for servers, applications, and devices. While a standard certificate is "notarized" by a trusted third party like DigiCert or Let’s Encrypt, a self-signed certificate is an "issued-to-self" credential. 

For C-Suite executives, this represents a trade-off between speed and risk. They allow for rapid deployment in development but bypass the governance of a formal Public Key Infrastructure (PKI).

For SOC leaders, these certificates create an operational "blind spot." Because anyone with command-line access can generate one, they often proliferate across internal networks without being recorded in an asset inventory. This "certificate sprawl" complicates incident response and identity management. Without a root of trust, these certificates are technically identical to those used by attackers in spoofing campaigns.

 

Use Cases & Real-World Examples

Self-signed certificates are appropriate for isolated, low-risk environments where external trust is unnecessary. Common scenarios include:

  • Dev/Test Environments: Speeding up the development cycle by bypassing CA procurement.
  • Internal-Only Applications: Securing traffic between two internal servers behind a robust firewall.
  • IoT Prototyping: Encrypting machine-to-machine (M2M) communication during the proof-of-concept phase.

The Risk of Shadow Identity

Unit 42 research indicates that identity weaknesses play a role in nearly 90% of security investigations. In many cases, attackers exploit unmanaged machine identities—like forgotten self-signed certificates on legacy servers—to move laterally through a network. Since these certificates often have long or infinite validity periods, they provide a persistent, unmonitored "backdoor" for unauthorized encryption if the private key is stolen.

 

How It Works

Self-signed certificates utilize Public Key Infrastructure (PKI) principles but serve as their own root of trust.

  1. Generation: A user creates a pair of keys (public and private).
  2. Signing: Instead of sending a Certificate Signing Request (CSR) to a CA like DigiCert or Let's Encrypt, the user signs the certificate using their own private key.
  3. Distribution: To avoid trust errors, the certificate must be distributed to clients via MDM, configuration management, application-specific pinning, or, as a last resort, manual import into the OS trust store.

Core Components

  • Public Key: Distributed to clients to encrypt data and verify the signature.
  • Private Key: Must be kept strictly confidential; if compromised, all encrypted traffic can be intercepted.
  • Subject: Information about the entity (server name, organization, etc.).
  • Signature: The mathematical proof that the certificate has not been altered since it was signed.

 

Self-Signed Certificate Best Practices

To maintain security while using self-signed certificates, organizations should follow these technical implementation steps:

Practice Implementation Detail Business Impact
Inventory Management Use automated discovery tools to map every certificate. Eliminates "Shadow IT" and hidden identities.
Short Validity Periods Limit certificate lifespans to months rather than years. Reduces the window of opportunity for attackers.
Secure Key Storage Store private keys in Hardware Security Modules (HSMs). Prevents credential theft and lateral movement.
Transition to Private CA Use an internal managed CA for internal-facing services. Centralized issuance, policy enforcement, lifecycle management, and revocation

 

Risks & Challenges

  • The "Set It and Forget It" Mentality: Because self-signed certificates can be set to never expire, they often linger on legacy systems long after the original administrator has left the company.
  • Man-in-the-Middle (MitM) Vulnerability: If users are trained to "click through" certificate warnings on internal sites, attackers can easily use their own self-signed certificates to intercept credentials.
  • No Support or Warranty: Unlike public CAs, there is no external technical support or financial insurance if the encryption fails or the certificate causes system outages.
  • Increasing Browser Blocks: Modern browsers, particularly on mobile platforms, block self-signed HTTPS certificates more aggressively than in the past. What worked as a quick internal workaround a few years ago may now be unreachable from newer clients without explicit trust configuration.

 

Unit 42 Intelligence: Attack Patterns

Unit 42 research indicates that threat actors frequently use self-signed certificates during the Command and Control (C2) phase of an attack. By using self-signed SSL/TLS, attackers can encrypt their malicious traffic, making it difficult for traditional firewalls to inspect the data for exfiltration or secondary payloads.

 

Self-Signed Certificates FAQs

Browsers only trust certificates issued by authorities in their pre-installed "Trust Store." Since self-signed certificates are not verified by these authorities, the browser warns users that the identity of the site cannot be confirmed.
In practice, no. A self-signed certificate can technically publish a Certificate Revocation List (CRL), but clients typically have no mechanism to check revocation for self-signed certs, so revocation is operationally ineffective.
The encryption strength is the same. The difference is trust: self-signed certificates don’t have a third-party identity verification, so clients can’t verify the certificate’s legitimacy without an out-of-band trust establishment.
You should replace them with CA-signed certificates whenever an application becomes public-facing, handles sensitive customer data, or is subject to regulatory audits like PCI-DSS.
Unit 42 views unmanaged certificates as a significant risk factor for lateral movement. Attackers frequently use the lack of visibility into these certificates to hide their traffic within encrypted tunnels.
No. Customers will see a security warning, which will significantly damage trust and conversion rates. Always use a public CA for customer-facing sites.
A self-signed certificate is its own authority. A private CA is a centralized internal system that can issue, manage, and revoke multiple certificates for an entire organization.
Technically, they can be generated with no expiration date, but this is a major security risk. Best practice is to limit their lifespan to 397 days or less.
Previous What Is a TLS/SSL Port? Port 443 and HTTPS Explained
Next What Is TLS Certificate Renewal? Process, Risks & Automation

Get the latest news, invites to events, and threat alerts