Self-Signed SSL/TLS Certificate

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Cryptographic / PKI Misconfiguration
Typical Severity Medium
OWASP A02:2021 – Cryptographic Failures; A05:2021 – Security Misconfiguration
CWE CWE-295 – Improper Certificate Validation
Also known as Untrusted Certificate, Unverified Certificate, Self-Issued Certificate
Affected systems Web servers, APIs, mail servers, internal services, IoT devices, admin consoles exposed over HTTPS
Relevant standards RFC 5280 (X.509 PKI), RFC 8555 (ACME/Let's Encrypt), CA/Browser Forum Baseline Requirements

Overview

An SSL/TLS certificate authenticates the identity of a server and enables encrypted communication. In a normal Public Key Infrastructure (PKI), a certificate is signed by a trusted Certificate Authority (CA) that browsers and operating systems include in their root store. A self-signed certificate is instead signed by the same private key whose public key it contains — no independent third party has vouched for the binding between the certificate's subject (domain name) and the key pair owner.

Because self-signed certificates are not traceable to any root in a standard trust store, browsers and HTTP clients display warnings or errors by default, and many automated clients (API consumers, mobile apps) will refuse the connection entirely unless explicitly configured to bypass validation. Sensagraph detects self-signed certificates during routine TLS inspection of scanned hosts.

How it works

TLS certificate validation follows a chain-of-trust model defined in RFC 5280. A client validates a certificate by:

  1. Verifying the certificate's digital signature traces back to a trusted root CA in the client's trust store.
  2. Confirming the certificate's Subject Alternative Name (SAN) or Common Name (CN) matches the requested hostname.
  3. Checking that the certificate is within its validity period and has not been revoked (OCSP / CRL).

A self-signed certificate fails step 1 by definition — its Issuer and Subject fields are identical, and the signature is made with the certificate's own private key. Clients that enforce strict validation therefore present an error (e.g., ERR_CERT_AUTHORITY_INVALID in Chromium). The technical implications include:

  • No identity assurance: Anyone can generate a self-signed certificate for any domain. There is no CA vetting the requester's ownership of the domain.
  • Man-in-the-Middle (MITM) attack surface: Users who click through browser warnings — or clients configured to skip validation — cannot distinguish a legitimate server from an attacker who has substituted their own self-signed certificate. The transport may be encrypted, but to an adversary's key.
  • HTTP Public Key Pinning / HSTS incompatibility: Self-signed certificates cannot participate in HSTS preload lists and are incompatible with standard certificate transparency (CT) logs.
  • Automated client failures: Libraries such as curl, Java's HttpsURLConnection, Python's requests, and mobile SDKs reject untrusted certificates by default, breaking integrations unless --insecure flags or trustAllCerts patterns are introduced — themselves security defects.
  • Revocation impossible: There is no CA to publish a CRL or OCSP response; if the private key is compromised, there is no standard mechanism to invalidate the certificate before it expires.

Business impact

The presence of self-signed certificates on production or internet-facing systems carries several concrete risks:

  • User trust erosion: Browser security warnings deter end users and damage brand credibility. Sophisticated users may abandon the session entirely.
  • Credential and data interception: If users or automated systems accept the certificate anyway, an active MITM attacker can decrypt and manipulate all traffic, including authentication credentials, session tokens, and sensitive payload data.
  • Compliance failures: PCI DSS (Requirement 4), HIPAA Security Rule, and NIST SP 800-52 Rev. 2 require proper certificate management and trusted CA issuance for systems handling regulated data. Self-signed certificates on in-scope systems can result in audit findings and sanctions.
  • Integration breakage: Third-party services, payment processors, or partners connecting over HTTPS will fail certificate validation, causing service outages or forcing insecure bypass configurations downstream.
  • Incident response gap: Without CA-backed revocation, a compromised certificate cannot be effectively invalidated before expiry, extending the window of exposure.

How to fix it

  1. Replace with a CA-signed certificate: Obtain a certificate from a publicly trusted CA. For most internet-facing services, Let's Encrypt provides free, automated Domain Validation (DV) certificates via the ACME protocol (RFC 8555). For higher-assurance needs, use an OV or EV certificate from a commercial CA.
  2. Automate renewal: Use ACME clients (Certbot, acme.sh, Caddy's built-in ACME, Traefik) to automate issuance and renewal. Set renewal to trigger at 60–30 days before expiry to avoid lapses.
  3. Internal / private networks: For systems not reachable from the public internet (internal APIs, admin panels, internal microservices), deploy a private internal CA (e.g., using HashiCorp Vault PKI Secrets Engine, Microsoft AD CS, or CFSSL) and distribute its root certificate to all internal clients via MDM or configuration management. This preserves chain-of-trust without requiring public CA issuance.
  4. Enable HSTS: Once a trusted certificate is in place, set the Strict-Transport-Security header with an appropriate max-age and consider HSTS preloading to prevent protocol downgrade attacks.
  5. Implement certificate monitoring: Use certificate transparency log monitoring and automated expiry alerting (e.g., via crt.sh notifications or internal tooling) to detect unexpected certificate changes and approaching expirations.
  6. Audit client code: Search for any code that disables certificate validation (verify=False, trustAllCerts, -k flags, InsecureSkipVerify: true) introduced as a workaround for self-signed certificates, and remove these bypasses once legitimate certificates are deployed.
  7. Remove from production: Never deploy self-signed certificates to production or any externally accessible endpoint. Restrict their use to isolated development or lab environments with no access to production data.

References

Frequently asked questions

A self-signed certificate does encrypt traffic in transit, which is marginally better than plain HTTP for passive eavesdropping. However, it provides no identity assurance — an attacker can substitute their own self-signed certificate during a MITM attack, and users or clients cannot distinguish the legitimate server from the impersonator. For any production or user-facing system, a CA-signed certificate is required.

Self-signed certificates are commonly acceptable in isolated development environments, local testing, or automated test pipelines where no real users or sensitive data are involved. They are not acceptable on production systems, internet-facing endpoints, or any environment handling regulated data. Internal systems should use a private internal CA rather than self-signed certificates.

A self-signed certificate is signed by its own key and has no issuer chain. A certificate from a private (internal) CA is signed by a CA that your organisation controls and distributes as a trusted root to its own clients. The private CA model preserves the chain-of-trust principle — clients that have installed the private root certificate can fully validate server certificates it has issued, including revocation checks, without browser warnings.

Yes. During TLS handshake inspection, a scanner can retrieve the certificate chain and verify whether the issuer is the same entity as the subject (indicating self-signing) and whether the issuing root is present in a standard trust store. Sensagraph performs this check as part of its continuous TLS inspection.

Yes — if a client connects without validating the certificate chain (e.g., a user who clicks through the browser warning), the traffic is still encrypted at the TLS layer, protecting against purely passive observers. However, it does not protect against active MITM attacks, because the attacker can present their own self-signed certificate and the client has no basis to reject it.