Direct answer: of 25 homepages, 23 completed a TLS handshake and 21 passed certificate verification. E13's certificate expired 1,642 days ago and does not match the hostname, E27 uses a self-signed certificate, E04 timed out on port 443 three times, and E16 returned an internal TLS alert three times. Eighteen sites use TLS 1.3 and five use TLS 1.2; nine certificates expire in 31–90 days and none in the next 30 days.
This study only performs TLS handshakes and reads certificate fields; it sends no HTTP request and does not judge revocation status or page content.
Method: handshake for the certificate, then verify with the system store
On 2026-11-08 between 05:48 and 05:49 we ran two TLS checks against the final host of each of the 25 homepages from study 4: first a handshake with SNI and verification disabled, to read the protocol version and certificate; then a second handshake with the system trust store, to verify the chain and hostname. No HTTP request is sent; the connection timeout is 6 seconds; E04 and E16 were retried twice, 20 seconds apart.
| Item | Rule | Boundary |
|---|---|---|
| Handshake ok | TCP 443 plus a completed TLS handshake | Does not prove HTTP works |
| Verified | System trust store accepts and hostname matches | No OCSP, revocation or CT check |
| Expired | notAfter earlier than the check time | Certificate field only |
| Issuer | Normalised into eight classes | Issuer alone does not make a site safe |
| Expiry bucket | Days left in five buckets | One snapshot; renewal not predicted |
Result: 21 of 25 verify, two certificate failures and two handshake failures
| Result | Sites | Share of 25 |
|---|---|---|
| Handshake ok and verified | 21 | 84.0% |
| Handshake ok but verification failed | 2 | 8.0% |
| Handshake failed | 2 | 8.0% |
The two verification failures differ: E13's certificate expired in 2022 (1,642 days ago) and its name does not match the current host; E27 uses a self-signed certificate that still has 1,123 days left but has no trusted CA behind it. Browsers show different warnings, but public users cannot verify either identity normally.
Validity: nine certificates expire in 31–90 days
| Remaining validity | Certificates | Note |
|---|---|---|
| Expired | 1 | E13, 1,642 days ago |
| 0–7 days | 0 | — |
| 8–30 days | 0 | — |
| 31–90 days | 9 | Shortest 35 days (E12), longest 90 (E29) |
| >90 days | 13 | Includes the E27 self-signed certificate |
The 31–90 day bucket is the largest, consistent with a 90-day lifetime; no certificate expires within 30 days, so this batch currently has no public certificate close to expiry. Expiry is only a signal: certificates can be replaced early or revoked for key or domain reasons, and this study checks neither.
Protocols and issuers: TLS 1.3 on 18 of 23
| Protocol | Sites | Note |
|---|---|---|
| TLS 1.3 | 18 | 78.3% of the 23 completed handshakes |
| TLS 1.2 | 5 | E01, E08, E18, E19, E25 |
| No handshake | 2 | E04, E16 |
| Issuer | Certificates | Note |
|---|---|---|
| DigiCert | 8 | Most common |
| Other / unclassified | 7 | Includes the E27 self-signed certificate |
| Certum | 3 | — |
| Let's Encrypt | 3 | All within 90 days |
| TrustAsia | 2 | Includes the expired E13 certificate |
Reconciling the four SSL errors from the scheme pilot
Study 119 requested the http and https roots and saw SSL errors on E04, E13, E16 and E27 without attributing them. The handshakes here explain the four:
| Site | 02:41 https request | TLS / certificate now | Explanation |
|---|---|---|---|
| E04 | SSL error | Port 443 timeout (3 attempts) | No working HTTPS listener or network blockage |
| E13 | SSL error | Expired 1,642 days + hostname mismatch | Certificate problem, reproducible |
| E16 | SSL error | Internal TLS alert (3 attempts) | But HTTPS at 03:42 and 04:40 succeeded; handshake is unstable |
| E27 | SSL error | Self-signed certificate | Certificate problem, reproducible |
Two of the four are explained by certificates, one by an unreachable port and one by an intermittent handshake. E16 is the most interesting: the same site answered HTTPS at 03:42 and 04:40, then returned three internal TLS alerts from 05:48, so a single SSL error is not proof of a long-term outage.
What this means for acceptance
- An expired certificate is a hard failure. E13 has been expired for more than four years and browsers block it; expiry belongs in monitoring, not user reports.
- Self-signed is not valid. E27's self-signed certificate still has 1,123 days, but public clients cannot trust it; internal and public systems need different handling.
- Monitor expiry dates. Nine certificates expire in 31–90 days; 90-day certificates need a working automatic-renewal path.
- Log timeouts, TLS alerts and certificate errors separately. They lead to different fixes, and folding them into "SSL error" hides the cause.
- TLS 1.3 is no longer rare. 18 of 23 completed handshakes use it; TLS 1.2 still works, but cipher suites and an upgrade path should be checked. For website acceptance, see the website development service checklist.
Limits
- One snapshot: handshakes on 2026-11-08 05:48–05:49; CDNs and WAFs may vary by region or time.
- Handshake only: no HTTP request, so page, redirects or HSTS are not judged.
- No revocation check: no OCSP, CRL or certificate-transparency lookup; the chain is judged only by the system trust store.
- One network: no IPv6, regional or SNI variants were tested.
- 25-site pilot: E16's intermittent handshake failure is not attributed; no industry claim.
Data and reproduction
Anonymised data: equipment-homepage-tls-certificates-2026.csv (25 rows × 13 columns: handshake status, protocol, days left, expiry bucket, hostname match, verification result and reason, issuer class, SAN count, expired flag, check time, error type). The repository keeps docs/research/2026-11-homepage-tls-certificates.csv.
Parser: scripts/tls_certificate_probe.py; unit tests: scripts/test_content_tls_certificate.py (18 tests, no network). Run:
python -m unittest scripts.test_content_tls_certificate
Related: the homepage canonical and scheme-redirect pilot, the homepage security-header pilot, and the homepage cache, compression and revalidation pilot, and the homepage HTTP/2 and HTTP/3 pilot, and the homepage entity and compliance signal pilot, and the homepage CSP pilot.
Sources and definitions
- Sample: the final hosts of the 25 homepages from study 4 (same sample_id).
- Handshake: Python
sslwith SNI, 6-second timeout, 2026-11-08 05:48–05:49 (Asia/Shanghai). - Verification: the default system trust store plus hostname checking; the failure reason comes from
SSLCertVerificationError.verify_message. - Certificate fields: notBefore / notAfter / issuer / subjectAltName, decoded by the standard library.
- Issuer: normalised into fixed classes; the E27 self-signed certificate counts as "other".
Frequently asked questions
Does an unexpired certificate prove trust?
No. E27's self-signed certificate still has 1,123 days left, but no trusted CA backs it, so browsers still block it.
Should TLS 1.2 be retired?
Five sites still use TLS 1.2, which is not a vulnerability by itself; TLS 1.3 handshakes are simpler, so new configurations should prefer it.
Why are E04 and E16 missing from the certificate data?
E04 timed out on port 443 in all three attempts; E16 returned an internal TLS alert in all three. Neither completed a handshake, so no certificate could be read.
Is 31–90 days left dangerous?
Not unusual: 90-day certificates are common. Automatic renewal is what matters; this study records days left and does not judge renewal automation.
Do 25 sites represent the industry?
No. This is the same 25 equipment-company homepages from study 4; it describes only these pages and is not an industry sample.
Can the data be re-checked?
Yes. The public CSV has 25 rows by 13 columns; scripts/tls_certificate_probe.py has 18 offline unit tests.