On 2026-09-21 I opened the public front door of sixteen detection and SOC vendors, one browser session per host, and kept two things from the TLS handshake: the negotiated key exchange group, and the certificate validFrom and validTo pair. The question was narrow. Not "is this vendor secure". Only this: what lifetime does the certificate on their own hostname actually carry, now that the CA/Browser Forum schedule has started to bite?
Issued lifetime below is validTo minus validFrom, in days.
| host | issued lifetime | key exchange group |
|---|---|---|
| elastic.co | 397 | X25519MLKEM768 |
| expel.com | 396 | P-256, X25519, X25519MLKEM768 |
| arcticwolf.com | 376 | X25519MLKEM768 |
| splunk.com | 364 | X25519MLKEM768 |
| crowdstrike.com | 198 | X25519MLKEM768 |
| wazuh.com | 197 | X25519MLKEM768 |
| rapid7.com | 197 | X25519MLKEM768 |
| blumira.com | 90 | X25519MLKEM768 |
| exabeam.com | 90 | X25519MLKEM768 |
| graylog.org | 90 | X25519MLKEM768 |
| huntress.com | 90 | X25519MLKEM768 |
| redcanary.com | 90 | X25519, X25519MLKEM768 |
| securityonionsolutions.com | 90 | X25519MLKEM768 |
| sentinelone.com | 90 | X25519MLKEM768 |
| sophos.com | 90 | X25519MLKEM768 |
| todyl.com | 90 | X25519MLKEM768 |
Three clusters, and nothing between them. Nine hosts sit at exactly 90 days. Three sit at 197 to 198. Four sit at 364 to 397. There is no host at 120 days, none at 150, none at 250. This population isn't a spread. It is three points.
The number that made me write this down: zero of sixteen is at or under 47 days.
The CA/Browser Forum schedule caps issuance at 200 days from 2026-03-15, at 100 days from 2027-03-15, and at 47 days from 2029-03-15. Seven of these sixteen currently carry a certificate longer than 100 days, so seven renewal processes have to change shape before March 2027. All sixteen have to change again before March 2029.
The set reconstructs that schedule without being asked to. Every certificate here issued before 2026-03-15 runs 364 to 397 days. Every certificate issued after it runs 90 to 198 days. Sixteen out of sixteen, no exception. I didn't select for that. It fell out of the dates.
Two hosts served more than one key exchange group inside a single page load. On redcanary.com some responses came back classical X25519 while others came back hybrid. On expel.com three groups appeared at once, including P-256 over TLS 1.2. A single label per hostname hides that, so the table prints every group observed.
Controls, because a measurement without one is a story
Three of them, same sitting, same tool, and two are hosts anyone can hit.
Direction on group and protocol: sha256.badssl.com returned P-256 over TLS 1.2. Nothing collapses into a single hybrid label and nothing is forced into a TLS 1.3 bucket.
Fail closed: expired.badssl.com returned zero matching responses and therefore zero rows. A host whose certificate the browser rejects produces an absence, never an invented date. That matters more than it sounds, because it means a missing row in the table above would read as missing rather than as a clean result.
Discrimination inside the set: two of the sixteen came back with classical and hybrid groups on different responses of the same page load. The tool splits them apart on live data, not only on a rigged host.
What this doesn't measure
The marketing hostname only. Not the product plane, not the customer portal, not the API endpoint.
One client, one vantage point, one day. No repeat run, no second observer.
Several of these hosts sit behind a CDN. For those, the certificate describes the automation of whoever operates that CDN, not the engineering practice of the vendor. The issuers observed across the set were a mix of large cloud and CDN certificate authorities plus two commercial ones, which is roughly the shape you would predict from the 90-day cluster.
The sample is sixteen names chosen by hand. It isn't random and it isn't the whole market. One host redirected to a different hostname and was measured at the destination it landed on. Another redirected as well and was dropped instead of being silently attributed.
Lifetime is read from what the browser reports for the certificate it actually received. Certificate Transparency logs were not pulled.
How to run it yourself
Any TLS client that reports both the negotiated group and the certificate dates will do. The browser developer tools print both under Security. A scripted version attaches a Network.responseReceived listener over the debugging protocol, keeps only the responses whose hostname matches the host under test, and prints the matched count next to the total response count on every row, so that an empty result is visibly empty rather than quietly missing.
If you run the same check across your own vendor list, post the counts in the three buckets. I want to know whether the three cluster shape holds outside these sixteen names, or whether it's an artifact of picking well known ones.
Top comments (2)
The 47-day floor is a sobering number. Methodology question: was the TLS check a synthetic probe from a fixed vantage point, or did you replay real beacon sessions? Vendors tuned on lab traffic tend to score differently against noisy production TLS. Also curious whether any of the sixteen flagged the same session with different confidence levels - that gap is usually where the tuning lives.
Synthetic, single vantage point: one handshake per host on 2026-09-21, no replayed sessions. Nothing was submitted for anyone to flag. I kept only the negotiated group and validTo minus validFrom on each vendor's hostname, so there is no confidence dimension to compare. One limit: where a host sits behind a CDN, the lifetime describes that CDN's automation, not the vendor's.