If you bought a one year certificate for a domain this spring, the certificate you installed lasts 199 days, and the reissue for the rest of the year is yours to install. The rules for publicly trusted certificates changed on 15 March 2026, and DigiCert and Sectigo moved before that date: DigiCert has issued nothing longer than 199 days since 24 February, Sectigo since 12 March. A DigiCert certificate issued on 24 February ran out at the end of 10 September. One issued on 15 March for the full 200 days runs out at the end of September.

The 200 days are the first step of a schedule written into the Baseline Requirements, the rules every publicly trusted certificate authority follows. Version 2.3.0, dated 7 September 2026:

Certificate issued Longest allowed Domain check reusable for
before 15 March 2026 398 days 398 days
from 15 March 2026 200 days 200 days
from 15 March 2027 100 days 100 days
from 15 March 2029 47 days 10 days

The authorities are not waiting for the dates. DigiCert’s own table puts its next step, 99 days, in early 2027. Let’s Encrypt runs further ahead: from 10 February 2027 its default certificates last 64 days, from 16 February 2028 they last 45, and the time a domain check stays valid drops to 10 days and then to 7 hours.

The right column is the one that hurts a manual process. A certificate ordered by hand starts with proving control of the domain, by a DNS record, a file or an email, unless the last proof is recent enough. From March 2029 recent enough means ten days, so for a 47 day certificate the proof is part of every order. A domain whose certificate a person renews needs that person about twice a year now, about four times a year from 2027 and about eight times from 2029.

On a domain that only redirects, nobody has to do this at all. The rest of this article finds the domains where somebody still does. If you are still choosing how to redirect in the first place, every way to redirect on Cloudflare compares the options.

A redirect domain should have no certificate you renew

A parked domain, or one that only forwards, needs a certificate for a single reason: a visitor who types https:// has to finish the TLS handshake before your 301 can be sent. Nothing else on that domain uses it. Put the record behind Cloudflare’s proxy and the certificate becomes Cloudflare’s job. The documentation, updated 16 April 2026:

Universal certificates have a 90-day validity period. The auto renewal period starts 30 days before expiration.

Universal SSL is included on every plan, Free too. Its 90 days are already inside the 2026 and 2027 caps. They are longer than the 47 days of 2029, and closing that gap is not your job either:

For Universal certificates, Cloudflare controls the validity periods and certificate authorities (CAs), making sure that renewal always occur.

The setup that removes the question entirely is the one from the portfolio runbook: a proxied A record pointing at 192.0.2.1, an address reserved for documentation that no server answers on, and a redirect rule at the edge. There is no server behind the domain, so there is no server certificate. The only certificate in the path is the one Cloudflare renews.

Sort your domains by who renews them

You do not need an inventory to find the domains that do not fit that setup. The certificate each domain serves carries its own start and end dates, and the distance between them tells you a lot about how it got there. The script below needs only openssl and GNU date, the same pair the audit script uses for its certificate column. On macOS use date -j -f '%b %d %T %Y %Z'.

#!/usr/bin/env bash
set -uo pipefail

printf '%-34s %-24s %-9s %s\n' DOMAIN ISSUER LIFETIME LEFT

while read -r domain; do
  [ -z "$domain" ] && continue

  cert=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
         | openssl x509 -noout -issuer -startdate -enddate 2>/dev/null)
  if [ -z "$cert" ]; then
    printf '%-34s %s\n' "$domain" "no certificate"
    continue
  fi

  issuer=$(printf '%s\n' "$cert" | sed -n 's/^issuer=.*O *= *\([^,]*\).*/\1/p')
  from=$(date -d "$(printf '%s\n' "$cert" | sed -n 's/^notBefore=//p')" +%s)
  until=$(date -d "$(printf '%s\n' "$cert" | sed -n 's/^notAfter=//p')" +%s)

  life=$(( (until - from + 43200) / 86400 ))
  left=$(( (until - $(date +%s)) / 86400 ))

  printf '%-34s %-24.24s %-9s %s\n' "$domain" "${issuer:--}" "${life}d" "${left}d"
done < domains.txt

The lifetime is rounded to the nearest day, because authorities pad both ends by hours. A run on 19 September 2026 against this site, our Russian host, and a few large sites for contrast:

DOMAIN                             ISSUER                   LIFETIME  LEFT
301.sh                             Google Trust Services    90d       89d
www.301.sh                         Google Trust Services    90d       89d
ru.301.sh                          Let's Encrypt            90d       72d
www.paypal.com                     DigiCert Inc             199d      176d
www.salesforce.com                 DigiCert Inc             199d      13d
www.zoom.us                        DigiCert Inc             366d      101d
www.adobe.com                      DigiCert Inc             365d      107d
this-domain-does-not-exist-9f3.com no certificate

The LIFETIME column is the one to sort by.

90 days or less. A machine issued this and a machine will replace it. Behind Cloudflare’s proxy you should see 90 days from Google Trust Services, Let’s Encrypt or SSL.com; 301.sh was reissued a few hours before the run. A short lifetime does not tell you whose machine it is. ru.301.sh is not behind Cloudflare at all: it is served by GitHub Pages, and GitHub renews its Let’s Encrypt certificate.

199 or 200 days. The longest certificate a commercial authority issues under the new rules, the kind that comes with an order. The www.salesforce.com certificate was issued on 18 March and has 13 days left. Whoever renews it will do it again within 200 days, and from 15 March 2027 within 100.

365 days or more. Issued before 15 March 2026, and among the last of their kind. The next certificate for that domain lasts 200 days at most, or 100 if it is ordered after 15 March 2027. On these domains the renewal date moves closer and nothing announces it.

No certificate. The handshake never happened: the name does not resolve, or nothing answers on port 443. Visitors typing https:// get an error before any redirect can run.

On a portfolio where every domain is meant to sit behind Cloudflare, a lifetime over 90 days means Cloudflare is not the one serving that domain. On Business and Enterprise it can be a custom certificate you uploaded, which Cloudflare does not renew either. Everywhere else it is a record that was never proxied, or a domain whose nameservers never moved.

no

yes

no

yes

no, redirect only

yes

no

yes

Zone active
on Cloudflare?

Whoever serves it today:
Cloudflare issues nothing
until the nameservers change

Record proxied?

You do:
automate it,
or proxy the record

Does a server
answer behind it?

Cloudflare:
nothing to do

SSL mode
Full (Strict)?

Cloudflare for visitors;
the server certificate
is not checked

Cloudflare for visitors,
you for the server:
ACME or Origin CA

Who renews the certificate on a domain

The certificate the script does not see

Behind the proxy, the script reads Cloudflare’s certificate, the one visitors get. When Cloudflare forwards the request to your server, there is a second certificate on that connection. In SSL/TLS mode Full (Strict), Cloudflare checks it, and on the day it expires visitors get a 526 instead of your page or your redirect. No browser ever sees this certificate, so nothing warns you before that day.

To read it, connect to the server’s address directly and name the domain:

echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate

There are three ways to take this certificate off your calendar.

  1. Automate it on the server. Any ACME client renews on its own. For the move to 64 days in February 2027, the advice from Let’s Encrypt is one sentence: “you should verify that your automation is compatible with certificates that have shorter validity periods.”

  2. Use a Cloudflare Origin CA certificate. It is free on every plan and trusted by Cloudflare and nobody else, so the public schedule does not apply to it: the API offers validity from 7 days up to 5,475, which is 15 years. Cloudflare’s own page names two conditions. The first:

    Cloudflare does not currently send expiration notifications for origin CA certificates.

    The second: it only works while the record stays proxied.

    Site visitors may see untrusted certificate errors if you pause Cloudflare or disable proxying on subdomains that use Cloudflare origin CA certificates.

    Write the expiry date down somewhere you will look, because Cloudflare will not remind you.

  3. Take the server out of the path. If the server exists only to send a redirect, move the redirect to Cloudflare and point the record at 192.0.2.1 as above. The second certificate goes away with the server.

Where this breaks

Universal SSL has conditions. On a portfolio, each of them is a domain somewhere in the list.

The record is not proxied. A record set to DNS only gets no certificate from Cloudflare:

Cloudflare can only serve an SSL/TLS certificate for a DNS record when you set the record’s proxy status to Proxied. If you do not do this, the origin server your record points to will be responsible for supporting SSL/TLS connections.

The zone is still pending. Universal SSL is issued to domains added to and activated on Cloudflare. Until the nameservers change at the registrar there is no certificate at all, and adding many zones at once runs into a limit of its own.

The name is two levels deep. On a full setup the certificate covers example.com and www.example.com, but not www.shop.example.com. The fix is Advanced Certificate Manager with Total TLS, listed at $10 a month on Cloudflare’s plans page on 19 September 2026.

Cloudflare will not certify the name. From the limitations page:

Some domains are not eligible for Universal SSL if they contain words that conflict with trademarked domains.

A portfolio of names close to brands will find some of its domains here. Cloudflare’s way out is a paid advanced certificate, or a custom one on Business and Enterprise.

A CAA record elsewhere in the chain. When you add CAA records to a zone with Universal SSL, Cloudflare adds the ones its authorities need. It cannot change the records of a zone you point to:

If your hostname CNAMEs to a domain whose zone has restrictive CAA records, those records take precedence — even if your own domain has no CAA records.

When 301.st is worth it

For a few domains you do not need us. Proxy the records, move the redirects to the edge, and run the script once a quarter. It takes a minute.

With hundreds of domains the setup has to happen at the moment a domain is added. 301.st builds it for every domain it adds: the apex gets a proxied A record at 192.0.2.1 and the redirect runs at the edge, so those domains have no server certificate at all. It also reads the certificate state of every zone from Cloudflare each day and shows which domains have a certificate that is pending or failing, such as one stuck on validation because of a CAA record two hops away.

It does not look at certificates installed on your own servers, and a record someone later switches to DNS only is not a certificate error in Cloudflare’s eyes. The record shows up in the script’s LIFETIME column, the server certificate in the openssl line from the previous section. Put both in a cron job.