For most visitors, the small padlock next to the address in the browser is not a technical detail but a verdict: this site is fine. Behind it sits a certificate that encrypts the connection and confirms that the address belongs to the server that answers. That certificate has an expiry date, and the gap between two expiry dates is getting much shorter. Since 15 March 2026, a newly issued certificate may be valid for at most 200 days, from 15 March 2027 for 100 days and from 15 March 2029 for 47 days (CA/Browser Forum). At the same time, Chrome 154 has been in the stable channel since 22 September 2026 (Chrome Releases), and Google has announced that with this version the browser will ask for permission before the first visit to any public site without HTTPS (Google). Together, the two changes turn a task that used to come up once a year into an ongoing one. This article explains, from the owner's point of view, what is changing, how to recognize an expiring certificate and which questions belong on the list for your own provider.
What the padlock in the browser means to visitors
A certificate does two jobs at once. It encrypts whatever passes between visitor and website, meaning form entries, login details and the pages themselves.
And it confirms that the address in the browser really belongs to the server that answers. It is issued by a certificate authority, which first checks whether the applicant controls the domain. The rules for this are set by the CA/Browser Forum, in its own words a voluntary organization of certificate authorities and makers of browsers and other software that relies on certificates (CA/Browser Forum). Its Baseline Requirements are the reason the validity periods are changing: browsers only accept certificates that follow these rules. How HTTPS fits into broader protection of a website is covered in the article on keeping the attack surface of a business website small; this one is only about the certificate and its lifetime.
As long as the certificate is valid, nobody notices it. That changes on the day after it expires. The browser no longer sets up the connection quietly but shows a full-page warning: the connection is not secure, and third parties could read data. In Chrome, the error code NET::ERR_CERT_DATE_INVALID appears below it. Only someone who opens the advanced details and deliberately bypasses the warning gets through. Anyone who simply wanted a phone number or the opening hours is more likely to close the tab at this point and open the next search result. Inside the business, this is often noticed late: owners rarely load their own site fresh, and the warning only comes to light when someone calls to ask whether the website has been hacked.
- The website no longer opens; a full-page warning about an insecure connection appears instead
- Enquiries through the contact form stop arriving, without any error message reaching the business
- Embedded parts such as a booking window or a shop on a secondary address stay blank while the main page still loads
- Links from newsletters, ads and QR codes lead to the warning page instead of the offer
- Customers get in touch by phone and ask whether something is wrong with the site
Certificate and domain are two different things
Validity is shrinking: 398, 200, 100, 47 days
Until March 2026 the arithmetic was simple. A certificate issued before 15 March 2026 could be valid for up to 398 days (CA/Browser Forum), a little over a year.
Many businesses treated it accordingly: one invoice a year, one renewal a year, often done by hand in the hosting provider's customer menu. Since the cut-off date, that arithmetic no longer works. For certificates issued on or after 15 March 2026 and before 15 March 2027, the upper limit is 200 days (CA/Browser Forum). What counts is the issue date: a certificate issued in early March 2026 under the old maximum remains valid until it ends. Anyone who has not noticed anything so far will notice at the next renewal at the latest, because the new certificate only runs for about half as long.
The next stages are already fixed. From 15 March 2027 the maximum is 100 days, from 15 March 2029 it is 47 days (CA/Browser Forum). A second limit is less well known. Before a certificate authority issues a certificate, it checks whether the applicant controls the domain, and it may reuse the result of that check for a while. From 15 March 2026 that period is at most 200 days, from 15 March 2027 100 days and from 15 March 2029 only 10 days (CA/Browser Forum). In practice this means that from 2029 the domain will be checked again at almost every renewal. That only works if the proof, such as a DNS record or a file on the server, is still correct at that moment.
Scroll table sideways
| Certificate issued | Maximum validity | Domain validation reusable | Issuances per year, minimum by arithmetic |
|---|---|---|---|
| before 15 Mar 2026 | 398 days | under older rules | 1 |
| from 15 Mar 2026 | 200 days | 200 days | 2 |
| from 15 Mar 2027 | 100 days | 100 days | 4 |
| from 15 Mar 2029 | 47 days | 10 days | 8 |
The last column is simple arithmetic: 365 days divided by the maximum validity, rounded up. In practice the figure is higher, because nobody should let a certificate run to its last day; it makes sense to renew with some lead time so that a failure shows up before expiry. With a validity of 47 days (CA/Browser Forum), there is not much room left for that lead time. This is exactly where the "calendar entry once a year" model ends. Anyone still renewing by hand today will have to do it at least four times a year from 2027 and at least eight times a year from 2029, on time and for every address. This is not a fault you fix once, but a routine that should be built from the start so that it works without a reminder.
The calendar test
Chrome 154: a prompt before sites without HTTPS
The second change comes from the browser. At the end of October 2025, the Chrome security team announced that with Chrome 154 in October 2026 it would switch on the "Always Use Secure Connections" setting by default (Google).
Chrome will then ask for permission before a public site without HTTPS is opened for the first time. The setting itself is not new: it has existed since 2022 as an opt-in option (Google). In this mode Chrome attempts every connection first over HTTPS and shows a warning that can be bypassed if HTTPS is unavailable. What is new is that it is meant to apply to everyone who leaves the default unchanged.
Since 22 September 2026, Chrome 154 has been in the stable channel for Windows, Mac and Linux; according to the Chrome team, the rollout runs over the following days to weeks (Chrome Releases). Whether and when the prompt appears for a particular visitor therefore depends on when their browser updates and the new default takes effect. There was an intermediate step: with Chrome 147 in April 2026, the setting was to be switched on for the more than 1 billion users who have turned on Enhanced Safe Browsing protection in Chrome (Google). The warning can still be switched off by disabling the setting (Google). For a business this is little comfort: someone visiting a site for the first time reads the prompt before seeing anything of the offer, and hardly anyone changes a setting for that.
This means Chrome will ask for the user's permission before the first access to any public site without HTTPS.
Why now? Google publishes an HTTPS transparency report that tracks what share of navigations in Chrome use HTTPS. The figure was around 30 to 45 percent in 2015 and reached a range of 95 to 99 percent around 2020 (Google). Since then, according to Google, progress has largely stalled (Google). If navigations to private addresses on home or company networks are left out, the share on Windows rises from 95 to 98 percent, and on Android and Mac to over 99 percent (Google). What remains is a small set of public sites without HTTPS, and that remainder is exactly what the new default targets: old secondary addresses, forgotten campaign pages, booking forms on a separate server.
For visitors, the change is meant to cause little effort. Chrome does not warn on every visit, only when a site without HTTPS is new or has not been visited recently; instead of warning on about 1 in 50 navigations, the warning therefore appears much less often (Google). In an experiment with a small share of users, the share of navigations with a warning was considerably lower than 3 percent, and the median user saw fewer than one warning per week (Google). For a business, the same figure reads the other way round: the warning hits precisely the new visitors, the people arriving at the site for the first time through a search, an ad or a QR code. Regular customers who visit often do not see it repeatedly; people opening the site for the first time do.
Forgotten addresses: shop., booking., promo.
The main address of a business is usually encrypted today. The risk sits at the edges.
Over the years, secondary addresses pile up: shop. for an online shop that was discontinued at some point, booking. for the appointment system of a former provider, promo. or summer. for a campaign that ended long ago. Some of these addresses still point to a server where no certificate is renewed any more, or where there never was one. As long as nobody visits them, nobody notices. But as soon as an old flyer, a directory listing or a gift card refers to one of them, a new visitor ends up in front of either the Chrome prompt or a certificate warning. Pages where money or data change hands are particularly sensitive, for example when selling gift vouchers through the website: there, a warning costs a sale directly.
A second typical case is printed routes to the website. A QR code on a poster or business card only leads to the prompt if the address behind it offers no HTTPS. In this mode Chrome tries the encrypted connection first, even if the code still contains http://. If that fails because the secondary address sits on an old server without a certificate, the warning appears. How to plan QR codes and landing pages in offline advertising properly is covered in a separate article. Searching for old addresses is closely related to searching for old statements: if you are already reviewing website copy for statements with an expiry date, you can check the list of linked addresses in the same pass.
- The address with and without www: both variants need a valid certificate, even if one of them only redirects
- Secondary addresses for shop, appointment booking, customer portal or downloads
- Old campaign addresses printed on flyers, posters, vehicle lettering or in QR codes
- Additional domains, such as the spelling with a hyphen or a second ending, that redirect to the main site
- Addresses set up by a former provider that no longer appear in any current contract
- Links in email signatures, newsletter templates and directory listings
Address Purpose Certificate until Responsible
www.your-business.example Main site ____________ ____________
your-business.example Redirect to www ____________ ____________
shop.your-business.example Online shop, in use? ____________ ____________
booking.your-business.example Appointment booking ____________ ____________
promo.your-business.example Old campaign ____________ ____________
your-business-two.example Additional domain ____________ ____________Redirects need a certificate too
Reminder emails are no longer a safety net
For a long time there was a safety net that many relied on without knowing it: the certificate authority sent an email when a certificate was about to expire. That net is getting thinner.
The certificate authority Let's Encrypt ended its expiration emails on 4 June 2025 (Let's Encrypt). One of the reasons given was that over the past 10 years more and more subscribers had put reliable automation in place for renewal (Let's Encrypt). The message behind this applies regardless of the certificate authority: renewal is meant to run without human involvement, and anyone waiting for an email may be waiting in vain. Even where reminders are still sent, they go to the address stored at setup, and that is not rarely the mailbox of a former agency or of an employee who has left.
There is a second problem that grows with every stage. With a validity of 200 days, a renewal is due twice a year by arithmetic, with 100 days four times, with 47 days (CA/Browser Forum) eight times. Each of these dates is an opportunity for automation to fail: because a DNS record has changed, because a server has moved or because an access permission has expired. That is why it is not enough for renewal to be automatic; someone also has to find out when it does not work. If you are checking the contract and access details with your provider anyway, put this question on the same list.
Automatic with feedback
Renewal runs without anyone stepping in, and in case of an error a message goes to someone who reads it and acts. This is the model that still holds with a maximum validity of 47 days.
By hand, by calendar
Someone renews on schedule in the hosting provider's customer menu. At 398 days that meant one date a year, at 200 days it is two by arithmetic, from 2029 at least eight.
With the provider, no insight
The host or agency takes care of it, but nobody in the business knows how or when. That can work out, but it can only be judged once the answers to the five questions below are in.
An expiring certificate is also a case that a simple availability check may not notice: the server does answer, just with a certificate the browser rejects. Whether a check catches this depends on whether it evaluates certificate errors. How monitoring of website availability is set up and what it covers is a topic of its own. For the certificate, a plain rule in the maintenance routine for the website is enough: once a month, look at the expiry date of every address and compare it with the date of the last renewal.
Five questions for your own provider
Most businesses do not renew their certificate themselves but have handed it to a provider along with the hosting or the website contract. That is sensible as long as it is clear what happens there.
The following five questions can be asked by email and answered in a few lines. With the answers in writing, you know whether the next validity stage is an issue or not.
- Who renews the certificate for our addresses, and under which name is the job recorded on your side?
- Is renewal automatic or manual, and is the process set up for the maximum validity of 100 days from March 2027 and 47 days from March 2029?
- Who is notified when a renewal fails, through which channel and how quickly?
- Are all addresses covered: with and without www, secondary addresses, additional domains and redirects?
- Where can I look up the expiry date myself without having to ask you every time?
Scroll table sideways
| Provider's answer | What it means | Next step |
|---|---|---|
| "That runs automatically." | A good start, but incomplete: it is still open who notices a failure. | Follow up with question 3 and record the answer in writing |
| "We renew once a year." | The procedure dates from before 15 Mar 2026 and no longer fits the maximum validity. | Agree on a change before the next certificate expires |
| "You get an email before expiry." | A reminder does not replace renewal and depends on a mailbox that someone reads. | Check the recipient address and clarify who acts when the email arrives |
| "The main address is covered." | Secondary addresses and redirects may not be included. | Send the address list and have it confirmed line by line |
| "You can't see that, we handle it." | You have no insight of your own into the current state. | Look up the expiry date in the browser yourself and note it in the calendar |
None of these answers is a reason for concern on its own. They only show where a process depends on a single person who might be on holiday. Timing matters: the next stage applies to certificates issued on or after 15 March 2027 (CA/Browser Forum). Asking the questions in autumn 2026 leaves several months to change a procedure calmly instead of repairing it under time pressure.
Looking up the expiry date yourself
How it works with XICflow
With XICflow, the certificate is part of connecting the domain. After the first publication, a website is first reachable at a preview address of the form your-short-name.xicflow.com, and this address is encrypted.
When you connect your own domain, activation runs through several steps; one of them is called "3 · Issue the certificate". The message "Domain is being activated (SSL certificate being issued)." appears, and XICflow records the expiry date of the certificate. In the domain overview, active domains additionally carry the "SSL" marker, which means that encryption is set up for this address. How the individual steps work and what to do when a message appears is described in the handbook on publishing and connecting domains.
The domain itself stays where it is. You only change the DNS records with your provider; the domain remains in your ownership and with your provider. For addresses that do not run through XICflow, such as a shop or a booking system with another provider, the section on secondary addresses still applies: their certificate lies with the provider that operates them and belongs on the address list. An overview of what is included is on the page with the features of XICflow; how a website goes from preview to your own domain is shown in the getting started chapter of the handbook.
What matters in the end