Certificate Is Self-Signed

Issue type: Certificate Is Self-Signed
Key: tlscert_self_signed
Severity: Low
Factor: Network Security

The Certificate Is Self-Signed issue type flags assets with an SSL/TLS certificate not signed by a public Certificate Authority (CA). Instead, the certificate is signed by the organization's own internal CA or by a local machine.

Findings are raised on the Target:Port:SNI combination. For example, a self-signed certificate found on 201.107.1.42:443 with no SNI means the endpoint is not using the DNS of the IP. When testing, use the exact same parameters — for example, https://201.107.1.42:443 rather than https://goodssl.mydomain.com:443.

Why does SecurityScorecard flag this issue?

Web clients (like browsers) maintain a list of trusted CAs. When a certificate is not signed by one of those CAs, the browser cannot validate it and displays a security warning. Beyond browser warnings, self-signed certificates introduce several security risks:

• Man-in-the-middle (MitM) attacks: Because no trusted CA verifies the certificate, an attacker can impersonate the server and intercept or manipulate communication between the server and users.
• Phishing risk: Anyone can generate a self-signed certificate for any domain name. Attackers can create convincing fake websites and trick users into entering sensitive information such as passwords or credit card numbers.
• No certificate revocation: CA-signed certificates support revocation mechanisms such as CRLs and OCSP, which prevent the use of compromised or expired certificates. Self-signed certificates lack these mechanisms, increasing risk if a private key is compromised.
• Browser warnings: Most modern browsers display a warning when they encounter a self-signed certificate. These warnings can confuse users and cause them to dismiss or ignore legitimate security risks.
• No domain ownership validation: A CA-signed certificate requires the requester to prove control over the domain. Self-signed certificates skip this validation, so there is no external confirmation that the server is controlled by who it claims to be.

As a general rule, any public-facing endpoint must use a certificate signed by a trusted public CA.

How to test whether a certificate is self-signed

You can verify whether a certificate is self-signed using either of the following methods:

• Using a browser: Click the icon next to the URL in the address bar. If the certificate is signed by a trusted CA, you see "Connection is secure" and "Certificate is valid." If the certificate is self-signed, a warning icon appears next to the URL, and additional warnings are displayed on the page.
• Using TestTLS: Go to testtls.com and enter the endpoint. The tool shows whether the certificate is signed by a public CA or is self-signed.

How to mitigate

Replace the self-signed certificate with one issued by a trusted, publicly recognized CA. Some of the CAs that SecurityScorecard accepts include:

• DigiCert
• GlobalSign
• GTS (Google Trust Services)
• Amazon Root CA
• Comodo / Sectigo
• Let's Encrypt
• GoDaddy
• Entrust
• GeoTrust
• SwissSign
• Starfield
• Certum
• QuoVadis

Remediation options in SecurityScorecard

SecurityScorecard allows you to remove a finding if any of the following conditions apply:

• The endpoint configuration has changed and the self-signed certificate is no longer offered: Select the finding and click Report as Fixed.
• The endpoint has been closed and is no longer serving a self-signed certificate: Select the finding and click Report as Fixed.
• After verification, the endpoint does not actually offer a self-signed certificate contrary to what SecurityScorecard reports: Select the finding, click Other resolutions, and select I cannot reproduce this issue and I think it's incorrect.
• The endpoint with a self-signed certificate is not browser-accessible and is only used by specific clients (such as VoIP): Select the finding, click Other resolutions, and select I have a compensating control.