What is Certificate Scanning

Certificate scanning is the technical process of connecting to network endpoints or inspecting local systems to extract certificate metadata. A scanner initiates a TLS handshake (or reads certificate files from disk), retrieves the full certificate chain, and records: subject, SANs, issuer, validity dates, key algorithm and size, signature algorithm, chain completeness, and protocol version. This data feeds into certificate inventory, expiry alerting, compliance checks, and vulnerability detection.

Why it matters

• Finds what you don’t know about — certificates deployed by other teams, shadow IT, forgotten test environments, and legacy systems all become visible through scanning.
• Expiry prevention — scanning extracts notAfter dates. Combined with alerting, this prevents the #1 cause of TLS outages: expired certificates nobody was tracking.
• Compliance validation — scans detect weak keys (RSA 1024), deprecated signature algorithms (SHA-1), and certificates violating policy (too-long validity, wrong CA). Auditors need this data.
• Chain completeness — a scan reveals whether the server sends the full chain (end-entity + intermediates) or just the leaf. Incomplete chains work in some clients but fail in others — scanning catches this before users report it.
• Crypto inventory for PQC readiness — scanning identifies every RSA and ECC certificate in your infrastructure, which is the starting point for post-quantum migration planning.

How it works

1. Target enumeration — define what to scan: IP ranges, DNS names, port lists (443, 8443, 636, 993, etc.), cloud endpoints, or Kubernetes services
2. TLS connection — the scanner initiates a TLS handshake to each target. It doesn’t need to complete the full handshake — just enough to receive the server’s certificate chain.
3. Certificate extraction — the scanner parses the X.509 certificates from the handshake: leaf certificate, intermediate(s), and any cross-certificates sent.
4. Metadata parsing — extract: Subject CN, SANs, Issuer, Serial Number, Not Before/Not After, Public Key Algorithm + Size, Signature Algorithm, Key Usage, Extended Key Usage, OCSP/CRL URLs.
5. Chain validation — verify the chain builds correctly to a known root. Flag incomplete chains, expired intermediates, or untrusted issuers.
6. Storage and deduplication — store results in a central inventory. Deduplicate certificates seen on multiple endpoints (same cert on 10 load balancer instances = 1 certificate, 10 deployments).
7. Alerting — trigger alerts based on rules: expiry within 30 days, key size < 2048, SHA-1 signature, self-signed in production, etc.

In real systems

OpenSSL manual scan (single endpoint):

# Extract certificate from a single endpoint
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Output:
# subject=CN = example.com
# issuer=C = US, O = Let's Encrypt, CN = R3
# notBefore=Mar  1 00:00:00 2026 GMT
# notAfter=May 30 23:59:59 2026 GMT
# X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com

Nmap TLS scan (network range):

# Scan a subnet for TLS certificates on common ports
nmap --script ssl-cert -p 443,8443,636,993,995 192.168.1.0/24
# Returns certificate details for every responding endpoint

Kubernetes certificate scan:

# Find all TLS secrets across namespaces
kubectl get secrets --all-namespaces -o json | \
  jq '.items[] | select(.type=="kubernetes.io/tls") | 
  {namespace: .metadata.namespace, name: .metadata.name}' 

# Decode and check expiry
kubectl get secret api-tls -o jsonpath='{.data.tls\.crt}' | \
  base64 -d | openssl x509 -noout -enddate

Cloud API scanning (AWS):

# List all ACM certificates with expiry
aws acm list-certificates --query 'CertificateSummaryList[*].[DomainName,NotAfter]' --output table

# Describe for full details
aws acm describe-certificate --certificate-arn arn:aws:acm:us-east-1:123:certificate/abc

Where it breaks

Scanning only port 443 — certificates live on many ports: 8443 (admin panels), 636 (LDAPS), 993 (IMAPS), 5671 (AMQPS), 6443 (Kubernetes API), custom application ports. A scan limited to 443 misses certificates on non-standard ports. These are often the ones that expire first because they’re the least visible. Scan all known service ports, not just HTTPS.

SNI-unaware scanning — multiple domains share a single IP (virtual hosting). Without sending the correct Server Name Indication (SNI) in the ClientHello, the scanner receives the default certificate — missing all other certificates hosted on that IP. Scanning must enumerate all known hostnames and send the correct SNI for each, or it only sees one certificate per IP.

Scanning finds the certificate but not the private key location — network scanning tells you what certificate is served, but not where the private key is stored or who has access to it. A certificate scan shows “valid, expires in 60 days” but can’t tell you whether the renewal automation has access to the key location, or whether the key is in an HSM vs. a world-readable file. Network scanning must be complemented by agent-based or configuration scanning for complete lifecycle visibility.

Operational insight

The gap between “certificate found” and “certificate managed” is where outages live. Scanning finds 2,000 certificates across your infrastructure. But finding them isn’t managing them — each certificate needs an owner, a renewal process, and a deployment path. Organizations that scan without assigning ownership end up with a dashboard showing 47 certificates expiring in 30 days and no clear answer to “whose job is it to renew each one?” Scanning is step one. Ownership mapping is step two. Without both, you have visibility without accountability.

Related topics

• What is Certificate Discovery
• Certificate Monitoring and Alerting
• Certificate Lifecycle Stages
• TLS Termination
• CBOM Scanning Infrastructure