# Let's Encrypt six-day and IP address certificates available

> Since 2026-01-15 Let's Encrypt issues six-day (160-hour) certificates and IPv4/IPv6 address certificates via the opt-in shortlived profile.

Source: https://ssl.sh/news/lets-encrypt-six-day-and-ip-certificates/
Last updated: 2026-11-10

Let's Encrypt made two long-requested features generally available on 15 January 2026: certificates valid for six days (160 hours), and certificates for IP addresses instead of domain names, for both IPv4 and IPv6. Both are opt-in through the shortlived [ACME profile](https://ssl.sh/glossary/acme-profile/); clients that do not ask for it keep receiving default certificates.

## What happened

Any subscriber can now request the shortlived profile. Let's Encrypt introduced ACME profiles on 9 January 2025: a profile is a named set of issuance options that a client selects when it places an order, and Let's Encrypt's profiles include classic (the default), tlsserver and shortlived.

At the protocol level, an order for a short-lived certificate covering an IP address looks like this:

```json
{
  "identifiers": [
    { "type": "ip", "value": "203.0.113.10" }
  ],
  "profile": "shortlived"
}
```

The `ip` identifier type is defined in RFC 8738. Because an IP address has no DNS zone, it can be validated only with [HTTP-01](https://ssl.sh/glossary/http-01/) or [TLS-ALPN-01](https://ssl.sh/glossary/tls-alpn-01/), never [DNS-01](https://ssl.sh/glossary/dns-01/). IPv6 addresses such as `2001:db8::10` work the same way.

[Short-lived certificates](https://ssl.sh/glossary/short-lived-certificate/) also change the role of [revocation](https://ssl.sh/glossary/revocation/). Under CA/Browser Forum rules, certificates valid for 7 days or less do not need to carry OCSP or CRL information: if a key leaks, the certificate stops working within days anyway.

## Who is affected

The features are most useful for:

- services reached by IP address rather than a name, such as DNS-over-HTTPS resolvers, device management interfaces, temporary test hosts and some IoT devices, which previously had to use a [self-signed certificate](https://ssl.sh/glossary/self-signed-certificate/) or a [private CA](https://ssl.sh/glossary/private-ca/);
- operators who want to limit the damage of a leaked [private key](https://ssl.sh/glossary/private-key/) without depending on revocation checks.

The trade-off is operational. With a 90-day certificate, a renewal pipeline can be broken for weeks before anyone notices; with a six-day certificate, the same failure becomes an outage within days. IP certificates also tie the certificate to an address, so changing hosting or IP needs a new certificate.

## What you should do

Opt in only where renewal is fully automated and monitored.

- Check that your ACME client can select a profile and, ideally, supports [ARI](https://ssl.sh/glossary/ari/).
- For IP certificates, make sure the address serves port 80 or 443 to validators in different regions.
- After issuance, confirm the subject alternative names and expiry:

```bash
openssl x509 -in cert.pem -noout -ext subjectAltName -enddate
```

The output should list `IP Address:203.0.113.10` and an expiry roughly six days after issuance. The [certificate decoder](https://ssl.sh/tools/certificate-decoder/) shows the same fields in a browser, the [IP address certificate](https://ssl.sh/glossary/ip-address-certificate/) entry covers client support, and the [ACME protocol guide](https://ssl.sh/learn/acme-protocol/) explains orders and challenges.