Certificate experts get caught by expiry too — nii.ac.jp, and why these outages are about to get more common

In mid-July 2026, the website of Japan’s National Institute of Informatics (NII), nii.ac.jp, was reported to be temporarily inaccessible because its TLS certificate had expired. Browsers show a full-page warning for expired certificates, so for most visitors the site was effectively down.

NII runs UPKI, the certificate issuance service used by universities and research institutions across Japan, so it’s one of the organizations most experienced with certificate operations in the country. If it can happen there, certificate expiry isn’t a carefulness problem. It’s a structural one.

The usual failure patterns

Certificate expiry takes down large services regularly, regardless of engineering strength. The same patterns repeat:

Renewal notices don’t reach anyone. CAs email whoever obtained the certificate, often years ago. People move on, and shared mailboxes go unread
One certificate falls outside the automation. The main sites renew via ACME, but an old subdomain or a certificate installed directly on a load balancer is still manual, and that’s where the incident happens
Renewal isn’t deployment. The renewal job logs success while the certificate actually served to users is still the old one. If monitoring only looks at the files on the server, nobody notices

Renewals are about to become eight times more frequent

The CA/Browser Forum has scheduled a staged reduction of maximum certificate validity:

Period	Maximum validity
Now (until March 14, 2026)	398 days
From March 15, 2026	200 days
From March 15, 2027	100 days
From March 15, 2029	47 days

A once-a-year renewal becomes roughly eight per year by 2029, which multiplies the chances of hitting the patterns above. The full schedule, including the domain-validation reuse periods that most summaries skip, is in a separate post. UPKI itself has started offering ACME-based automatic renewal in response, and the industry’s direction is clearly automation. Automation alone doesn’t close the gap, though.

Automation still needs independent monitoring

ACME doesn’t eliminate incidents because of the third pattern above: a renewal that succeeds isn’t the same thing as the right certificate reaching users. DNS-01 challenges fail, rate limits hit, deployment scripts break, CDN certificate rotation gets missed. When part of the pipeline fails quietly, something outside the pipeline has to notice.

Independent monitoring needs three properties:

External: check the certificate actually delivered in the TLS handshake, not the file on disk
Staged: escalating notifications at 30, 14, 7, and 1 days out, designed on the assumption that any single email will be missed
Team-addressed: alerts go to a Slack channel or a team address, not to whoever set things up years ago

Where Certly fits

Certly is that external monitor. It checks the certificate your servers actually serve and sends staged alerts to email, Slack, Discord, or webhooks. It also watches domain expiry, registry status, and DNS/DNSSEC on the same dashboard (the domain side of this story is covered in our gigafile.nu post).

The free checker shows any domain’s certificate expiry without signup. If you can’t say offhand how many days your own certificate has left, that’s a reasonable sign you need monitoring.

Takeaways

Expiry happens to the most experienced operators. It’s a structural problem, not an attention problem
Certificate validity is shrinking from 398 to 47 days on a fixed schedule. Renewal events multiply, and so do the chances to fail
The fix is automated renewal plus independent external monitoring. Either one alone falls short

Sources

The report on X (h_okumura) (Japanese)
UPKI certificate issuance service (NII) (Japanese)
Kyoto University: UPKI certificate validity shortening and ACME auto-renewal
CA/Browser Forum Ballot SC-081 (staged reduction of certificate validity)