In short and in plain language
A certificate lets your site use an encrypted link. Certificates will soon be valid for a shorter time.
So they must be renewed more often. If one runs out, visitors see a warning, not your site.
The article shows a way with no manual work. Renewal can run on its own.
You need a list of all your certificates. A check warns a named person before one runs out.
We set up renewal and checks for you.
For a long time, an HTTPS certificate was a job that came around once a year. That is changing in three steps. In its TLS Baseline Requirements, the CA/Browser Forum has set out that the maximum lifetime of newly issued certificates drops from the current 398 days (CA/Browser Forum) to 200 days (CA/Browser Forum) from 15 March 2026, to 100 days (CA/Browser Forum) from 15 March 2027 and to 47 days (CA/Browser Forum) from 15 March 2029. Anyone who replaces a certificate once a year today will be replacing it several times a year afterwards. A manual step that works once a year typically stops working at that rhythm, and an expired certificate is not a cosmetic flaw but a full-page warning in front of your home page. This article sets out the steps, describes what changes in day-to-day operation and lays out a route that works without a recurring manual step: a complete register of every certificate in use, automated renewal, monitoring that reports before expiry, and a written record of who does what if something goes wrong.
Key takeaways
- The maximum lifetime of new certificates falls in three steps: 200 days (CA/Browser Forum) from 15 March 2026, 100 days (CA/Browser Forum) from 2027 and 47 days (CA/Browser Forum) from 2029.
- The date of issuance is what counts. A certificate issued before a step keeps its lifetime; the pressure arrives with the first renewal after the cut-off date.
- In parallel, the period during which a validated domain authorisation may be reused falls to 10 days (CA/Browser Forum) from 2029. In practice, the authorisation is then revalidated for every issuance.
- Automated renewal is standardised and available in almost every common server environment. The real work is the register: which name sits on which service, and who is responsible for it.
- Automation belongs together with monitoring that measures from the outside what the server actually serves, and that reports before expiry to a named role rather than to a shared mailbox.
What changes from 2026
Which certificates a browser accepts is decided neither by the hosting provider nor by the certification authority alone. The common minimum requirements are set out in the TLS Baseline Requirements of the CA/Browser Forum, a body made up of certification authorities and browser vendors. Breaching one of those requirements costs a provider the trust of the browsers, which makes these rules more binding in practice than many a contract. Section 6.3.2 of that document governs the validity period of a subscriber certificate, precisely the span that sits between two renewals on your website.
The requirement distinguishes two levels: a SHOULD limit names the recommended value, a MUST limit the hard ceiling. For certificates issued before 15 March 2026, those values are 397 and 398 days (CA/Browser Forum). For issuance on or after 15 March 2026, they are 199 and 200 days (CA/Browser Forum). From 15 March 2027 they are 99 and 100 days (CA/Browser Forum), and from 15 March 2029 they are 46 and 47 days (CA/Browser Forum). The date of issuance is what decides: a certificate issued shortly before a step runs its full term and does not become invalid early.
A second period is shortening in parallel. It is less well known and has more effect on day-to-day operation: the reuse of validated authorisation data. Once a certification authority has validated that you control a domain name, it may reuse that result for a limited time. Section 4.2.1 reduces that span for domain names and IP addresses to 200 days (CA/Browser Forum) from 15 March 2026, to 100 days (CA/Browser Forum) from 15 March 2027 and to 10 days (CA/Browser Forum) from 15 March 2029. That last value is the real break point: from then on, the authorisation is revalidated for practically every issuance. Anyone who provides that proof by hand through a DNS record or a file in the web directory will be doing so at short intervals.
The issuance date decides, not the contract
The staged plan at a glance
The table below brings both periods together and names what is due in operation at each step. It is sorted by date of issuance, because that is the figure everything else follows. For the first row of the reuse column, the source gives no separate figure for domain names before the cut-off date, so that cell simply refers to the previous position.
| Issued | Maximum lifetime | Reuse of domain validation | What is due in operation |
|---|---|---|---|
| until 14 March 2026 | 398 days | as before | Build the register, set up automated renewal and watch it once |
| from 15 March 2026 | 200 days | 200 days | Renewal several times a year, monitoring with an earlier warning threshold |
| from 15 March 2027 | 100 days | 100 days | Resolve exceptions without automation, keep the validation path clear |
| from 15 March 2029 | 47 days | 10 days | Authorisation effectively per issuance, no manual operation envisaged |
Two things stand out in the table. First, lifetime and validation period move far apart at the last step: the certificate is valid for 47 days (CA/Browser Forum), while the authorisation may only be reused for 10 days (CA/Browser Forum). Second, the first row is the only one in which manual operation remains conceivable at all. After that, the question is no longer whether to automate, but who sets the automation up and who monitors it.
What shorter lifetimes mean in operation
HTTPS has long been the norm on the web. For its 2025 edition, the HTTP Archive Web Almanac reports that 98.8 percent (Web Almanac 2025) of all requests on mobile run over HTTPS, while the share of home pages rose to 97.3 percent (Web Almanac 2025). Encryption is therefore no longer an add-on but a foundation, and an expired certificate lands correspondingly hard. The browser does not show a small warning at the edge but a full-page interruption that most visitors will not click through.
What changes with shorter lifetimes is less the technology than the frequency. Every step a renewal requires now repeats more often: generate a key, prove the authorisation, collect the certificate, reload the service, check the result. A procedure that ran once a year off a calendar entry becomes a recurring source of disruption when there are several renewals a year, particularly where several people are involved or the same certificate sits in more than one place.
More renewals per year
One date a year becomes several. Each repetition is an opportunity for a fault nobody has seen before, because it could only occur once a year.
Shorter window when things break
If a renewal fails, less buffer remains before expiry. Monitoring therefore has to report earlier than it would with an annual certificate.
More places than expected
A certificate rarely sits on the web server alone. Reverse proxies, load balancers, mail servers and internal services often hold their own copies of the same file.
Mail names run along with it
Names used for incoming and outgoing mail need valid certificates too. If one expires there, delivery stalls without the website showing anything. How mail delivery is secured technically is covered in our article on SPF, DKIM and DMARC.
Reload instead of restart
After renewal, the service has to read the new file. A forgotten reload is a common reason why the browser still sees the old certificate even though a new one has been issued.
Alerts to a role
An expiry alert in a shared mailbox is typically overlooked. Responsibility belongs to a named role, with a stand-in for holidays and sickness.
Taken together, these six points are why the change rarely fails on the technology. It fails on overview and responsibility: the web server is automated, the mail server is not; the main domain renews, an old campaign address does not. Anyone who has already put the basics of website security in order has half of this list to hand already.
Automated renewal is the normal case
The way out of that rhythm has been standardised for years. RFC 8555 describes a protocol with which a program on your server proves the authorisation and collects a certificate without anyone operating an interface. Almost every common server environment ships an implementation, and most hosting interfaces offer the switch ready-made. RFC 9773 adds a hint from the other side about when renewal should be attempted, so that renewals do not all start at the same moment across every participant, and so that a certificate can be replaced early if it has to be revoked.
This document specifies how an Automated Certificate Management Environment (ACME) server may provide suggestions to ACME clients as to when they should attempt to renew their certificates.
For operations, that means the question is not whether a certificate can be renewed automatically, but whether it actually does so in every place. That can be checked, and without access to anyone else's systems. The list below is the state an environment should reach after the change.
- For every domain and subdomain it is known which system obtains the certificate and which one serves it.
- Renewal runs as a scheduled job, not as a reminder in one individual person's calendar.
- After renewal the service reloads the new file by itself; the reload is part of the job.
- The job writes its output to a log file, so that a failure can be read back later.
- Monitoring checks the served certificate from the outside and reports before expiry, not after it.
- Every alert has a named role that responds, plus a stand-in for holidays and sickness.
The fourth line is the one most often missing. A renewal job whose output is discarded has no signal that would reveal a persistent fault; it announces itself only once the certificate has expired. The same logic applies to backups; how to turn one into solid evidence is covered in our article on testing the restore.
Renew before it gets tight
Start with the certificate register
Every piece of automation starts with a list. Without one, you automate the places you know about and miss the ones that surface at the worst moment. The list does not come from memory but from three sources: the DNS records for the domain, the services on the servers involved, and the contracts with providers who operate names of their own.
Each entry needs four pieces of information: the name, the service that delivers it, the type of renewal and the responsible role. The expiry date deliberately does not belong there; it changes with every renewal and is measured, not maintained. It can be measured with standard tools, without access to any administration interface.
The first command shows what the server actually serves, not what is recorded in an interface. That is the difference that counts: a renewed certificate the service has not reloaded shows as current in the administration panel and still goes out over the wire as the old one. The second command checks the same point for the mail name, and the third shows whether the site responds at all.
The list counts names, not servers
Where renewal trips up
Automated renewal rarely fails on the protocol. It fails on environmental conditions that have changed between two renewals, and with short lifetimes each of those changes surfaces faster, because the next attempt comes sooner.
The list below comes from recurring patterns in operation. It is not exhaustive, but it covers the cases that typically show up first.
- A redirect in front of the validation path: a rule that sends everything to the home page or to HTTPS also catches the validation file used to prove the authorisation.
- DNS in two places: if the name points to a different provider than expected, the certification authority validates the wrong location. After a change of provider this often goes unnoticed.
- A CAA record that no longer fits: a CAA record sets out which authority may issue. If the provider changes without the record being adjusted, issuance fails.
- A certificate in several places: if the file is copied to a second service, that service has to reload as well. A copy step without a reload only surfaces weeks later.
- Access tied to one person: if administration access runs through a personal account, a change of staff blocks renewal. Which accounts should belong to whom is covered in our article on who owns your website, domain and access rights.
- Mixed content: after a renewal it sometimes becomes apparent that individual images or scripts are still embedded over HTTP. The certificate is valid, yet the page does not count as consistently encrypted.
It is striking that five of these six points are not questions of certificates at all, but of DNS, redirects and responsibilities. Short lifetimes only make them more visible, they do not create them. That is the good news about the change: working through it cleanly clears up building sites that had rarely surfaced before.
An exception becomes a standing burden
Monitoring, alerting and evidence
Automation without a check is an assumption. So the check does not measure the job but its result: what does the server serve today, and how long is it valid for? That measurement runs from the outside, independently of the renewing system, and it runs for every name in the register. The register itself can be a simple file; it has to be readable, complete and current, not pretty.
{
"as_of": "2026-09-25",
"names": [
{ "name": "www.example-site.example", "service": "Web server", "renewal": "automatic", "role": "Website care", "warn_days": 20 },
{ "name": "shop.example-site.example", "service": "Reverse proxy", "renewal": "automatic", "role": "Website care", "warn_days": 20 },
{ "name": "mail.example-site.example", "service": "Mail server", "renewal": "automatic", "role": "IT operations", "warn_days": 25 },
{ "name": "old-domain.example", "service": "Redirect", "renewal": "manual", "role": "open", "warn_days": 30 }
],
"alerting": {
"channel": "email",
"address": "operations@example-site.invalid",
"deputy": "management@example-site.invalid"
}
}Two fields carry the actual work. warn_days sets how many days before expiry the alert goes out; the value follows the response time of the people involved, not the lifetime of the certificate. And role with the value open is a visible gap, which is exactly why the file is kept at all. A line that reads manual and open is the task for the coming weeks, not an operating state.
The same file produces the evidence. If you have to show after an incident that encryption was set up in line with the state of the art, you do not produce a certificate but a documented arrangement together with its check. Article 32(1) GDPR ties precisely those together: the state of the art, the risk, and appropriate technical and organisational measures. A maintained register with responsibility, warning threshold and alerting route is fitting evidence for that; the wider framework is summarised in our GDPR website checklist.
Report before expiry, not after
What belongs alongside the lifetime
A short lifetime is an operational matter, not a security gain in itself. That comes from what is configured alongside it: the protocol version, the redirects, the embedded resources. Germany's Federal Office for Information Security regularly updates its technical guideline TR-02102-2 for this and names both the recommended version and the period for which a recommendation holds.
Two points from it are directly relevant to running a website. First, in the assessment of the Federal Office for Information Security, TLS 1.3 should be given preference. Second, TLS 1.2 is only recommended until the end of 2031 (BSI TR-02102-2), because on current knowledge no quantum-safe key agreement methods are being standardised for that version. Anyone setting a server configuration today therefore has a horizon to align it with, and a reason not to treat that configuration as a one-off task.
- TLS 1.3 is active and outdated protocol versions are switched off.
- All HTTP addresses redirect permanently to HTTPS, including the variants with and without www.
- HSTS is set so that the browser requests the encrypted version without a detour.
- No images, fonts or scripts are embedded over HTTP any more.
- A CAA record names the authority allowed to issue, and is adjusted when the provider changes.
- The configuration is measured again after every larger change, not only when it is first set up.
These six points have more to do with hosting than with the certificate itself. What role location, care and reachable contacts play here is covered in our overview of web hosting in Germany. And because every extra redirect and every additional resource also costs load time, it is worth reading our article on Core Web Vitals if you are working on the configuration anyway.
What this means for a small website
For a website with one domain, one hosting provider and one mailbox, the effort is manageable. In most hosting environments automated renewal is already set up; what remains is to check whether it really covers every name and whether an alert arrives when it does not. That is an hour of work, not a project, and it is easier to do before the first step than after it.
It gets more demanding where things have grown over the years: a second domain from an old campaign, a shop on its own subdomain, a booking system at a service provider, a mail server on the premises. In that case it is worth building the register before the first step takes effect. It is the same act of tidying that other grown structures need, customer groups and price rules in a B2B online shop, for instance: first the inventory, then the rule.
Three questions that show where you stand
We take this on as part of ongoing care: we record which names are in use, set up automated renewal including the reload of the services, clean up redirects and mixed content, and put in place monitoring that reports before expiry to a named role. We record the position in writing, so that the next step typically passes without anyone having to intervene. That fits web hosting just as well as an existing environment at another provider; the ongoing part is described on our website care page. If you would like to know where your own estate stands today, write to us through the contact form.
Sources and studies
Related Articles
Website Backups: Test the Restore, Not Just the Backup
A backup only counts once it has been restored. Why restore tests are required, which two target values matter and how a test run works in practice.
Switching Web Host: Move Site and Email Without Downtime
Change hosting provider without downtime for site and mailboxes: backups, auth code, TTL, parallel operation and a migration schedule from T-14 to T+7.
Website contracts: terms and year-end notice periods
Which contracts sit behind a website, how term, renewal and notice period interact, and why late September is the last date for a clean exit at the year's end.