A certificate on a site I run expired in August 2026 and stayed expired for eight days, because the renewal had been failing quietly for months and nothing was watching. I wrote up the cause separately. The question that followed was how common this is on ordinary Indian sites, the kind run by one person or a small business with a hosting plan and no engineer. I expected the answer to be embarrassing for the web. It was not, quite.
Method
The sample comes from the Majestic Million, a free daily list of the million most-linked domains on the web, downloaded on 1 September 2026. I kept domains on Indian country-code TLDs (.in, .co.in, .org.in, .net.in, .firm.in, .ind.in), dropped government, academic and research TLDs, and kept only those with a global rank of 300,000 or worse. That left a pool of 3,953 domains. A seeded random sample of 500 was drawn from it. The seed and the filter are in the sampling script published with this report, so the sample can be rebuilt.
“Long tail of the Majestic Million” is not the same thing as “small business”, and the sample shows it. It contains a few alternate domains of large brands, a state utility, one central government scheme and several parked or dead domains, alongside the small commercial sites that were the target. I have not removed any of them. The filter is stated and the results are reported for what it produced.
Each host was checked once, on the bare domain, on 1 September 2026, from my own machine on a residential connection. Two connections per host. The first was a verified TLS handshake using Python’s default trust store, to record whether an ordinary client would accept the certificate and, if not, why. The second was an unverified handshake to read the leaf certificate’s issuer, expiry date and subject alternative names regardless of validity. The www subdomain was not checked, which means a site that redirects bare to www with a different certificate on each is reported on the bare certificate only.
The cloud environment I usually work from could not run this scan. Its outbound TLS is intercepted by a gateway that presents its own certificate for every host, so every result would have been the gateway’s. The scan ran on my own machine.
What 500 hosts produced
Of 500 hosts, 444 presented a certificate. 43 no longer resolve in DNS, 8 timed out, 2 refused the connection on port 443, 2 returned a TLS alert during the handshake, and 1 failed at the socket level. The 43 with no DNS record deserve their own paragraph and get one below.
Among the 444 certificates, 3 were expired. One Let’s Encrypt certificate had expired 75 days earlier, a second 1,341 days earlier, which is a site that has been serving a browser warning for well over three years, and one GoDaddy certificate had expired 376 days earlier and was also issued for a different hostname. A further 5 certificates had fewer than 14 days remaining and 8 more had between 14 and 29 days. So 16 of 444, 3.6 percent, were expired or inside 30 days.
The shape of the distribution is the story. 381 of 444 certificates had between 30 and 89 days remaining, which is exactly what a population of 90-day certificates renewing on schedule looks like. The 47 with more than 90 days are the annual certificates. There were none with more than a year left, which is consistent with the industry’s move to shorter maximum lifetimes.
Who issues the certificates
Let’s Encrypt issued 210 of the 444, 47 percent. Google Trust Services issued 162, 36 percent; almost all of those are the WE1 intermediate, which is what Cloudflare’s universal certificates and several managed hosts now use. Between them, 372 sites, 84 percent of the sample, are on 90-day certificates renewed by automation rather than by a person remembering.
The remaining 72 are on commercial certificates from DigiCert (19), Sectigo (14), GoDaddy (13), Amazon (12), GlobalSign (8), ZeroSSL (4) and two others. Most of these are annual. Amazon’s are automated through its own load balancers; the rest depend on someone renewing.
Where the risk actually sits
Two groups account for nearly all the near-expiry cases, and they fail in different ways.
The first group is the annual commercial certificates. 9 of the 72, 12.5 percent, were inside 30 days of expiry, against 6 of the 372 automated certificates, 1.6 percent. That comparison is not entirely fair, because an annual certificate spends a larger share of its life in any given 30-day window than a 90-day certificate does, and a certificate at 20 days on an annual plan is not yet a failure, since manual renewal near the end is normal. But it is the group where a missed calendar entry becomes an outage, and it is the group where the one 376-day expiry came from.
The second group is the one I went looking for. Certbot, the most common Let’s Encrypt client, attempts renewal when a certificate has 30 days or fewer remaining, and it tries twice a day. A Let’s Encrypt certificate with fewer than 30 days left is therefore a certificate whose renewal has already been attempted and has already failed, at least once, and usually many times. In this sample, 5 of the 210 Let’s Encrypt certificates were inside that window and 2 had already expired. Seven hosts, 3.3 percent, where the automation that everyone assumes is working has stopped working and has not yet produced a visible symptom. On the site I run, the same condition lasted for months before the certificate finally lapsed. These seven are on the same path.
Google Trust Services certificates showed 1 of 162 inside 30 days, which is consistent with Cloudflare renewing earlier in the lifetime than certbot does.
Three certificates were issued for a hostname other than the one requested, and 39 hosts, 8.8 percent, negotiated TLS 1.2 rather than 1.3, which is a configuration age signal rather than a fault.
The 43 domains that no longer exist
Forty-three of 500, 8.6 percent, had no DNS record at all. These are domains that still appear in a list of the million most-linked sites on the web and no longer resolve. They have expired as registrations, or been abandoned with the nameservers removed. Every link pointing at them, from every site that once cited them, now goes nowhere.
This is outside the question I set out to answer, but it is the largest single failure category in the data and it is worth stating for anyone who builds or buys links. A long-tail Indian domain with a backlink profile has, on this sample, roughly a one-in-twelve chance of being dead. The links are still counted in tools. The sites are gone.
What to take from this
If your site is on Cloudflare, a managed WordPress host, or any platform that handles certificates for you, this report is reassurance. The automated majority is in good shape and the failure rate is under 1 percent.
If you run your own server with certbot, the useful number is 3.3 percent, and the useful check takes ten seconds: how many days does your certificate have left? Fewer than 30 means renewal has already failed and you have until the number reaches zero to find out why. The guide I published alongside this report covers the most common cause I have seen, which is a redirect that sends the renewal challenge somewhere it cannot succeed.
If you are on an annual commercial certificate renewed by hand, you are in the group where the near-expiry rate is roughly eight times higher, and a calendar entry sixty days before expiry costs nothing.
Where I could be wrong
The sample is one day and 500 hosts. The expired count is 3, which is small enough that a different seed could produce 1 or 6. The direction of the finding, that automation has made expiry rare in this population, survives that; the precise percentages do not.
Checking the bare domain only is a real limitation. A site that redirects to www and serves a different certificate there could be fine on www and wrong on bare, or the reverse, and the browser warning a visitor sees depends on which URL they typed. A second pass on www would tighten the numbers.
The Majestic Million measures inbound links, not traffic or business size. The long tail of a link-ranked list skews towards sites that once had links and may no longer be maintained, which likely overstates both the dead-domain rate and the expiry rate relative to a sample of actively trading small businesses. A sample drawn from a business directory would answer a slightly different question and probably produce fewer dead domains.
The reading of Let’s Encrypt certificates under 30 days as renewal failures assumes certbot’s default renewal threshold. Other ACME clients renew at different points, and a site using one that renews at 15 days would be counted here as a failure while behaving normally.
Sources
- Majestic Million, daily download
- Let’s Encrypt, Integration guide, renewal recommendations
- Certbot documentation, renewing certificates
- Cloudflare, Universal SSL
- Google Trust Services
- Sampling script, scan script and raw results for this report, published alongside it [VERIFY: final public path for /data/r4-certs/]