TLS & Certificate Posture
Infracast actively probes your public-facing endpoints to assess real TLS and certificate posture — surfacing expiring certificates, weak protocols, and misconfigured chains before they become outages or audit findings. No agent required.
Overview
Most posture tools infer TLS configuration from cloud API metadata. Infracast goes further: it performs live, outside-in TLS connections to the endpoints in your asset graph and inspects what a real client would actually negotiate. This catches drift that metadata alone misses — an expired certificate behind a load balancer, a listener still accepting TLS 1.0, or a hostname that doesn't match the served certificate.
Results are correlated back into the unified graph, so every certificate finding is tied to the exact node (load balancer, CloudFront distribution, API gateway, ingress, or any host with a public address) that serves it.
How Endpoints Are Discovered
The scanner extracts candidate endpoints from your graph automatically:
- By resource type — application/network load balancers, classic ELBs, CloudFront distributions, API Gateway stages, and Kubernetes Ingress resources
- By public host property — any node carrying a routable public address (public DNS name, public IP, endpoint, FQDN, and similar attributes)
- By your own DNS names — when a discovered DNS record (
A/AAAAalias orCNAME) from Route 53, Azure DNS, Google Cloud DNS or Cloudflare points at one of those endpoints, that name is probed too, using it as the TLS server name (SNI). This is usually the name your users actually visit and the one your certificate is issued for. Wildcard records cannot be probed and are skipped.
Private and loopback addresses are skipped — only externally reachable endpoints are probed.
Every name is shown, with where it came from
One resource is often reachable under several names — for example a load
balancer answers both on app.example.com and on its AWS-generated
…elb.amazonaws.com address. Each name is scanned and listed separately, and
labelled so you can tell them apart:
| Label | Meaning |
|---|---|
| Custom domain | Your own DNS name pointing at the resource, found via a record in Route 53, Azure DNS, Google Cloud DNS or Cloudflare. For a Cloudflare record with proxying on, the row says so: that name is answered by Cloudflare's edge, so the certificate seen there is Cloudflare's. |
| Provider address | A name generated by the cloud provider (*.elb.amazonaws.com, *.cloudfront.net, *.azurewebsites.net, …). Certificates are normally issued for your own domain, so a hostname mismatch on this row usually means "reached by its generated name", not "wrong certificate". |
| IP address / Hostname | Probed by IP, or by a hostname from discovery that is not provider-generated. |
Each row (and its findings) also says where the name was found, for example
Route 53 A record app.example.com (zone example.com) → aws.elbv2.load_balancer "web-alb"
or aws.elbv2.load_balancer "web-alb" (property dns_name). On-premises DNS (for example
Active Directory-integrated zones) is not read today, so names that exist only
there are not matched. Rows scanned before
this was recorded show "not recorded" until the next scan.
Ports Scanned
| Resource | Ports |
|---|---|
| AWS load balancers (after a discovery scan) | Exactly the ports of its HTTPS / TLS listeners |
| Other load balancers and ingresses, or AWS load balancers not yet rediscovered | 443 and 8443 |
| Everything else | 443 |
STARTTLS protocols (SMTP, IMAP, PostgreSQL, MySQL) are supported by the probe engine but are not part of the automatic scan today.
What Gets Checked
Each probe evaluates the negotiated session and presented certificate chain against a dedicated rule pack:
- Certificate expiry — already expired, or expiring inside the warning window
- Weak protocols — TLS 1.0 / TLS 1.1 still accepted
- Weak cipher suites — known-insecure or deprecated ciphers
- Chain trust — self-signed or untrusted issuing chains
- Hostname mismatch — served certificate doesn't cover the requested host (check the row's label: on a provider address this is usually expected)
- Key strength — RSA keys below recommended length
- Transport hardening — missing HSTS
Compliance Mapping
TLS posture findings map directly to controls across major frameworks:
| Framework | Controls |
|---|---|
| NIST 800-53 | SC-8, SC-12, SC-13 |
| FedRAMP | SC-8(1) |
| PCI-DSS v4 | 4.2.1 |
| CMMC Level 2 | SC.L2-3.13.8 |
| ISO 27001 | A.8.24 |
In the UI
- Certificates view (Compliance Center) — a sortable inventory of every discovered certificate with issuer, expiry, key details, and posture status
- TLS Posture tab — opens in the topology node drawer for any scanned endpoint, showing the negotiated protocol, cipher, chain, and findings
- Certificate-expiry widget — surfaces soon-to-expire certificates on the dashboard so renewals never slip
Continuous Monitoring
TLS scanning runs as a scheduled monitoring pass, not just on demand. New findings flow into the standard alert routing (Slack, Teams, PagerDuty, OpsGenie, email, webhook) and escalation chains, so a certificate quietly ticking toward expiry triggers a notification well before it lapses.