# Let's Encrypt: Six-Day Certificates and Certificates for IP Addresses
Table of Contents
Anyone who runs a website knows TLS certificates: the small digital document that proves a server’s identity and lets the browser encrypt the connection, the thing that lights up the padlock next to the address. Until recently a Let’s Encrypt certificate lasted 90 days. As of 15 January 2026 the authority is making two new options available to everyone: certificates that expire after just over six days, and certificates that cover an IP address instead of a domain name. For people browsing, nothing changes. For people running servers it’s a clear signal about where the web is heading: certificate lifetimes are shrinking, just as the share of traffic already protected by post-quantum cryptography keeps growing, and automation is becoming the only sensible way to manage them.
The news in brief
Let’s Encrypt is a Certificate Authority (CA): the body that issues certificates, meaning it vouches for a site’s identity. It’s free, and for years it has been the most widely used CA in the world, because it turned issuing certificates into an automatic operation rather than a manual purchase.
The two features being announced had been in limited testing for months. As of 15 January 2026 they’ve moved to general availability, meaning they’re open to anyone:
- Short-lived certificates, valid for 160 hours, just over six days.
- Certificates for IP addresses, both IPv4 and IPv6.
Both remain optional. The standard Let’s Encrypt certificate still lasts 90 days: if you do nothing, you’ll notice no difference. If you want the short-lived certificates or the IP ones, you have to ask for them explicitly.
Six days instead of ninety
Getting a short-lived certificate takes more than simply asking for one: the program that talks to the authority has to be able to name a profile, a kind of certificate template. The profile is called shortlived. It’s identical to the one normally used for websites, with a single difference: the certificate lasts about six days instead of three months.
That very short lifetime isn’t arbitrary. There’s an industry rule, the Baseline Requirements, which defines a separate category, short-lived certificates. A certificate that falls into this category gets a privilege: it doesn’t have to carry any revocation information. To see why that’s an advantage, we need to step back and explain what revocation is.
Why so short: the revocation problem
Every certificate is tied to a private key, a secret file that must stay on the server and never leave it. If that key is stolen - through an attack, a misconfiguration, a backup ending up in the wrong place - whoever holds it can impersonate the legitimate site for as long as the certificate stays valid. This interval is called the window of compromise: the longer the certificate, the longer a theft can do damage without anyone noticing.
In theory there’s a remedy: revocation, declaring a certificate invalid before its natural expiry. In practice revocation works poorly. Browsers don’t always check whether a certificate has been revoked, and the mechanisms meant to warn them are slow or unreliable. The result is that, even after a revocation, many visitors keep trusting a certificate they should no longer accept.
Short-lived certificates sidestep the problem at its root. If a certificate lasts six days, the window of compromise is six days at most: after that, it expires on its own. There’s no need to revoke it, because it disappears quickly anyway. It’s a less elegant but more solid way to reach the same result. It’s also why Let’s Encrypt has said it plans to bring the standard lifetime down from today’s 90 days to 45 over the coming years, the same industry-wide shift set out by the CA/Browser Forum’s 47-day target: the direction is to shrink the time in which a mistake can do harm.
The end of OCSP
This choice is tied to a change that happened a few months earlier. For years the main way to check whether a certificate had been revoked was called OCSP (Online Certificate Status Protocol): on each visit, software could ask the authority in real time, “is this certificate still valid?”.
On 6 August 2025 Let’s Encrypt switched off its OCSP service. There were two reasons. The first is privacy: every OCSP query revealed to the authority which site a person was visiting, and from which address. The second is scale: at its peak the service handled around 340 billion requests a month, an enormous infrastructure to maintain. In place of OCSP, one mechanism remains, CRLs (Certificate Revocation Lists), that is, lists of revoked certificates published periodically.
In a world where real-time checking no longer exists, short-lived certificates make even more sense: they don’t need to be revoked, so they don’t depend on a revocation system that has deliberately been made lighter.
Certificates for an IP address
The second new feature solves a different problem. Usually a certificate covers a domain name, for example example.com. But not everything has a domain: some services are reachable only through their numeric address, such as 203.0.113.10 or an IPv6 address. Until now, for those cases, a publicly trusted certificate simply wasn’t available, leaving only self-issued certificates, which browsers flag as untrusted.
Now Let’s Encrypt can issue certificates that cover an IP address directly, both IPv4 and IPv6. This protects connections to services that have no domain name: infrastructure endpoints, network appliances, technical environments where the numeric address is all there is.
There are two constraints, both stemming from the nature of IP addresses. First: a certificate for an IP address must be short-lived, so it goes through the shortlived profile. The reason is that an IP address changes hands far more often than a domain, and checking it frequently matters to keep it from ending up with someone who shouldn’t have it. Second: to prove control of the address you can use only two verification methods, one based on an HTTP response and one based on the TLS connection itself. The DNS-based method, handy for domains, can’t be used here, because an IP address has no DNS records to edit.
What you need to use them
The practical requirement is just one: the program that manages your certificates - the ACME client, where ACME is the standard protocol a server uses to obtain and renew certificates on its own - has to be able to request a profile. That’s a recent feature, so it’s worth running an up-to-date version of your client. The most common clients, including certbot, already have dedicated instructions for selecting the shortlived profile.
The rest is automation, and that’s the important part. A certificate that lasts six days has to be renewed every few days: by hand it’s unthinkable. But for an automated system, renewing every day or every three days is no more effort than renewing every two months. If you already leave renewals to an ACME client that runs on its own, you have almost nothing to change; if you still renew by hand, with these certificates you simply can’t.
In short
Let’s Encrypt has opened two optional features to everyone: certificates valid for just over six days and certificates for IP addresses. The first shrink to a minimum the time in which a compromised certificate can do harm, in a world where revocation - and the old OCSP service, now switched off - offered no reliable guarantees. The second bring publicly trusted certificates to places where there’s no domain. The common thread is the same throughout: shorter certificates, more frequent checks, and solid automation as the one condition for keeping up, while over the same period post-quantum key exchange turned on by default in Chrome is raising the bar for TLS security more broadly.
