TLS Landscape Report for lenovo.com
Scope
This report assesses the observable TLS posture for the single domain scope lenovo.com, based on publicly reachable certificates, hostnames, and TLS handshakes attributable to that domain and its subdomains.
Scale (Issuer & Validity)
At Internet scale, lenovo.com presents a large, multi-issuer certificate estate with a heavy tilt toward short-lived certificates.
- Observed hostnames: 1,610
- Observed certificates: 2,201
- Total SAN entries observed: 5,181 (1,682 distinct; 3,499 duplicate instances)
Issuer & validity mix (top issuers by certificate count)
Short validity periods (notably 90 days) are prominent—often a sign of automated issuance, but also a driver of operational churn.
| Issuer | Typical validity (days) | Certificates |
|---|---|---|
| Let’s Encrypt | 90 | 596 |
| Google Trust Services | 90 | 469 |
| DigiCert, Inc. | 185 | 147 |
| Amazon | 395 | 111 |
| DigiCert Inc | 183 | 95 |
| GlobalSign nv-sa | 397 | 62 |
| SSL Corporation | 90 | 40 |
| CLOUDFLARE, INC. | 397 | 20 |
| TrustAsia Technologies, Inc. | 90 | 14 |
| ZeroSSL | 91 | 11 |
Key algorithm distribution (certificates)
| Key algorithm | Certificates |
|---|---|
| RSA | 1,776 |
| ECDSA | 425 |
Certificate Churn
Indicators of churn show up both in short-lived issuance and repeated SAN reuse across distinct certificates.
- Duplicate SAN instances: 3,499 (suggesting frequent re-issuance and/or repeated naming patterns)
- SANs appearing on the most distinct certificates (sample):
sso.lenovo.com(51 distinct certificates)*.sso.lenovo.com(31)lenovo.com(29)*.lenovo.com(27)
Operational note: high churn can be healthy (automation, rotation), but it also increases the chance that stale endpoints keep serving old, expired, or policy-inconsistent configurations.
Subdomain Structure
lenovo.com shows a deep and diverse subdomain topology, consistent with a large enterprise footprint.
Hostname depth distribution
| Labels in hostname | Occurrences |
|---|---|
| 2 | 1 |
| 3 | 440 |
| 4 | 710 |
| 5 | 354 |
| 6 | 105 |
Most common subdomains
Counts include all hostnames matching *.bucket and deeper under that bucket.
| Level-3 bucket | Distinct hostnames |
|---|---|
uds.lenovo.com | 177 |
partnerhub.lenovo.com | 106 |
uds-qa.lenovo.com | 78 |
lena.lenovo.com | 56 |
xclarityone.lenovo.com | 48 |
cochat.lenovo.com | 46 |
uds-sse.lenovo.com | 41 |
uds-sit.lenovo.com | 38 |
pcc.lenovo.com | 37 |
moli.lenovo.com | 36 |
TLS Versions
The ecosystem largely supports modern TLS, but legacy TLS remains present on a non-trivial set of endpoints.
| TLS Version | Hostnames | IPs |
|---|---|---|
| TLS 1.3 | 553 | 720 |
| TLS 1.2 | 767 | 909 |
| TLS 1.1 | 16 | 29 |
| TLS 1.0 | 15 | 28 |
Legacy TLS
Legacy protocol support persists:
- TLS 1.1: 16 hostnames
- TLS 1.0: 15 hostnames
Sample endpoints observed offering legacy versions (port 443):
agile.lenovo.com(TLS 1.0 / 1.1 / 1.2)jobs.lenovo.com(TLS 1.0 / 1.1 / 1.2)hawk.lenovo.com(TLS 1.0 / 1.1 / 1.2)yun.lenovo.com(TLS 1.0 / 1.1 / 1.2)legion.lenovo.com(TLS 1.0 / 1.1 / 1.2 / 1.3)promotions.lenovo.com(TLS 1.0 / 1.1 / 1.2 / 1.3)
Risk context: TLS 1.0/1.1 are deprecated and can expose clients to downgrade pressure and compatibility-driven weak cipher enablement. Even if intended for legacy client populations, keeping these protocols enabled tends to widen the cipher surface area.
Expired Certificates Still Served
Observed count: 12 endpoints serving expired certificates.
Sample (port 443):
| Hostname | Expired at (UTC) | Issuer |
|---|---|---|
test.qi.lenovo.com | 2023-08-19 | DigiCert Inc |
d.codata.lenovo.com | 2025-05-16 | DigiCert Inc |
www.thinkcloud.lenovo.com | 2025-07-03 | DigiCert, Inc. |
app16.qliksense.lenovo.com | 2025-07-17 | DigiCert, Inc. |
pats.lenovo.com | 2025-08-15 | DigiCert, Inc. |
test.codata.lenovo.com | 2025-10-24 | DigiCert, Inc. |
mtyprismaa24.lenovo.com | 2025-11-13 | DigiCert, Inc. |
nss-k1-pilot-gateway.lenovo.com | 2025-12-10 | Let’s Encrypt |
Editorial note: even a small number of expired endpoints can be a meaningful indicator of orphaned services, inconsistent deployment pipelines, or monitoring gaps—especially in a domain with high certificate churn.
Revoked Certificates Still Served
Observed count: 0
No data available.
Cipher Exposure
Weak cipher exposure is where lenovo.com shows the clearest policy tension: much of the observed weakness is driven by RSA key exchange and CBC-mode suites, often associated with legacy compatibility settings. Even if intentionally enabled (e.g., for older clients or embedded stacks), these suites materially increase risk.
Weakest ciphers first (do not ignore rare suites)
3DES (SWEET32-class risk; 64-bit block cipher)
TLS_RSA_WITH_3DES_EDE_CBC_SHA— 42 occurrences; 11 hostnamesTLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA— 18 occurrences; 3 hostnames
RSA key exchange (no forward secrecy; compromises are retrospective)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA— 128 occurrences; 94 hostnamesTLS_RSA_WITH_CAMELLIA_128_CBC_SHA— 128 occurrences; 94 hostnamesTLS_RSA_WITH_AES_128_CCM— 114 occurrences; 58 hostnamesTLS_RSA_WITH_AES_256_CCM— 114 occurrences; 58 hostnamesTLS_RSA_WITH_AES_256_CCM_8— 107 occurrences; 51 hostnamesTLS_RSA_WITH_AES_128_CCM_8— 107 occurrences; 51 hostnamesTLS_RSA_WITH_CAMELLIA_256_CBC_SHA256— 87 occurrences; 53 hostnamesTLS_RSA_WITH_CAMELLIA_128_CBC_SHA256— 87 occurrences; 53 hostnamesTLS_RSA_WITH_ARIA_128_GCM_SHA256— 74 occurrences; 49 hostnamesTLS_RSA_WITH_ARIA_256_GCM_SHA384— 74 occurrences; 49 hostnamesTLS_RSA_WITH_SEED_CBC_SHA— 18 occurrences; 4 hostnames
CBC + SHA1 (legacy integrity; broader downgrade/legacy posture signal)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA— 61 occurrences; 14 hostnamesTLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA— 61 occurrences; 14 hostnamesTLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA— 29 occurrences; 29 hostnames
Other notable weak/legacy-adjacent suites (still worth tracking)
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384— 87 occurrences; 53 hostnamesTLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256— 87 occurrences; 53 hostnamesTLS_DHE_RSA_WITH_AES_256_CCM_8— 7 occurrences; 7 hostnamesTLS_DHE_RSA_WITH_AES_256_CCM— 7 occurrences; 7 hostnamesTLS_DHE_RSA_WITH_AES_128_CCM_8— 7 occurrences; 7 hostnamesTLS_DHE_RSA_WITH_AES_128_CCM— 7 occurrences; 7 hostnames
Risk framing:
- 3DES is broadly discouraged due to practical collision risks in long-lived sessions and high-volume traffic scenarios.
- RSA key exchange removes forward secrecy; a future key compromise can decrypt previously captured traffic.
- CBC/SHA1-era suites often correlate with enabling legacy protocol versions and can be leveraged in downgrade-prone environments.
PQC Readiness
Post-quantum readiness signals appear mixed.
| PQC ready | Distinct hostnames | Occurrences |
|---|---|---|
| true | 120 | 573 |
| false | 650 | 1,578 |
Interpretation: a minority of observed endpoints appear PQC-ready, while a larger set does not. In practice, “PQC-ready” often reflects edge/CDN capabilities or specific TLS stacks rather than a uniform enterprise standard—suggesting uneven rollout.
Key Findings
- Legacy protocol exposure persists: 15 hostnames with TLS 1.0 and 16 with TLS 1.1 indicate pockets of legacy compatibility that likely expand cipher risk.
- Expired certificates are still being served (12 endpoints): this is a concrete operational weakness and a common marker for neglected services or broken renewal/deploy chains.
- Weak cipher surface includes 3DES and extensive RSA key exchange suites: even if driven by policy for compatibility, these configurations measurably reduce confidentiality guarantees (notably forward secrecy).
- Short-lived certificates dominate issuer mix: Let’s Encrypt and Google Trust Services (90-day) account for a large share, suggesting automation—and simultaneously a higher need for tight hygiene to avoid “stranded” expired deployments.
- PQC readiness is uneven: a meaningful subset is PQC-ready, but most observed endpoints are not, implying the organization is likely in an early or partial transition phase.
This data relies entirely on public sources accessible through the Internet without any authentication