On 22 September 2026 we checked the HTTPS certificates on 116 sites we had already measured for market studies, and for 104 of them we compared the state with August. All 116 passed verification, 108 run on 89- and 90-day free certificates, and only one site's certificate has still not renewed, even though with typical settings it should have by now. We walk through the measurements and the limits of the method, and show how to check your own site with a single command.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Your opinion helps us create better content
Help others learn about it - share the article on social networks
Thank you for helping us grow
Writes about what he builds himself: online stores on OpenCart, applications on Next.js, integrations and site speed. The articles carry measurements and checks a reader can repeat on their own project, not general advice. Commercial development since 2015.
Answers to common questions on the topic
The simplest way is a terminal command: echo | openssl s_client -connect your-site.com.ua:443 -servername your-site.com.ua 2>/dev/null | openssl x509 -noout -dates -issuer. It shows the issue date (notBefore), the expiration date (notAfter) and the issuer. The difference between the dates tells you the certificate type: about 90 days most often means a free one designed for automatic renewal. Also check the www address and subdomains separately, since they may have their own certificates.
Among the sites we measured, paid certificates are rare. Of the 116 sites we checked on 22 September 2026, 108 ran on 89- and 90-day certificates designed for auto-renewal, mostly Let's Encrypt and Google Trust Services. We measured only validity and issuer, so we do not claim a paid certificate offers nothing. But the "buy it for a year and forget it" argument is going away: under CA/Browser Forum ballot SC-081, certificates issued from 15 March 2026 are valid for no more than 200 days, and in our sample every paid certificate issued after that date has 181 or 198 days.
A typical ACME client, meaning certbot and most hosting control panels, triggers renewal when 30 days remain. If a 90-day certificate has fewer than about 20 days left, 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. Our sample had one such case: a sports club site's certificate had 8 days left on 22 September, even though with typical settings it should have renewed around 1 September.
Watch for the fact that renewal happened, not the date. The date changes on its own, and a reminder about it goes stale after the very first renewal. 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 a site's uptime monitoring.
Most often because of an incomplete chain: the server does not send the intermediate certificate, and the browser sometimes fetches it on its own. Scripts, bots and some services do not, and they see an error such as unable to get local issuer certificate. In our August measurement, this is what the check of an auto repair shop's site looked like; in September the same host was already passing with a new certificate. openssl s_client with the -showcerts flag will show the full chain.
Subscribe to our newsletter and receive useful tips, insights and news about web development, marketing and business.
Web developmentOn 21 September 2026, a type check on our site reported 154 errors, even though the build had been green every time: the check's result was simply thrown away. Inside, we found zeros in link statistics and in the analytics export, sorting that didn't sort, and tests that never ran. Here is how we worked through them, what we changed, and how to check your own project.
Web developmentOn 21 September 2026, the first day of per-route request tracking, the internal /api/health endpoint received 13,666 requests, 60% of application traffic, and every one of them hit the shared database. Here are the two settings that fixed it, what they cost us, and how to check your own healthcheck.
Web developmentOn 5 September 2026 we opened Grafana to check four alert rules our documentation had promised since 17 January. There were zero rules there, the metrics beneath them were empty, and the delivery channel was a placeholder. Here is what we put in their place, and how to check your own monitoring in half an hour.
