An HTTPS certificate has an expiration date, and there was a time when people tracked it on a calendar: buy one for a year, set a reminder, buy again a year later. We wanted to see what this looks like on live sites today. We took 116 sites we had already measured for other market studies and checked the certificate on each one on 22 September 2026. For 104 of them we have an August measurement from 7–8 August, so their state can be compared; seven hotels were first captured only on 14 September. In the time between the two measurements, most of the certificates had already been replaced, and visitors noticed nothing.
In short: on 22 September the certificate passed verification on all 116 sites, and all 18 sites with the smallest August margin had received a new one. We found one worrying case, and it gets its own section.
What we measured and where the method stops
The sample was not put together for this article. These are root addresses we had already captured for other reasons: 41 online stores across seven niches, 28 sites from an SEO sample across six niches, 23 service sites across four niches, 17 education and construction sites, and 7 hotels. That makes 116.
The script connected to the root host on port 443 with the server name in the request (SNI) and fetched the certificate using the Python standard library. The chain of trust was validated against the system root certificate store.
Here is the first limitation you need to know to read the results correctly. Our script does not fetch intermediate certificates if the server did not send them. A browser sometimes does this on its own. So a chain error in our check does not necessarily mean a visitor saw a warning: their Chrome may have quietly pulled in the missing link. The reverse is also true: the padlock in your browser does not guarantee the chain is assembled correctly for every client, including payment services and bots that fetch nothing.
The second limitation: we checked only the root, without www or subdomains.
First measurement, August
On 7–8 August we were able to get the number of days until expiration for 104 hosts. The median remaining time was 61.5 days, the smallest was 24. For 97 of the 104 sites, between 30 and 90 days remained; for six, more than 90; for one, fewer than 30.
One more site, an auto repair shop, failed chain validation on 7 August: the script returned CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate. This error usually means the server did not send the intermediate certificate. On 22 September the same host passes verification, with an Asseco (Certum) certificate issued on 11 August 2026. We do not know exactly what changed on the server; we only see the result.
Second measurement, September
On 22 September all 116 sites completed the handshake without errors.
There turned out to be seven issuers. Let's Encrypt is on 77 sites, Google Trust Services on 30. Next come Sectigo and DigiCert with three each, and one certificate each from Asseco (Certum), GoGetSSL and ZeroSSL. Google Trust Services is often associated with Cloudflare, but we did not check the hosts separately, so we do not treat one as the other.
The validity period says more than the issuer names. 77 certificates were issued for 89 days, 31 for 90. That means 108 of 116, or 93%, run on free certificates designed for automatic renewal. Another eight have validity periods of 181 to 370 days, and these come from paid issuers.
Remaining time as of 22 September: median 59 days, minimum 8, maximum 163. Three sites had fewer than 30 days left.
Who renewed
The most interesting part shows up when you connect the two measurements. In August, 18 sites had 40 days or fewer. By 22 September, all 18 had received a new certificate.
The worst August state belonged to a store that had 24 days left on 8 August. Its new Let's Encrypt certificate was issued on 19 August, and as of 22 September it has 55 days to spare. Seven more sites had 31 to 33 days in August, and all of them got new certificates as early as 9–11 August.
Overall, of the 104 hosts in the August measurement, 72 got a new certificate between the two checks. This does not mean the rest are at risk: their renewal point simply has not come yet.
The one worrying case
A sports club site from the services sample. An 89-day Let's Encrypt certificate issued on 3 July 2026 expires on 1 October. On 7 August it had 54 days left, on 17 September 13, on 22 September 8.
A typical ACME client, meaning certbot and most hosting control panels, triggers renewal when 30 days remain. For this certificate, that is around 1 September. Three weeks after that date, the old certificate is still on the server.
The certificate did not renew, even though with typical settings it should have. It looks like broken auto-renewal, but we do not know that for sure: the owner may renew manually or have a nonstandard schedule. If nothing changes by 1 October, visitors will see a browser warning instead of the site.
The other two sites with fewer than 30 days left look fine. One has a 198-day paid Sectigo certificate with 22 days left: these are renewed by hand, and there is still time. The other has Let's Encrypt with 29 days, right at the threshold of typical renewal.
Why "buy it for a year and forget it" is ending
In 2025 the CA/Browser Forum, the body where browsers and certificate authorities agree on the rules, adopted ballot SC-081. The maximum validity of a public TLS certificate is being reduced in stages: 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029.
The first step is already visible in our sample. All three certificates with 364–370-day validity were issued before 15 March 2026: on 26 November and 15 December 2025 and on 8 February 2026. All paid certificates issued after that date have a validity of 181 or 198 days.
So the one-year certificate is going away even for those who pay. Manual renewal will have to happen every six months, and from 2029 roughly every six weeks. At that pace, a person sooner or later misses the date, which is why automatic renewal becomes a mandatory part of server maintenance. We set up certbot or the hosting panel and verify that renewal actually fires as part of server administration.
How to check your own site
For the first step, a terminal with OpenSSL is enough (it ships with Linux and macOS; on Windows, use Git Bash or WSL). Substitute your own address:
echo | openssl s_client -connect your-site.com.ua:443 -servername your-site.com.ua 2>/dev/null | openssl x509 -noout -dates -issuer
The command shows the issue date (notBefore), the expiration date (notAfter) and the issuer. The difference between the two dates tells you what kind of certificate you have: about 90 days most often means a free one designed for auto-renewal.
Next, a few conclusions from what you see.
If the certificate is a 90-day one and fewer than about 20 days remain, auto-renewal is most likely not working. Look for the cause in your hosting panel or in the certbot logs while the certificate is still valid.
Watch for the fact of renewal, not the date. The date changes on its own, and a reminder saying "certificate expires on 1 October" goes stale as soon as renewal has run. A more useful alert is one that fires when the remaining time drops below the point where renewal should already have happened: for a 90-day certificate, that is, for example, 20 days. This threshold can be added to uptime monitoring, and then you will learn about a failure well before the browser warning, and not from a customer.
Check the full chain. The same command with the -showcerts flag prints every certificate the server sends. If there is only one, with no intermediate, some clients will see an error even when your browser shows a padlock. Online chain checkers work too.
Don't stop at the root. The www address and subdomains may have separate certificates and separate renewal. We measured only the root, but you should check everything visitors can land on. While you are at it, look at what each of those addresses returns: you can check response codes and redirects with our tool.
What this measurement does not show
The sample is 116 sites we had already measured for other reasons. It does not represent the entire Ukrainian web, and you cannot derive the share of sites with expired certificates in Ukraine from it.
Both measurements capture the state on a specific date. We see that a certificate changed, but not how: automatically, by hand, or after someone's reminder. The word "auto-renewal" in this article refers to the certificate type and its typical maintenance method, not a verified fact on every server.
We measured only validity and issuer. So these data do not imply that a paid certificate offers nothing: the measurement did not touch its other properties.
And we checked only the root, so the state of www and subdomains on these sites remains unknown.
Whether the sports club site's certificate renews before 1 October only a repeat check will show. As for your own certificate, you can check it right now with the one command above.
