TLS Landscape Report for optum.com

TLS Landscape Report for optum.com

Scope

This report analyzes the public-facing TLS posture observed for the optum.com domain set (including discovered subdomains associated with the base domain). Findings are derived from aggregated Internet-accessible telemetry and focus on certificate issuance patterns, protocol support, and cipher exposure.

Scale

Observed footprint

  • Hostnames: 15,289
  • Certificates: 14,209
  • SAN names (total / distinct): 48,113 / 19,255
  • SAN duplication: 28,858 duplicate instances (a signal of repeated re-issuance and/or broad multi-SAN reuse)

Issuer & validity (top issuers by certificate count)
The ecosystem is dominated by a mix of commercial CAs and short-lived issuance (notably 90-day certs), consistent with automation and cloud edge deployments.

IssuerTypical validity (days)Certificates
Sectigo Limited3664,808
Google Trust Services903,571
COMODO CA Limited3663,139
DigiCert, Inc.1851,101
DigiCert Inc182743
Let’s Encrypt90245
Amazon395148
SSL Corporation9036
Optum36511

Certificate Churn

Indicators point to high churn on specific names, suggesting frequent rotations, ephemeral environments, automated issuance, or repeated redeployments behind the same DNS.

Top SANs by distinct certificates observed (sample):

SAN nameDistinct certificates
asset-tracking-meili-dev.optum.com422
assettracking-api-dev.optum.com285
appcheckout-ext-md.optum.com248
optum.com189
appcheckout-ext-ss.optum.com88
test.optum.com72
asset-tracking-meili-prod.optum.com69
bi-reporting-dev.optum.com64
asset-tracking-meili-test.optum.com61
bi-reporting-dev-g.optum.com58

Subdomain Structure

The hostname set is heavily concentrated at 3 labels (e.g., x.optum.com), with a substantial tail of deeper names (5+ labels), which is often where legacy stacks and inconsistent TLS policies persist.

Hostname depth distribution (labels in FQDN)

  • 3 labels: 8,185
  • 4 labels: 1,874
  • 5 labels: 4,789
  • 6+ labels: 440 (combined)
  • 2 labels (apex): 1

Most common subdomains

Counts below represent distinct hostnames under each level-3 bucket, and include all hostnames matching *.bucket and deeper (e.g., everything under *.pmnts.optum.com).

Level-3 bucketDistinct hostnames
pmnts.optum.com3,477
caip-nonprod.optum.com408
gpd-acq-azure.optum.com394
caip-stg.optum.com239
caip.optum.com230
az-nsis.optum.com139
scm.optum.com128
oi-apip-nonprod.optum.com109
reco.optum.com80
drn.optum.com79

TLS Versions

Protocol support remains anchored in modern versions (TLS 1.2/1.3), but the continued presence of TLS 1.0/1.1—and a trace of SSLv3—indicates pockets of legacy configuration still reachable.

TLS VersionHostnamesIPs
TLS1.32,6202,434
TLS1.23,8782,857
TLS1.126102
TLS1.023100
SSLv312

Note: These counts are not mutually exclusive; a single hostname/IP may support multiple protocol versions.

Legacy TLS

Observed legacy enablement

  • TLS 1.1: 26 hostnames
  • TLS 1.0: 23 hostnames
  • SSLv3: 1 hostname

Why it matters: Even when legacy protocols are enabled “for compatibility,” they expand downgrade and weak-crypto attack surface, increase compliance exposure, and often correlate with outdated cipher suites.

Sample hostnames advertising legacy versions (illustrative subset)

  • aspirus-api.optum.com (TLS 1.0, 1.1, 1.2)
  • auth.bcbs.subropoint.optum.com (TLS 1.0–1.3)
  • bpoapi.optum.com (TLS 1.0, 1.1, 1.2)
  • myappsepic-ogr-west-cloud.optum.com (SSLv3, TLS 1.0, 1.1, 1.2)
  • plan-benefits-api-stage.optum.com (TLS 1.1, 1.2)

Expired Certificates Still Served

Observed: 11 endpoints serving expired certificates.

This is usually a sign of abandoned environments, misrouted traffic at the edge, incomplete certificate renewals, or “dark” deployments that still answer on 443. Expired certs erode client trust, can break integrations, and complicate incident response (clients frequently bypass warnings in internal tooling).

Sample (truncated)

HostnamePortExpiredIssuer
acet-advocate-assist-lab.optum.com4432025-08-08COMODO CA Limited
cloudprod-myoptum-green-nocdn.optum.com4432025-09-11COMODO CA Limited
clouddev-healthlibrary.optum.com4432025-09-11COMODO CA Limited
prism-card-msk-pub-broker1-dev.optum.com4432025-09-12COMODO CA Limited
prism-card-msk-pub-broker2-dev.optum.com4432025-09-12COMODO CA Limited

Revoked Certificates Still Served

Observed: 0
No data available (no revoked certificates were observed being actively served).

Cipher Exposure

The weak-cipher picture is mixed: the most frequent items are RSA key exchange and CBC+SHA1 families, with a smaller but important presence of 3DES. It’s plausible these reflect “broad compatibility” policies (older clients, embedded systems, or conservative load balancer templates). Even so, the practical outcome is measurable exposure: weaker suites remain selectable by some clients and can become the negotiated result in downgrade or constrained-client scenarios.

Weak ciphers (weakest first; complete list)

3DES (SWEET32-class risk; should be eliminated)

  • TLS_RSA_WITH_3DES_EDE_CBC_SHA — occurrences: 103; hostnames: 25

RSA key exchange (no forward secrecy; higher impact if key is compromised)

  • TLS_RSA_WITH_AES_128_GCM_SHA256 — 1,614; hostnames: 1,077
  • TLS_RSA_WITH_AES_256_GCM_SHA384 — 1,270; hostnames: 1,046
  • TLS_RSA_WITH_AES_256_CCM — 23; hostnames: 16
  • TLS_RSA_WITH_AES_256_CCM_8 — 22; hostnames: 15
  • TLS_RSA_WITH_AES_128_CCM — 8; hostnames: 8
  • TLS_RSA_WITH_AES_128_CCM_8 — 7; hostnames: 7
  • TLS_RSA_WITH_ARIA_256_GCM_SHA384 — 23; hostnames: 16
  • TLS_RSA_WITH_ARIA_128_GCM_SHA256 — 8; hostnames: 8
  • TLS_RSA_WITH_CAMELLIA_256_CBC_SHA — 50; hostnames: 28
  • TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 — 17; hostnames: 10
  • TLS_RSA_WITH_CAMELLIA_128_CBC_SHA — 5; hostnames: 5
  • TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 — 2; hostnames: 2

CBC + SHA1 (legacy MAC; avoid where possible, especially when TLS 1.0/1.1 also present)

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA — 1,662; hostnames: 1,124
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA — 1,612; hostnames: 1,095
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA — 132; hostnames: 31
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA — 132; hostnames: 31

Other legacy / non-preferred suites (often “enabled by template”)

  • TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 — 18; hostnames: 11
  • TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 — 3; hostnames: 3
  • TLS_DHE_RSA_WITH_AES_256_CCM — 24; hostnames: 17
  • TLS_DHE_RSA_WITH_AES_256_CCM_8 — 23; hostnames: 16
  • TLS_DHE_RSA_WITH_AES_128_CCM — 9; hostnames: 9
  • TLS_DHE_RSA_WITH_AES_128_CCM_8 — 8; hostnames: 8
  • TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA — 5; hostnames: 5

PQC Readiness

Post-quantum readiness here is measured as a binary signal from observed endpoints (as provided in the dataset), not as a full cryptographic inventory.

  • PQC-ready: 553 hostnames (2,321 occurrences)
  • Not PQC-ready: 3,385 hostnames (6,462 occurrences)

Interpretation: Early PQC-capable edges exist, but the majority of observed endpoints do not yet advertise PQC readiness. Given the domain’s scale and heterogeneity, this looks like selective enablement on specific platforms rather than a unified baseline.

Key Findings

  1. Legacy protocol tail persists (TLS 1.0/1.1 and even SSLv3). While numerically small, these endpoints can dominate risk if they sit on sensitive workflows, are externally reachable, or share infrastructure with modern services.
  2. Weak cipher exposure is not just theoretical: RSA key exchange and CBC+SHA1 appear at scale. This suggests policy/templates still permit non-forward-secret and legacy CBC suites, which can become negotiated for older clients or in downgrade conditions.
  3. 3DES is present and should be treated as an urgent cleanup item. Even “rare” 3DES availability is a red flag because removal is typically straightforward and the risk is well understood.
  4. Expired certificates are actively served on multiple endpoints. This is consistent with orphaned environments or certificate automation gaps and is a practical reliability/security problem.
  5. Certificate ecosystem is diverse and churn-heavy. A mix of 90-day and ~1-year validity issuers indicates multiple issuance pipelines; without strong policy enforcement, configuration drift (protocols/ciphers) becomes likely.

This data relies entirely on public sources accessible through the Internet without any authentication