SSL Certificate Chain Contains RSA Keys Less Than 2048 bits

Tenable plugin 69551 fires when a TLS service presents at least one X.509 certificate in the served chain with an RSA key shorter than 2048 bits. In practice that usually means a legacy leaf or intermediate certificate; Tenable explicitly notes it does not flag root certificates under 2048 bits when they were issued before 2010-12-31, because those old trust anchors were grandfathered by the public-web rules.

Tenable's LOW rating is basically right. This is a real cryptographic weakness and a standards/compliance problem, but it is not a modern mass-exploitation primitive: the attacker still needs an active interception position, a way to redirect clients, or an expensive/specialized path to abuse the weak key. Browser and platform distrust of sub-2048-bit certs further reduces real-world exploitability, although it increases the chance of outages and audit findings.

Why this verdict

• Requires more than reachability: seeing a weak cert is easy; abusing it typically needs MITM, redirection, or another prior-compromise stage.
• Narrow exposed population: public-facing sub-2048-bit RSA certs are now uncommon, and many findings are on internal appliances, old middleware, or management planes.
• Blast radius is service-scoped: even a successful abuse path usually enables impersonation of one TLS endpoint or trust path, not remote code execution across the estate.

Why not higher?

This is not a one-packet internet-to-root problem. There is no commodity attacker workflow where simply finding this issue on a host predictably yields server compromise, and modern browsers/platforms already distrust much of this weak-cert population.

Why not lower?

It is still a real cryptographic weakness, not a false positive by default. If the weak key is on a business-critical auth portal, B2B endpoint, or sensitive internal service, the confidentiality and trust implications are real enough that it should stay above IGNORE.

1. Limit exposure — Restrict the affected TLS service to trusted networks, VPN users, or administrative jump paths where possible. For a LOW verdict there is no SLA (treat as backlog hygiene), so apply this during normal change windows if the service is more exposed than it should be.
2. Pin or tightly manage trust where feasible — Use certificate pinning, private trust stores, or strict enterprise trust policy for sensitive internal apps so a forged or swapped certificate is less likely to be accepted. For LOW, fold this into normal engineering backlog rather than emergency change activity.
3. Monitor certificate fingerprints — Baseline the presented leaf and intermediate fingerprints and alert on changes from unexpected IPs or load balancers. This gives you a fighting chance to spot impersonation without waiting for user trust-warning tickets.
4. Queue PKI replacement — Generate a replacement cert using RSA 2048+ or ECDSA, validate the full served chain, and retire the old keypair. For LOW, there is no hard mitigation deadline; handle it as planned certificate-maintenance work.

Run this from an auditor workstation or scan node that can reach the target TLS service. Invoke it as ./check_weak_rsa_cert.sh example.com 443; it needs only network access to the target and local openssl, no admin privileges.

#!/usr/bin/env bash
# check_weak_rsa_cert.sh
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

HOST="${1:-}"
PORT="${2:-443}"
TMPDIR="$(mktemp -d 2>/dev/null || mktemp -d -t weakrsa)"
cleanup() { rm -rf "$TMPDIR"; }
trap cleanup EXIT

if [ -z "$HOST" ]; then
  echo "UNKNOWN - usage: $0 <host> [port]"
  exit 2
fi

if ! command -v openssl >/dev/null 2>&1; then
  echo "UNKNOWN - openssl not found"
  exit 2
fi

CHAIN_FILE="$TMPDIR/chain.pem"
if ! timeout 15 openssl s_client -connect "${HOST}:${PORT}" -servername "$HOST" -showcerts </dev/null >"$CHAIN_FILE" 2>/dev/null; then
  echo "UNKNOWN - TLS connection failed to ${HOST}:${PORT}"
  exit 2
fi

awk 'BEGIN{c=0} /-----BEGIN CERTIFICATE-----/{c++} c>0{print > sprintf("'"$TMPDIR"'/cert_%02d.pem", c)} /-----END CERTIFICATE-----/{next}' "$CHAIN_FILE"

shopt -s nullglob
CERTS=("$TMPDIR"/cert_*.pem)
if [ ${#CERTS[@]} -eq 0 ]; then
  echo "UNKNOWN - no certificates parsed from handshake"
  exit 2
fi

found_vuln=0
found_cert=0

for cert in "${CERTS[@]}"; do
  if ! subj="$(openssl x509 -in "$cert" -noout -subject 2>/dev/null)"; then
    continue
  fi
  found_cert=1

  pubinfo="$(openssl x509 -in "$cert" -pubkey -noout 2>/dev/null | openssl pkey -pubin -text -noout 2>/dev/null)"
  if echo "$pubinfo" | grep -qi 'RSA Public-Key\|Public-Key: ([0-9]\+ bit)'; then
    bits="$(echo "$pubinfo" | sed -n 's/.*Public-Key: (\([0-9][0-9]*\) bit).*/\1/p' | head -n1)"
    if [ -n "$bits" ]; then
      echo "INFO - $subj - RSA ${bits} bits"
      if [ "$bits" -lt 2048 ]; then
        found_vuln=1
      fi
    else
      echo "INFO - $subj - RSA key present but size parse failed"
    fi
  else
    algo_line="$(echo "$pubinfo" | head -n1 | tr -d '\r')"
    echo "INFO - $subj - non-RSA or unparsed key (${algo_line:-unknown})"
  fi

done

if [ "$found_cert" -eq 0 ]; then
  echo "UNKNOWN - certificates were present but could not be decoded"
  exit 2
fi

if [ "$found_vuln" -eq 1 ]; then
  echo "VULNERABLE"
  exit 1
else
  echo "PATCHED"
  exit 0
fi

Sources

1. Tenable plugin 69551
2. Tenable PCI analogue plugin 73459
3. NIST SP 800-131A Rev. 2
4. CA/Browser Forum Baseline Requirements
5. Chromium intent to remove support for RSA keys smaller than 2048 bits
6. Mozilla Security Blog: Phasing out Certificates with 1024-bit RSA Keys
7. F5 Labs 2021 TLS Telemetry Report