← Blog

証明書運用のプロでも期限切れは起こる — nii.ac.jp の事例と、これから事故が増える構造的な理由

2026-07-18

Also available in English: Read in English →

2026年7月中旬、国立情報学研究所（NII）のサイト nii.ac.jp が、証明書の期限切れで一時アクセスできなくなっているとSNSで報告されました。最近のブラウザは期限切れ証明書のサイトに全画面の警告を出すため、訪問者にとっては実質的にサイトが止まっているのと同じ状態になります。

NIIは、大学・研究機関向けの電子証明書発行サービス（UPKI）を運営している機関です。つまり、日本で証明書運用に最も詳しい組織のひとつでもこれが起きたことになります。この記事は誰かの失敗を責めるためのものではなく、「詳しい組織でも起きる」という事実をもとに、証明書の期限切れが個人の注意力ではなく仕組みの問題であることを整理するのが目的です。

期限切れが起こる典型パターン

証明書の期限切れによる障害は、規模や技術力に関係なく繰り返し起きています。パターンはだいたい決まっています。

  • 更新通知が人に届かない。認証局からの通知は証明書を取得した当時の担当者宛てに届くため、異動や退職、読まれなくなった共有メールボックスで迷子になる
  • 一部の証明書が自動化から漏れる。主要なサイトはACMEで自動更新できていても、古いサブドメインやロードバランサに直接入れた証明書が手動運用のまま残っていて、事故はそこで起きる
  • 更新とデプロイは別物。更新ジョブは成功ログを出しているのに、実際に配信されている証明書は古いままというケース。監視がサーバー内の証明書ファイルしか見ていないと気づけない

有効期間の短縮で、更新は年8回になる

CA/Browser Forum の決定で、証明書の最大有効期間は段階的に短くなることが決まっています。

時期最大有効期間
現在（〜2026年3月14日）398日
2026年3月15日〜200日
2027年3月15日〜100日
2029年3月15日〜47日

年1回だった更新イベントは、2029年には年8回程度になります。更新の回数が増えれば、上のパターンを踏む機会も同じだけ増えます。スケジュールの全体像は、見落とされがちなドメイン検証の再利用期間の短縮も含めて別の記事にまとめました。UPKI もこれに対応してACMEによる自動更新サービスの提供を始めており、業界の方向性は自動化で一致しています。ただ、自動化だけでは足りません。

更新は自動化し、監視は独立させる

ACMEを導入しても事故がなくならないのは、3つ目のパターンのとおり、更新の成功と実際に配信されている証明書が別物だからです。DNS-01チャレンジの失敗、レート制限、デプロイスクリプトの不具合、CDN側の証明書切り替え漏れなど、パイプラインのどこかが静かに壊れることがあります。それに気づくには、パイプラインの外側からの監視が必要です。

監視側に必要な条件は次の3つだと考えています。

  • 外形監視であること。サーバー内のファイルではなく、TLSハンドシェイクで実際に配信されている証明書を見る
  • 通知が段階的であること。30日前・14日前・7日前・1日前とエスカレーションさせる。1通だけのメールは読まれない前提で設計する
  • 通知先が個人でないこと。Slackチャンネルやチームのメールアドレスに届くようにして、「当時の担当者にしか届かない」状態を避ける

Certly の場合

Certly はこの独立した外形監視を提供しています。サーバーが実際に配信している証明書を外からチェックし、期限の30/14/7/1日前にメール・Slack・Discord・Webhookへ通知します。証明書のほかに、ドメインの有効期限・レジストリステータス・DNS/DNSSECも同じダッシュボードで監視します（ドメイン側の話は gigafile.nu の解説記事に書きました）。

登録不要の無料チェッカーで証明書の残り日数を確認できます。自分のドメインの残り日数をすぐに答えられないようであれば、監視を入れる価値はあると思います。

まとめ

  • 証明書の期限切れは、最も詳しい組織でも起きる。注意力ではなく仕組みの問題
  • 有効期間は398日から47日まで段階的に短縮され、更新イベントは年8回になる。事故の機会も同じだけ増える
  • 対策は更新の自動化と独立した外形監視の両方。どちらか片方では足りない

関連記事: gigafile.nu はなぜ突然消えたのか — ドメインは「期限切れ」以外でも止まる

参考リンク