Let's Encrypt Is Going to 64 Days. I Checked 520 .id Sites. 3 in 4 go.id Sites Still Run Long-Lived Certificates

On 10 February 2027, Let’s Encrypt switches its default certificate lifetime from 90 days to 64. Five weeks later, on 15 March 2027, the CA/Browser Forum cap for every publicly trusted TLS certificate drops from 200 days to 100. I wanted to know how Indonesian sites are placed for that, so on 25 October 2026 I scanned 520 popular .id domains. The Let’s Encrypt users look fine. The problem is elsewhere: of the 81 go.id sites that answered, 61 (75%) serve a certificate valid for 198 days or more, the kind people buy once and install by hand.

TL;DR (for non-technical readers)

• Website certificates are getting shorter lives. Let’s Encrypt goes to 64 days in February 2027, and from March 2027 no public certificate may last longer than 100 days.
• I checked 520 popular Indonesian .id domains on 25 October 2026. 477 answered over HTTPS, and 270 of those (56.6%) already use certificates of 90 days or less, which almost always means renewal is automated.
• 190 sites (39.8%) still use long-lived certificates of 198 days or more. In government sites (go.id) it is 3 in 4.
• Sites that renew by hand will have to do it far more often from 2027. The fix is automation (ACME), plus monitoring that tells you before a certificate expires.

ICANN87 took place in Bali last week, hosted by PANDI, the first ICANN public meeting held in Indonesia. It felt like a good week to measure something concrete about .id.

What is changing, and when

From the Let’s Encrypt announcement (7 October 2026):

• 10 February 2027: all subscribers move to 64-day certificates by default. The last 90-day certificate expires on 11 May 2027.
• Optional profiles with 45-day and 6-day lifetimes are available for those who want them.
• Authorization reuse drops from 30 days to 10 days on the same date. In 2028 it shrinks to seven hours, and Let’s Encrypt describes this step as groundwork for a 45-day default in 2028.
• The staging environment has issued 64-day certificates since 14 October 2026, so you can test now.

From the CA/Browser Forum Baseline Requirements (sections 6.3.2 and 4.2.1, introduced by ballot SC-081, adopted 11 April 2025):

• Since 15 March 2026, the maximum validity is 200 days.
• From 15 March 2027, it is 100 days.
• From 15 March 2029, it is 47 days, and domain validation data can be reused for only 10 days.

The Let’s Encrypt change affects its own users. The CA/B Forum change affects everyone, including sites that buy from DigiCert or Sectigo.

Method

The Tranco list GQ32K (generated 24 October 2026) contains 4,814 .id domains. I took the top-ranked domains in each second level: 100 plain .id, 90 each of co.id, ac.id and go.id, 40 sch.id, 30 each of or.id, web.id and my.id, and 20 biz.id. That is 520 domains.

For each domain, a Python script:

1. Opened a TLS connection to port 443 with SNI, 5-second timeout, 50 threads. Apex first, then www. if the apex did not answer.
2. Verified chain and hostname with ssl.create_default_context(). If that failed, it reconnected without verification to read the certificate anyway.
3. Recorded issuer, notBefore, notAfter, validity length and expiry.
4. Queried CAA and DS for the domain through 1.1.1.1 and 8.8.8.8 with dnspython.

The scan started at 09:21 WIB on 25 October 2026 and took under a minute. The core of it:

ctx = ssl.create_default_context()
with socket.create_connection((host, 443), timeout=5) as s:
    with ctx.wrap_socket(s, server_hostname=host) as t:
        der = t.getpeercert(binary_form=True)
cert = x509.load_der_x509_certificate(der)
days = (cert.not_valid_after_utc - cert.not_valid_before_utc).days

I used validity length as a proxy for how a certificate is renewed. 90 days or less almost always means ACME automation. For the long end, I had planned to use 200 days, but the data changed my mind: since the 200-day cap, commercial CAs issue 198 or 199 days. In this sample, 87 certificates were 199 days long, and every certificate longer than 200 days (87 of them) was issued before 15 March 2026. So “long-lived” here means 198 days or more.

Results

Of 520 domains, 477 (91.7%) answered TLS. 453 of those (95.0%) passed chain and hostname verification.

Group	Answered TLS	90 days or less	198 days or more
go.id	81	14 (17%)	61 (75%)
co.id	86	34 (40%)	47 (55%)
ac.id	87	49 (56%)	36 (41%)
.id	94	57 (61%)	33 (35%)
or.id	28	20 (71%)	8 (29%)
web.id	21	18 (86%)	3 (14%)
sch.id	40	38 (95%)	2 (5%)
my.id	24	24 (100%)	0
biz.id	16	16 (100%)	0

Across all 477: 270 (56.6%) were 90 days or less, 17 (3.6%) were in between, and 190 (39.8%) were 198 days or more. Eleven of the long-lived ones came from Amazon, whose managed certificates renew themselves. Without those, 179 (37.5%) are long-lived and likely renewed by hand.

By issuer: Google Trust Services 146 (30.6%), Let’s Encrypt 118 (24.7%), DigiCert 96 (20.1%), Sectigo 71 (14.9%), GlobalSign 18 (3.8%), ZeroSSL 2 (0.4%) and others 26 (5.5%). I found no certificate from an Indonesian CA. All 190 long-lived certificates came from DigiCert (87), Sectigo (66), GlobalSign (14) and others (23).

Three things stood out.

1. Let’s Encrypt users already renew early. All 118 Let’s Encrypt certificates were 90-day certificates. Of the 117 that were still valid, the median age was 30.5 days and only 1 was older than 60 days. Renewals here happen well before day 64. That does not prove every client computes renewal from the lifetime, but it is a good sign.

2. go.id is where the work is. Only 8 of 81 go.id sites (10%) use Let’s Encrypt, and 13 (16%) use any of the three ACME-first CAs I counted (Let’s Encrypt, ZeroSSL, Google Trust Services). go.id also had the lowest verification rate among the large groups, 72 of 81 (89%), with 3 sites serving an expired certificate. Compare sch.id, where 38 of 40 are on certificates of 90 days or less.

3. Manual installs already show cracks. 24 sites (5.0%) failed verification: 9 with an incomplete chain, 6 expired, 5 with a hostname mismatch, and 4 self-signed. 17 of those 24 were on long-lived certificates, and 7 of the 9 incomplete chains were on long-lived certificates. A missing intermediate is a typical result of someone pasting a certificate into a server by hand.

On the DNS side, 62 of 520 domains (11.9%) publish CAA, and 55 of those 62 allow letsencrypt.org. 5 publish an issue tag that does not include it, so a switch to Let’s Encrypt would fail there until CAA is updated. 48 domains (9.2%) have a DS record, meaning a DNSSEC-signed delegation. go.id leads here with 19 (21%).

What breaks, and why

Manual renewals. A team that buys a 199-day certificate and installs it by hand does that job rarely today, and rare jobs are the ones nobody remembers how to do. Of the 190 long-lived certificates, 144 expire before 15 March 2027, so their owners can buy one more 200-day certificate. The one after that is capped at 100 days, and in 2029 at 47. A manual process that works twice a year will not survive that.

Hardcoded renewal schedules. Let’s Encrypt calls out cron jobs with numbers like 83, 80 or 60 days. A cron that renews at day 60 leaves 4 days of margin on a 64-day certificate. One failed run and the site expires. Renewal should happen at about two thirds of the lifetime, or better, when the CA says so through ACME Renewal Information (ARI).

Pinned certificates. Apps and API clients that pin a leaf certificate or its key break whenever the key changes, and more renewals mean more chances. A TLS scan cannot see this, so check what your apps pin.

Authorization reuse and DNS-01. Today, a Let’s Encrypt validation stays good for 30 days. From 10 February 2027 it is 10 days. If you validate once with a TXT record pasted by hand (certbot --manual) and expect renewals to ride on it, they will not. DNS-01 needs to be automated through your DNS provider’s API, or you need to switch to HTTP-01 where that is possible.

Checklist

1. Find every certificate and how it renews. For each host, write down who issued it, its lifetime, and what renews it. If the answer is “a person”, that is your list.
2. certbot: run certbot renew --dry-run. Dry runs use staging, which now issues 64-day certificates. Check systemctl list-timers | grep certbot or your cron, and look for renew_before_expiry set in /etc/letsencrypt/renewal/*.conf.
3. acme.sh: run acme.sh --list and check the renew date against the new lifetime. Search crontabs and scripts for fixed day counts: grep -rnE '\b(60|80|83)\b' /etc/cron* ~/.acme.sh/*.conf.
4. Caddy: it manages renewal itself. Keep it updated and alert on renewal errors in its logs.
5. cert-manager: check kubectl get certificate -A and kubectl describe certificate. A fixed renewBefore of 60 days on a 64-day certificate makes it renew almost constantly. Leave the default or use a percentage.
6. Commercial certificates: ask your CA whether it offers ACME for paid certificates. If you keep buying by hand, put the next two renewal dates in a shared calendar.
7. DNS-01: make sure TXT records are created by API, not by hand. If you publish CAA, confirm it lists the CA you will actually use.
8. Monitor expiry from outside. A simple check that alerts at 14 days:

echo | openssl s_client -connect example.go.id:443 -servername example.go.id 2>/dev/null \
  | openssl x509 -noout -enddate -checkend 1209600 || echo "expires within 14 days"

9. Serve the full chain. Use fullchain.pem, not cert.pem. 7 of the 9 incomplete chains in this scan were on long-lived certificates.

Caveats

• Sample bias. These are the top-ranked .id domains in Tranco, so they skew towards popular, better-funded sites. Smaller groups are small: biz.id had 16 TLS hosts.
• Validity is a proxy. A 90-day certificate can be renewed by hand, and a long-lived one can be automated, as Amazon’s are.
• Apex and www only. Subdomains, mail servers and internal services were not scanned.
• Verification is Python’s, not a browser’s. Python does not fetch missing intermediates, so some of the 9 incomplete chains may still load in a browser. curl, apps and APIs will fail the same way Python did.
• One point in time, one network. 25 October 2026, from Batam. CAA was checked only at the registrable domain, without climbing to the parent.

I am publishing aggregates only, not per-site results.

Closing

The .id sites already on Let’s Encrypt look ready for 64 days. The 190 sites on long-lived certificates are the real question, and most of them have one more 200-day purchase before the 100-day cap arrives.

If you run a go.id or ac.id site: what is actually stopping you from automating renewal, the tooling, procurement rules, or something else?

Versi bahasa Indonesia: https://www.kielltampubolon.id/writing/lets-encrypt-pindah-ke-64-hari-saya-cek-520-situs-id/