> ## Documentation Index
> Fetch the complete documentation index at: https://docs.leveragecyber.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Certificate Issues: TLS Misconfigurations and Expiry Risks
> How Leverage Cyber detects expired, misconfigured, and rogue TLS certificates, and what each finding type means for your security posture.
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.
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`.
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.
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.
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.
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.
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.
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.
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
| Finding Type | Severity | Business Impact |
| -------------------------------------------------- | -------- | -------------------------------------------------------------- |
| Expired certificate on production service | Critical | Service unavailable, browser warnings, broken integrations |
| Unauthorized certificate in CT logs | Critical | Potential subdomain takeover or rogue MITM infrastructure |
| Self-signed certificate on internet-facing service | High | No trusted CA validation, browser warnings, compliance failure |
| Wildcard certificate overexposure | High | Key compromise affects all covered subdomains simultaneously |
| TLS 1.0 or 1.1 in use | High | Vulnerable to downgrade attacks; PCI DSS non-compliant |
| Weak cipher suite (RC4, DES, 3DES) | High | Susceptible to known cryptographic attacks |
| Certificate expiring within 30 days | Medium | Imminent outage risk if not renewed and deployed |
| Certificate expiring within 60 days | Low | Planning-cycle action; renew and test before window closes |
| Self-signed on non-public internal service | Low | Internal trust issue; low external exploitability |
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.