Skip to main content
TLS certificate issues range from expired certificates that break trust and trigger browser warnings to misconfigured wildcard certificates that expose more of your infrastructure than intended. Certificate findings are unique in that they simultaneously affect security, availability, and compliance — an expired certificate on a customer-facing service can take it offline and damage customer trust within seconds of expiry, while an unauthorized certificate issued for your domain may be the first visible sign of a subdomain takeover or supply chain compromise. Leverage Cyber monitors certificate transparency logs and passive SSL data continuously to surface these findings before they become incidents.

​
Types of Certificate Findings

An expired certificate means the service is actively broken. Every major browser will display a full-page security warning, blocking users from accessing the service unless they manually override the warning — which most users will not do, and which most enterprise security policies prohibit. Beyond the user-facing impact, expired certificates break API integrations, mobile applications, and automated processes that enforce strict TLS validation. There is no grace period: the moment a certificate crosses its notAfter timestamp, it is expired. Any expired certificate finding requires same-day remediation.
A proactive alert triggered when a certificate’s expiry date falls within the next 30 days. This finding exists to give your team sufficient time to renew and deploy the replacement certificate before expiry, preventing an outage. Certificates require ordering, validation, deployment, and testing — in complex environments this process can take multiple days. Do not dismiss expiring-soon findings as low priority. The majority of certificate outages are preventable and occur because this warning was not acted upon in time.
A service negotiating TLS 1.0, TLS 1.1, or cipher suites using RC4, DES, 3DES, or export-grade encryption is vulnerable to downgrade attacks, BEAST, and POODLE-class exploits. These protocol versions are formally deprecated by the IETF and prohibited by PCI DSS 4.0 and other compliance frameworks. Leverage Cyber flags any service where passive data sources show it has advertised or negotiated these cipher suites. Remediation requires updating your TLS configuration to enforce TLS 1.2 minimum with approved cipher suites, and TLS 1.3 where supported.
A self-signed certificate is not issued by a trusted certificate authority and will trigger browser security warnings for any user who encounters it. Self-signed certificates are appropriate in isolated internal development environments but are a significant finding when discovered on internet-facing services. Their presence typically indicates a development or testing service that was exposed to the internet without proper security review, or a service that was stood up quickly without following your certificate management process. A self-signed certificate finding should prompt investigation into why the service is internet-accessible at all.
A wildcard certificate — for example, *.example.com — is valid for any single subdomain level under the specified domain. While convenient, wildcard certificates introduce a significant risk concentration: if the private key for a wildcard certificate is compromised on any one service, every service covered by that certificate is compromised. Leverage Cyber flags wildcard certificates that cover an unusually broad set of subdomains, particularly when those subdomains serve services with different sensitivity levels. The finding prompts a review of whether a wildcard certificate is appropriate for the scope it covers, or whether purpose-specific certificates for high-sensitivity subdomains would reduce exposure.
This finding is triggered when Leverage Cyber detects a new certificate issued for one of your domains that was not registered by or communicated to your IT team. Every TLS certificate issued by a public CA is logged in certificate transparency (CT) logs — a public, append-only record. Leverage Cyber monitors these logs in real time for certificate issuance activity on your domains. An unexpected certificate issuance may indicate a subdomain takeover (an attacker has claimed a dangling DNS record and obtained a valid certificate for it), a rogue certificate issued through a compromised CA account, or an unauthorized deployment by a third party or shadow IT project. Treat unexpected CT log findings as potential security incidents until the certificate’s origin is confirmed.

​
Certificate Finding Fields

Each certificate finding in the Leverage Cyber dashboard includes the following structured fields.
​
string
required
The fully qualified domain name (FQDN) for which the certificate was issued or on which the issue was observed. For wildcard certificates, this will include the wildcard notation, e.g., *.example.com.
​
string
required
The certificate authority (CA) that issued the certificate. For self-signed certificates, the issuer and subject will match. For CT log discovery findings, the issuer identifies which CA signed the unexpected certificate — useful for tracing unauthorized issuance.
​
string
required
The notBefore timestamp of the certificate — the earliest date from which the certificate is valid. Format: YYYY-MM-DD. Used to calculate certificate age and contextualize breach findings.
​
string
required
The notAfter timestamp of the certificate — the date on which the certificate expires. Format: YYYY-MM-DD. This is the primary field driving expiry and expiring-soon findings.
​
integer
required
The number of days remaining until certificate expiry at the time the finding was generated. Negative values indicate the certificate is already expired. Values between 0 and 30 trigger an expiring-soon finding.
​
string
required
The TLS protocol version advertised or negotiated by the service, as observed in passive data. Values include TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3. Versions 1.0 and 1.1 trigger a weak cipher suite finding.
​
string
The cipher suite negotiated during TLS handshake, as recorded in passive SSL data. Weak cipher suites including RC4, DES, 3DES, and NULL ciphers are flagged automatically. This field may be absent if cipher suite data is not available from passive sources.
​
enum
required
The composite severity rating for this finding. Possible values: critical, high, medium, low. See the severity table below for how each certificate finding type maps to a severity level and business impact.

​
Certificate Transparency Monitoring

Certificate Transparency (CT) is a public infrastructure requiring all publicly trusted TLS certificates to be logged in publicly auditable append-only logs before browsers will trust them. Every certificate issued for your domains — including subdomains — appears in these logs within minutes of issuance. Leverage Cyber monitors CT logs continuously for certificate issuance activity on all domains and subdomains associated with your organization. When a new certificate appears for your domain, Leverage Cyber cross-references it against your known certificate inventory and flags any issuance that cannot be attributed to your team’s documented activities. This monitoring catches three high-value attack patterns:
  • Subdomain takeover — An attacker claims a dangling DNS record (a subdomain pointing to a deprovisioned cloud resource) and obtains a valid certificate for it, enabling them to serve content under your domain with full browser trust
  • Account compromise at your CA — An attacker gains access to your certificate authority account and issues certificates for your domains, enabling man-in-the-middle attacks on your users
  • Shadow IT and unauthorized deployments — Internal teams or third-party vendors deploy services under your domain without notifying your security team, creating unmanaged attack surface
CT log findings are typically generated within hours of the unauthorized certificate being issued, giving you a narrow window to respond before the attacker can operationalize the certificate.

​
Interpreting Certificate Severity

Automate certificate renewal using Let’s Encrypt with an ACME protocol client such as Certbot, acme.sh, or your web server’s built-in ACME support. Automated renewal eliminates certificate expiry findings entirely for web-facing services — the client handles renewal, deployment, and reload before expiry, with no manual intervention required. For services where Let’s Encrypt is not appropriate (internal PKI, EV certificates, non-HTTP services), configure calendar alerts at 60 days and 30 days before expiry and document your renewal runbook so the process does not depend on institutional memory. Leverage Cyber expiring-soon findings serve as your backstop, but proactive automation is the more reliable control.