TLS Landscape Report for SSL.com
Scope
This report evaluates the publicly observable TLS posture for the single domain scope:
- Primary domain:
ssl.com - Alternate names:
ssl.com(no additional alternates provided) - Observed inventory: certificates and hostnames associated with
ssl.comand its subdomains, based on the supplied dataset.
Scale (Issuer & Validity)
Overall footprint
- Hostnames observed: 147
- Certificates observed: 205
- SAN names: 373 total; 163 distinct; 210 duplicates (re-use across certificates)
Key algorithms (certificate count)
- RSA: 150
- ECDSA: 55
Top issuers & typical validity
Issuer data shows a strong tilt toward internally branded issuance, with shorter validity appearing primarily on ACME/Let’s Encrypt.
| Issuer | Common validity (days) | Certificates |
|---|---|---|
| SSL Corporation | 396 | 96 |
| SSL Corp | 396 | 18 |
| Let’s Encrypt | 90 | 16 |
| SSL Corporation | 365 | 16 |
| SSL Corporation | 397 | 8 |
| SSL Corporation | 104 | 7 |
| SSL Corp | 365 | 6 |
| Amazon | 394 | 4 |
| Leocert LLC | 396 | 3 |
| SSL Corporation | 378 | 3 |
Note: The issuer list contains multiple entries for “SSL Corporation” with different validity durations, suggesting multiple product profiles, lifecycle policies, or issuance pipelines.
Certificate Churn
Signals of churn are visible in repeated SAN usage across distinct certificates:
- Distinct SAN names: 163
- Duplicate SAN instances: 210
- Several names recur across many distinct certificates (top examples include
revoked-root-2022-ecc.ssl.com,login.ssl.com, andtools.ssl.com).
Top SANs by number of distinct certificates (sample from dataset):
| SAN name | Distinct certificates |
|---|---|
revoked-root-2022-ecc.ssl.com | 9 |
www.revoked-root-2022-ecc.ssl.com | 9 |
revoked-root-2022-rsa.ssl.com | 8 |
login.ssl.com | 7 |
www.revoked-root-2022-rsa.ssl.com | 7 |
*.next.tsp.ssl.com | 6 |
www.test-ev-rsa.ssl.com | 6 |
tools.ssl.com | 6 |
www.tools.ssl.com | 6 |
acme.cf-b.ssl.com | 6 |
Subdomain Structure
Hostname depth distribution (labels in the FQDN, e.g., api.example.com = 3):
- 2 labels: 1
- 3 labels: 65
- 4 labels: 64
- 5 labels: 15
- 6 labels: 2
This is a subdomain-heavy environment, with most names living at depth 3–4, consistent with service segmentation (e.g., cdn, acme, help, staging) and nested stacks (e.g., api.staging.ssl.com).
Most common subdomains
Most common subdomains (top “level-3 bucket” under ssl.com). Counts include all hostnames matching *.bucket and deeper.
| Level-3 bucket | Hostnames (distinct) |
|---|---|
int.ssl.com | 32 |
cf-i.ssl.com | 7 |
cf-b.ssl.com | 5 |
tsp.ssl.com | 4 |
staging.ssl.com | 3 |
help.ssl.com | 2 |
acme.ssl.com | 2 |
acme-qa.ssl.com | 2 |
cdn.ssl.com | 2 |
acme-try.ssl.com | 2 |
Investigative note: The prominence of int.ssl.com suggests either internal integration surfaces exposed to the public Internet, a development/testing namespace, or an intentionally public “integration” fabric. In any of those cases, it tends to be where legacy compatibility and configuration drift accumulate.
TLS Versions
Observed TLS protocol support across the dataset:
| TLS Version | Hostnames | IPs |
|---|---|---|
| TLS1.3 | 46 | 224 |
| TLS1.2 | 66 | 240 |
| TLS1.1 | 4 | 29 |
| TLS1.0 | 2 | 5 |
Legacy TLS
Legacy protocol support remains present:
- TLS 1.1: 4 hostnames
- TLS 1.0: 2 hostnames
Sample endpoints advertising legacy versions:
| Hostname | Port | Legacy versions observed |
|---|---|---|
awscdn.ssl.com | 443 | TLS1.1 (also TLS1.2, TLS1.3) |
cdn.ssl.com | 443 | TLS1.0, TLS1.1 (also TLS1.2) |
help.ssl.com | 443 | TLS1.0, TLS1.1 (also TLS1.2, TLS1.3) |
sandboxcdn.ssl.com | 443 | TLS1.1 (also TLS1.2, TLS1.3) |
Risk context: TLS 1.0/1.1 are deprecated and commonly blocked by modern security baselines. Their presence can indicate (a) legacy client accommodation, or (b) configuration inheritance from older platform templates/CDN edge settings. Either way, they expand downgrade surface area and increase exposure to older cipher suites.
Expired Certificates Still Served
Count: 14
Sample observations (duplicates present in the provided samples):
| Hostname | Port | Noted expiry | Issuer |
|---|---|---|---|
acme-test1.ssl.com | 443 | 2025-03-06 | SSL Corporation |
cf.status.ssl.com | 443 | 2026-01-03 | Let’s Encrypt |
sandbox.ssl.com | 443 | 2026-01-11 | SSL Corporation |
legal.ssl.com | 443 | 2026-01-11 | SSL Corporation |
acme-try.cf.ssl.com | 443 | 2025-12-13 | SSL Corporation |
Investigative note: Some sample “expired” entries show dates in late 2025/early 2026, which do not read as expired relative to the report’s timestamp context. This may indicate a labeling/collection artifact (e.g., “non-current,” “mismatched,” or “stale chain served” being grouped as “expired”). Even with that caveat, the dataset asserts 14 instances of expired certificates being served and they warrant validation in follow-up checks.
Revoked Certificates Still Served
Count: 6
Sample hostnames:
revoked-ecc-dv.ssl.comrevoked-ecc-ev.ssl.comrevoked-root-2022-ecc.ssl.comrevoked-root-2022-rsa.ssl.comrevoked-rsa-dv.ssl.comrevoked-rsa-ev.ssl.com
Risk context: Serving revoked certificates is not just a hygiene issue—it can be interpreted as an intentional test harness (these names strongly suggest that) or as operational residue. Regardless of intent, publicly reachable endpoints serving revoked leafs can confuse automated trust monitors, increase incident-handling overhead, and create misleading signals for downstream consumers. If these are test endpoints, clearly segmenting them (network controls and explicit banners) reduces reputational and scanning noise.
Cipher Exposure
The dataset flags the following weak cipher suites. Weakness here is evaluated by common contemporary policy: avoidance of 3DES, avoidance of RSA key exchange (no forward secrecy), and avoidance of CBC with SHA-1.
Weakest-first listing (do not ignore rare ciphers)
1) 3DES (highest priority to eliminate)
TLS_RSA_WITH_3DES_EDE_CBC_SHA— occurrences: 4; hostnames: 1
Why it matters: 3DES is vulnerable to practical attacks (e.g., SWEET32 class issues) and is broadly prohibited by modern baselines.
2) RSA key exchange (no forward secrecy)
These suites indicate static RSA key exchange, meaning session compromise can follow from server private key compromise (no PFS). Even when paired with modern AEAD (GCM/CCM), policy typically disallows them.
TLS_RSA_WITH_AES_256_GCM_SHA384— 37 occurrences; 6 hostnamesTLS_RSA_WITH_AES_128_GCM_SHA256— 37 occurrences; 6 hostnamesTLS_RSA_WITH_AES_128_CCM— 1 occurrence; 1 hostnameTLS_RSA_WITH_AES_128_CCM_8— 1 occurrence; 1 hostnameTLS_RSA_WITH_AES_256_CCM— 1 occurrence; 1 hostnameTLS_RSA_WITH_AES_256_CCM_8— 1 occurrence; 1 hostnameTLS_RSA_WITH_CAMELLIA_128_CBC_SHA— 1 occurrence; 1 hostnameTLS_RSA_WITH_CAMELLIA_128_CBC_SHA256— 1 occurrence; 1 hostnameTLS_RSA_WITH_CAMELLIA_256_CBC_SHA— 1 occurrence; 1 hostnameTLS_RSA_WITH_CAMELLIA_256_CBC_SHA256— 1 occurrence; 1 hostname
Interpretation: The relatively high count for RSA+AES-GCM suggests an explicit compatibility stance or inherited server policy for older clients. That may be intentional, but it still increases exposure: it weakens confidentiality guarantees under key compromise and can complicate compliance narratives.
3) CBC + SHA-1 (legacy MAC; often policy-blocked)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA— 29 occurrences; 4 hostnamesTLS_ECDHE_RSA_WITH_AES_128_CBC_SHA— 29 occurrences; 4 hostnames
Why it matters: While ECDHE provides PFS, CBC+SHA1 suites are legacy and commonly disabled to reduce padding/MAC oracle risk classes and to align with strict baselines.
Additional legacy/edge suites observed
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256— 1 occurrence; 1 hostnameTLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384— 1 occurrence; 1 hostnameTLS_DHE_RSA_WITH_AES_128_CCM— 1 occurrence; 1 hostnameTLS_DHE_RSA_WITH_AES_128_CCM_8— 1 occurrence; 1 hostnameTLS_DHE_RSA_WITH_AES_256_CCM— 1 occurrence; 1 hostnameTLS_DHE_RSA_WITH_AES_256_CCM_8— 1 occurrence; 1 hostnameTLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA— 1 occurrence; 1 hostname
Bottom line: Even if the weak suites are concentrated on a small number of endpoints, they tend to be “policy smell”—evidence of older configuration profiles or compatibility modes. The standout is the repeated presence of RSA key exchange suites across multiple hostnames.
PQC Readiness
PQC readiness is reported as a binary flag in the dataset (methodology not provided). Observed distribution:
- PQC-ready: 36 hostnames (236 occurrences)
- Not PQC-ready: 30 hostnames (54 occurrences)
Interpretation: PQC enablement appears partial and uneven. Without the underlying definition (e.g., hybrid KEM support, PQC certificates, or edge-provider feature flags), this should be treated as an indicator for where to verify rather than a definitive compliance statement.
Key Findings
- Legacy TLS persists at the edges. TLS 1.0/1.1 are still enabled on a small but non-trivial set of hostnames, expanding downgrade and legacy cipher exposure.
- Weak ciphers are present, with RSA key exchange notably common. The counts for
TLS_RSA_WITH_AES_{128,256}_GCM_*suggest compatibility policy or inherited configurations that sacrifice forward secrecy. - 3DES is still advertised (even if rare). One hostname offering
TLS_RSA_WITH_3DES_EDE_CBC_SHAis enough to fail many modern security baselines. - Revoked certificates are actively served on multiple hostnames. The naming indicates deliberate revocation test endpoints, but their public reachability still carries operational and reputational implications.
- “Expired certificates served” needs validation. The dataset flags 14 instances, but sample dates include future expiries—suggesting either a categorization bug or a broader “non-current/stale” condition.
- Certificate ecosystem is RSA-heavy. RSA (150) dominates ECDSA (55), which may be fine for compatibility but can slow modernization efforts (including PQC/hybrid experiments) depending on platform constraints.
- Subdomain sprawl concentrates in
int.ssl.com. Large integration-style namespaces are common locations for drift (legacy protocols, older cipher policies, and stale certificate deployment paths).
This data relies entirely on public sources accessible through the Internet without any authentication