This is a locked door with no trusted nameplate on it
Tenable plugin 57582 fires when a TLS service presents a certificate chain that ends in a self-signed certificate the client does not recognize. In practice, the affected 'version range' is not a software build number at all: it is any HTTPS/TLS service whose presented chain terminates in a self-signed root or leaf cert that is not distributed through a trusted public CA or your enterprise trust store.
Vendor MEDIUM overstates the operational urgency for most enterprises. The finding matters because it weakens identity assurance and can enable man-in-the-middle spoofing on public or user-facing services, but it is not a direct initial-access bug, not code execution, not auth bypass, and not generally exploitable without an attacker first gaining an on-path position or convincing users/admins to click through warnings.
4 steps from start to impact.
Find a target service with an untrusted TLS identity
- The service must expose TLS to the attacker or to a reachable user population
- The certificate chain must terminate in a self-signed cert that clients do not already trust
- Many hits are internal-only management interfaces, sharply limiting reachable population
- If the org deploys an internal PKI root to managed endpoints, the cert may be intentionally trusted and the practical risk collapses
Gain an on-path position for interception
bettercap, mitmproxy, or sslsplit. That implies local network presence, rogue Wi-Fi, upstream proxy control, malware on the endpoint, or compromise of intervening infrastructure. Without that position, the self-signed cert is mostly noise and admin pain.- Attacker has network-adjacent or upstream interception capability
- Traffic is not pinned to a known certificate or private CA
- Modern enterprise networks, EDR, NAC, WPA2/3-Enterprise, and segmentation make transparent interception materially harder
- Many managed browsers and clients refuse or loudly block untrusted cert chains
Present a spoofed certificate and rely on user or client acceptance
- The target client must not enforce strict validation or pinning
- A user, script, or service account must accept or ignore the warning
- HSTS, strict client validation, and managed browser policy can block bypass entirely
- Many critical apps fail closed on unknown issuers instead of allowing click-through
Harvest or tamper with data in transit
- The intercepted application flow carries sensitive data or privileged sessions
- The attacker maintains MITM control long enough to capture or alter traffic
- Short-lived sessions, MFA, and app-layer signing reduce the payoff
- Impact is limited to the specific service and users traversing the interception path
The supporting signals.
| In-the-wild status | No evidence that tenable:57582 is a stand-alone exploited vuln class. This is a configuration weakness that becomes useful only inside a broader MITM campaign. |
|---|---|
| KEV status | N/A — this is not a CVE-backed software flaw and is not listed in CISA KEV. |
| PoC availability | There is no exploit chain to 'drop'. Abuse is straightforward with interception tooling such as bettercap, mitmproxy, or sslsplit, but only after the attacker gets on path. |
| EPSS | N/A — EPSS is CVE-centric and does not meaningfully apply to a generic self-signed-certificate finding. |
| Vendor score and vector | Tenable scores it CVSS 6.5 with CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. That vector assumes network reachability and low attack complexity, but it does not capture the real prerequisite: attacker-controlled interception or unsafe exception handling. |
| Affected scope | Any TLS-enabled service whose presented chain ends in an unrecognized self-signed certificate. This is environment-driven, not tied to a single product version. |
| Fixed state | There is usually no vendor patch. 'Fixed' means replacing the presented cert with one chaining to a trusted public CA or your enterprise/private PKI root distributed to clients. |
| Exposure and scanability | This condition is easy to enumerate on internet-facing assets. Censys documents queries against parsed.signature.self_signed: true, and Shodan notes SSL metadata can be faceted to inspect certificate-chain behavior; that makes it good hygiene data, not proof of imminent compromise. |
| Disclosure / plugin history | Tenable published plugin 57582 on 2012-01-17 and last updated it on 2022-06-14. |
| Key technical nuance | Per NIST, a self-signed cert protects integrity of the cert contents but does not guarantee authenticity. That is the entire issue here: encryption may still exist, but identity trust is weak unless the cert is securely pre-distributed and trusted. |
noisgate verdict.
The decisive factor is attacker position requirement: this finding normally needs an on-path adversary or unsafe client exception handling before it can hurt you. That makes it a trust-hygiene issue with situational impact, not a broad initial-access vulnerability deserving front-of-queue patch treatment.
Why this verdict
- Start at Tenable's 6.5 baseline because an untrusted certificate on a public production service can enable spoofing and traffic tampering if an attacker can intercept sessions.
- Minus 2.0 for attacker position friction: exploitation usually requires unauthenticated remote MITM capability, rogue network presence, transparent proxy control, or prior endpoint/network compromise. That is a major hidden prerequisite the CVSS label glosses over.
- Minus 1.0 for exposure narrowing: in real enterprises, many plugin 57582 hits are scanners, appliances, load balancers, printers, storage arrays, and internal admin UIs—not broad employee- or customer-facing apps.
- Minus 0.9 for impact ceiling: the finding does not itself deliver RCE, auth bypass, privilege escalation, or durable host compromise. At worst it enables a narrower interception-and-impersonation path against the affected traffic.
Why not higher?
This is not a wormable edge-service bug and not a remote code execution path. Without on-path control, certificate-warning bypass, or a client that skips validation, there is no practical exploit chain to complete.
Why not lower?
It is still a legitimate security weakness on public-facing portals, VPN gateways, and admin surfaces because it removes trusted identity and trains users to ignore warnings. If the service is internet-facing or touched by humans, especially admins, the risk is real enough that IGNORE would be sloppy.
What to do — in priority order.
- Prioritize external and user-facing services — Replace self-signed certs on public websites, VPN portals, SSO pages, reverse proxies, and admin consoles first. For a
LOWverdict there is no SLA — treat as backlog hygiene, but do the obvious blast-radius reduction by fixing anything internet-facing or commonly accessed by admins this quarter. - Use enterprise PKI for internal services — Where public CA issuance is inappropriate, issue from your internal CA and push the root/intermediates through managed endpoint trust stores. For
LOW, there is no formal mitigation clock; the goal is to eliminate avoidable certificate exceptions before they become normalized user behavior. - Block unsafe certificate bypass patterns — Harden browsers, automation, and SDKs so they do not allow
--insecure, trust-on-first-use shortcuts, or manual click-through on sensitive apps. This reduces the only realistic exploitation path while you work through backlog remediation. - Watch for interception indicators — Monitor for rogue DHCP/DNS, transparent proxying, endpoint TLS-inspection anomalies, and repeated browser certificate errors on the affected services. Even though there is no
LOWmitigation SLA, this gives you a safety net against the attack pattern that actually matters.
- A WAF does not solve this; the weakness is certificate trust and identity, not HTTP request filtering.
- Simply telling users to click through browser warnings is actively harmful; it preserves the finding and conditions users to accept spoofed endpoints.
- Encryption alone is not enough. A self-signed cert can still encrypt traffic while failing the authenticity problem that makes MITM feasible.
Crowdsourced verification payload.
Run this from a Linux/macOS auditor workstation that can reach the target TLS service; it does not need to run on the target host. Invoke it as ./check_self_signed.sh host.example.com 443 [servername]; no root is required, but openssl must be installed and the workstation must have a normal system CA bundle.
#!/usr/bin/env bash
# check_self_signed.sh
# Determine whether a remote TLS service presents an unrecognized self-signed chain.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error
set -u
HOST="${1:-}"
PORT="${2:-}"
SNI="${3:-${1:-}}"
if [[ -z "$HOST" || -z "$PORT" ]]; then
echo "Usage: $0 <host> <port> [servername]"
exit 3
fi
if ! command -v openssl >/dev/null 2>&1; then
echo "UNKNOWN - openssl not found"
exit 2
fi
# Find a likely CA bundle/path for verification.
CAFILE=""
CAPATH=""
for f in \
/etc/ssl/certs/ca-certificates.crt \
/etc/pki/tls/certs/ca-bundle.crt \
/etc/ssl/ca-bundle.pem \
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
/private/etc/ssl/cert.pem
do
if [[ -r "$f" ]]; then
CAFILE="$f"
break
fi
done
if [[ -d /etc/ssl/certs ]]; then
CAPATH="/etc/ssl/certs"
fi
TMPDIR="$(mktemp -d 2>/dev/null || mktemp -d -t selfsignedcheck)"
trap 'rm -rf "$TMPDIR"' EXIT
RAW="$TMPDIR/s_client.txt"
CHAIN="$TMPDIR/chain.pem"
LEAF="$TMPDIR/leaf.pem"
ROOTCAND="$TMPDIR/root_candidate.pem"
# Capture the presented chain. Timeout via openssl is not reliable everywhere; rely on shell redirection only.
if ! echo | openssl s_client -connect "${HOST}:${PORT}" -servername "$SNI" -showcerts 2>&1 > "$RAW"; then
:
fi
# Some openssl builds send most output to stderr, so re-run and capture combined output.
( echo | openssl s_client -connect "${HOST}:${PORT}" -servername "$SNI" -showcerts ) > "$RAW" 2>&1
awk '
/-----BEGIN CERTIFICATE-----/ {in_cert=1}
in_cert {print}
/-----END CERTIFICATE-----/ {in_cert=0; print "__CERT_END__"}
' "$RAW" | sed '/^__CERT_END__$/d' > "$CHAIN"
if ! grep -q 'BEGIN CERTIFICATE' "$CHAIN"; then
echo "UNKNOWN - could not retrieve certificate chain from ${HOST}:${PORT}"
exit 2
fi
awk '
/-----BEGIN CERTIFICATE-----/ {cert++}
cert==1 {print}
/-----END CERTIFICATE-----/ && cert==1 {exit}
' "$CHAIN" > "$LEAF"
awk '
/-----BEGIN CERTIFICATE-----/ {buf=$0 ORS; in_cert=1; next}
in_cert {buf=buf $0 ORS}
/-----END CERTIFICATE-----/ {last=buf; in_cert=0}
END {printf "%s", last}
' "$CHAIN" > "$ROOTCAND"
leaf_subject="$(openssl x509 -in "$LEAF" -noout -subject 2>/dev/null | sed 's/^subject=//')"
leaf_issuer="$(openssl x509 -in "$LEAF" -noout -issuer 2>/dev/null | sed 's/^issuer=//')"
root_subject="$(openssl x509 -in "$ROOTCAND" -noout -subject 2>/dev/null | sed 's/^subject=//')"
root_issuer="$(openssl x509 -in "$ROOTCAND" -noout -issuer 2>/dev/null | sed 's/^issuer=//')"
# If the leaf is self-issued, this is almost certainly vulnerable unless locally trusted.
leaf_self_signed=0
if [[ -n "$leaf_subject" && "$leaf_subject" == "$leaf_issuer" ]]; then
leaf_self_signed=1
fi
root_self_signed=0
if [[ -n "$root_subject" && "$root_subject" == "$root_issuer" ]]; then
root_self_signed=1
fi
# Verify against local trust if we can.
verify_output=""
verify_rc=2
if [[ -n "$CAFILE" ]]; then
if [[ -n "$CAPATH" ]]; then
verify_output="$(openssl verify -CAfile "$CAFILE" -CApath "$CAPATH" "$LEAF" 2>&1)"
verify_rc=$?
else
verify_output="$(openssl verify -CAfile "$CAFILE" "$LEAF" 2>&1)"
verify_rc=$?
fi
elif [[ -n "$CAPATH" ]]; then
verify_output="$(openssl verify -CApath "$CAPATH" "$LEAF" 2>&1)"
verify_rc=$?
fi
if [[ $verify_rc -eq 0 ]]; then
echo "PATCHED - certificate validates to a locally trusted CA"
exit 0
fi
# Parse common openssl failure text for self-signed conditions.
if echo "$verify_output" | grep -Eqi 'self[- ]signed certificate|self[- ]signed certificate in certificate chain'; then
echo "VULNERABLE - untrusted self-signed certificate detected"
exit 1
fi
if [[ $leaf_self_signed -eq 1 ]]; then
echo "VULNERABLE - leaf certificate is self-signed and not locally trusted"
exit 1
fi
if [[ $root_self_signed -eq 1 && $verify_rc -ne 0 ]]; then
echo "VULNERABLE - chain terminates in a self-signed root that is not locally trusted"
exit 1
fi
# Tenable notes plugin 57582 does not cover every unknown-CA case.
echo "UNKNOWN - certificate is untrusted, but not clearly self-signed from the presented chain"
exit 2
If you remember one thing.
LOW reassessment there is no noisgate mitigation SLA and no noisgate remediation SLA — treat as backlog hygiene, but you should still swap self-signed certs off internet-facing portals and heavily used admin interfaces first, then migrate internal services to enterprise PKI as part of normal certificate hygiene this quarter while documenting accepted internal-only exceptions.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.