SSL Certificate Validity Drops to 100 Days in 2027

SSL certificate validity drops to a 100-day maximum for publicly trusted TLS certificates issued from 15 March 2027. Let’s Encrypt gets there first: its default certificates move to 64 days on 10 February 2027. If your AI agents depend on HTTPS webhooks and APIs, renewal has to run on its own, not on someone remembering a date.

A common pattern: a phone provider sends an event to a webhook, an agent processes it, and an automation service updates a booking. Each hop looks simple until I map the HTTPS endpoints, the certificates they present and who is responsible for renewing each one.

This note is for founders and small teams running agents, webhooks and APIs on their own domains. It covers the published schedule, the endpoints worth checking, renewal automation and the monitoring I put around it.

What happens to SSL certificate validity in 2027?

The useful part isn’t only the shorter lifetime. It’s that the industry has published the whole schedule, so you can plan for it.

The CA/Browser Forum’s Ballot SC-081v3 passed when voting closed on 11 April 2025, with no votes against. The schedule now sits in the TLS Baseline Requirements, which cap the validity of publicly trusted certificates and how long a CA may reuse domain validation.

The CA/Browser Forum sets the maximum. Each certificate authority can issue shorter certificates, and Let’s Encrypt is doing exactly that. Its 64-day certificate announcement says every certificate it issues or renews on or after 10 February 2027 will last 64 days unless you pick a shorter profile, and it expects the last 90-day certificate to expire on 11 May 2027. It switched its staging environment to 64-day certificates on 14 October 2026, so you can test now. Its earlier 45-day plan covers the 2028 step and a new validation method, DNS-PERSIST-01.

I don’t treat 100 days as a renewal target. It’s a ceiling, not an operating schedule.

Why are certificate lifetimes getting shorter?

A certificate is a snapshot: at issuance, a CA confirmed the details for that domain. The longer a certificate lives, the more likely those details have drifted. The SC-081v3 ballot makes that argument directly, and Let’s Encrypt says shorter lifetimes reduce the risk of key compromise and mis-issuance.

For engineering, the implications are practical:

• Shorter exposure: a certificate issued on outdated information stays usable for less time.
• Fresher validation: issuance has to rest on more recently checked domain control.
• More frequent replacement: infrastructure must swap certificates without a person in the loop.
• Less room for old assumptions: scripts written around 90-day certificates get fragile.

Shorter certificates don’t replace protecting private keys or securing servers. And they come with a trade-off: renewing more often means depending more on automation, working validation paths and monitoring.

So I treat this as infrastructure maintenance, not certificate shopping. The question isn’t which certificate lasts longest. It’s whether replacement can happen without interrupting whatever depends on it.

Which endpoints in an AI agent stack need certificates?

I start with the HTTPS connections, not the agent.

My AI voice agent build is a telephony-to-LLM pipeline with booking through n8n, a human handoff path, and fallback to voicemail with an automatic callback. It’s a useful picture of how many parts talk over HTTPS: the phone provider, the agent and the booking automation all have to reach each other’s endpoints.

Every endpoint in a chain like that needs a renewal owner. That doesn’t mean I run every certificate myself; a managed service usually handles its own. For a self-hosted stack, I check:

• Webhook receivers: public URLs that accept events from phone systems and other services.
• API gateways: domains that route requests to agents, services and integrations.
• Automation URLs: the public address of a self-hosted workflow tool.
• Admin panels: any management interface exposed to the internet, including its login endpoints.
• Reverse proxies: the servers that terminate HTTPS before forwarding traffic inside.
• Callback endpoints: URLs that external systems use to deliver results later.

When I weigh self-hosting n8n against custom code, certificate ownership is part of the deployment decision.

A common pattern: the automation tool runs on a private network, but its webhook URL is published through a reverse proxy. The proxy presents the public certificate, so renewing a certificate inside the app does nothing at the public entry point.

For each connection I write down the public hostname, where TLS terminates, how renewal works and which system owns it. Private internal endpoints need their own review; the public schedule doesn’t automatically govern private certificates.

Running agents on your own domains in 2027?

I can review which endpoints need certificates and whether their renewal is fully automatic.

Book a conversation

How do I automate renewal so the date never matters?

I let an ACME client handle issuance and renewal instead of building a calendar reminder around expiry. ACME is the protocol for requesting certificates and completing validation; the client just has to keep up with the CA’s rules.

The order I build it in:

1. Find the certificate owner. Identify the proxy, web server, ingress controller or managed service that actually presents the certificate.
2. Set up an ACME client. Use the right integration for that environment and turn on unattended renewal.
3. Keep validation working. Make sure the HTTP or DNS challenge still works when renewal runs, not just on day one.
4. Renew by proportion, not by days. Renew at roughly two-thirds of the certificate’s lifetime instead of after a fixed number of days.
5. Use ACME Renewal Information where supported. ARI lets the CA tell a compatible client when to renew.
6. Load the new certificate. Make sure the service presenting HTTPS actually picks up the replacement and its matching key.
7. Check from outside. Verify the certificate the public endpoint serves, not just the file the renewal wrote.

Let’s Encrypt’s 64-day announcement says that if renewals are automated and your client supports ACME renewal information, you “should be all set.” If renewals are hard-coded to a date from expiry, it recommends switching to roughly two-thirds of the lifetime.

I prefer a client that does this for me. A custom script can make sense in a constrained environment, but then I own its scheduling, validation, error handling and reload logic.

Why does the validation method matter?

An installed ACME client doesn’t guarantee a successful renewal. For HTTP validation, the challenge path has to be reachable on the domain. For DNS validation, the system has to be able to publish the record. With Let’s Encrypt cutting authorization reuse to 10 days in February 2027 and to seven hours in 2028, validation will run far more often, so it has to be repeatable.

I re-test the full renewal after any change to DNS, proxy routing, firewall rules or deployment config. This is general engineering guidance, not security or compliance advice; the exact setup depends on your infrastructure and client.

What should you grep for before March 2027?

Before touching certificate config, I search the deployment repo for anything that quietly assumes a certificate lasts a fixed time.

A common pattern: an old maintenance task waits a fixed interval, then requests a new certificate. That was fine for 90-day certificates. With Let’s Encrypt 64-day certificates, the timing may no longer leave enough margin.

My search list:

• Lifetime assumptions: 90 days, 90d, or comments that describe a fixed lifetime.
• Renewal delays: timers set to 60, 80 or 83 days. Let’s Encrypt names these exact numbers as the ones to grep for in cron jobs, wrapper scripts and runbooks.
• Schedulers: cron jobs, container tasks and deploy jobs that call renewal.
• Certificate paths: hard-coded PEM files that renewal replaces without the service noticing.
• Pinning: clients that trust one specific certificate rather than a managed chain.
• Validation dependencies: DNS permissions, HTTP challenge routes and proxy exceptions.
• Reload behaviour: services that need an explicit reload to serve a renewed certificate.
• Environment drift: staging and production using different owners or validation methods.

I also check config that lives outside the repo, such as host-level schedulers and control panels.

Pinning needs care. If an integration pins a specific leaf certificate, replacing it may need coordination with that client. I find the dependency first rather than ripping out a security control I don’t understand.

The goal is to swap date-based assumptions for behaviour that reads the actual certificate. For the wider reliability picture, see my AgentOps production notes; here I’m sticking to the HTTPS endpoints.

How do I monitor expiry without Let’s Encrypt emails?

Let’s Encrypt stopped sending expiration emails on 4 June 2025. I don’t design anything that relies on an email arriving before a certificate expires.

Renewal and certificate expiry monitoring do different jobs. Renewal tries to replace the certificate. Monitoring checks that the replacement happened and that the public endpoint is serving it. I keep these checks separate:

• Renewal ran: did the scheduled ACME job run, and what did it report?
• Time left: how much validity remains on the certificate actually being served?
• External view: does a client connecting to the public hostname get the expected certificate?
• Validation ready: can the system still complete its DNS or HTTP challenge?
• Loaded: did the proxy or app pick up the renewed certificate?
• Alert reaches someone: does a failed renewal or near expiry notify the person who can fix it?

The Let’s Encrypt monitoring options page lists third-party services that can handle expiration notifications.

I monitor from outside the application where I can. A certificate file on disk can be fresh while the reverse proxy keeps serving the old one. That matters most for webhook receivers, because the service calling your webhook sees what the public endpoint presents, not what your renewal log says.

A common pattern: renewal succeeds, but the service never reloads. The automation reports success, and only an external expiry check shows the problem. That’s why a successful renewal command is not my final proof.

What is on my 2027 certificate checklist?

I finish this review before 15 March 2027, not during a renewal failure. It’s about implementation, not any particular vendor.

• List every public HTTPS hostname used by agents, webhooks, APIs and automation services.
• Record which service terminates TLS for each hostname.
• Note whether renewal is handled by a managed service or by my own infrastructure.
• Confirm every self-managed public certificate renews unattended through ACME.
• Confirm the ACME client handles shorter lifetimes without fixed timers.
• Check whether the client supports ACME renewal information, and turn it on.
• Test the 64-day change against Let’s Encrypt’s staging environment.
• Verify HTTP or DNS validation still works after deployment changes.
• Grep scripts and config for hard-coded 90-day lifetimes and 60, 80 or 83-day timers.
• Review pinning and certificate file references in dependent services.
• Confirm the service that terminates TLS actually loads renewed certificates.
• Turn on external expiry monitoring with an alert that reaches a person.

I keep this inventory with the deployment docs. When a new webhook domain or admin panel appears, certificate ownership becomes part of its deployment review.

The move to 47-day certificates in March 2029 settles the design choice. Building around one lifetime is less useful than a renewal process that responds to whatever lifetime the certificate actually has.

Key takeaways

• Public TLS certificates issued from 15 March 2027 can last at most 100 days.
• Let’s Encrypt’s 64-day default arrives earlier, on 10 February 2027.
• Every public HTTPS endpoint in an agent workflow needs a clear renewal owner.
• ACME renewal, proportional or ARI-driven timing and repeatable validation beat fixed timers.
• Independent expiry monitoring matters, because a successful renewal doesn’t prove the right certificate is being served.

If you run agents on your own domains, book a conversation to review your renewal setup before March 2027, or see my AI agents and automation work. You can also subscribe to The Production Notes using the signup box below this post.

FAQ

Does the 100-day limit apply to certificates I already have?

No. The 100-day maximum applies to publicly trusted TLS certificates issued on or after 15 March 2027; it doesn’t shorten certificates issued earlier. The TLS Baseline Requirements set the schedule by issuance date. Your next renewal, though, has to follow whatever rule applies on the day it’s issued, so check your renewal setup now.

Will Let’s Encrypt certificates last 100 days in 2027?

No. Let’s Encrypt moves its default profile to 64-day certificates on 10 February 2027, before the 100-day industry maximum takes effect, and cuts authorization reuse from 30 days to 10. Its announcement says it won’t revoke valid certificates as part of the change. Configure renewal around the certificate’s real lifetime, not the industry cap.

Do I need to renew certificates manually more often?

No. In a supported environment, an ACME client renews automatically and adapts to shorter lifetimes, ideally using ACME renewal information. It should also handle validation and make sure the serving software loads the new certificate. Let’s Encrypt explicitly advises against manual renewal. Keep independent monitoring, because an automated renewal can still fail or never reach the public endpoint.

What happens if an agent webhook’s TLS certificate expires?

A service that validates the HTTPS connection can refuse to connect, so its request never reaches your webhook. What happens next depends on how that sender handles failed deliveries. I check the public certificate, restore a valid one through the normal renewal path, and then review the integration’s delivery status before assuming any requests were processed.