ある朝、クライアントのサイトが「開けない」と連絡が来る
Web制作の仕事を10年以上続けていると、何度か同じ種類の連絡を受けます。
「サイトが表示されなくなった」「メールも届かなくなった」。
調べてみると、サーバーが落ちているわけでも、改ざんされたわけでもない。原因はドメインの更新忘れでした。レジストラからの更新案内メールが、担当者の異動で誰にも読まれないアドレスに届いていた、というパターンです。
私自身、数十社のサイトを保守する立場でこの連絡を受けたことがあり、「気をつけましょう」で済む話ではないと痛感しました。そして2026年からは、もうひとつの期限がこの問題を加速させます。SSL証明書の有効期間が、段階的に47日まで短くなるからです。
SSL証明書の有効期間が「最長47日」になる
ブラウザベンダーと認証局で構成されるCA/Browser Forumで、TLS証明書の最大有効期間を短縮する決定がされています。スケジュールは次のとおりです。
- 2026年3月15日以降：最長200日
- 2027年3月15日以降：最長100日
- 2029年3月15日以降：最長47日
これまで「1年に1回、更新日を手帳に書いておけば済んでいた」運用が、最終的には1か月半ごとの更新になります。Let’s Encryptのように自動更新が前提の証明書なら影響はほぼありませんが、年1回の手動更新で回していたサイトは、仕組みを変えないと必ずどこかで切れます。
正直に言うと、制作会社の保守契約の多くは「人が覚えておく」ことで成り立っていました。それが成り立たなくなる、というのが今回の変化の本質だと思っています。
更新漏れが起きたとき、実際に何が止まるか
ドメインとSSLでは、切れたときの症状が違います。
ドメインが切れた場合
- サイトが表示されない（DNSが引けなくなる）
- そのドメインのメールが送受信できなくなる
- 一定期間を過ぎると第三者が取得できる状態になる
メールが止まるのが一番痛いです。問い合わせも社内連絡も届かなくなるので、ビジネスへの影響がサイト停止より大きいことも珍しくありません。
SSL証明書が切れた場合
- ブラウザに「この接続ではプライバシーが保護されません」という警告が全面に出る
- フォーム送信をためらう訪問者が増える
- 連携している外部サービス（決済・API）が通信を拒否することがある
サイト自体は生きているのに、見た目は「危険なサイト」になります。
私が現場でやっている管理方法
対策はシンプルですが、「誰が・いつ・どこで気づくか」を人の記憶から外すことが肝心です。
1. 期限を一覧にして、更新案内メールの宛先を見直す
サイトごとに「ドメインの期限・レジストラ・SSLの期限・発行元・自動更新の有無」をスプレッドシートにまとめます。地味ですが、これがないと始まりません。
あわせて、レジストラや認証局からの通知メールが個人のアドレスではなく、複数人が見るグループアドレスに届くように変更します。更新忘れの原因の多くは、通知が「誰も見ていない受信箱」に落ちていることです。
2. 自動更新に寄せられるものは寄せる
ドメインはレジストラの自動更新をオンにし、支払い方法の有効期限も一緒に確認します。クレジットカードの期限切れで自動更新が失敗する、というのもよくある落とし穴です。
SSLは、レンタルサーバーの無料SSL（Let’s Encrypt）が使えるなら、それが一番確実です。有償証明書が必要な案件でも、ACME対応の自動更新ができるかを選定基準に入れるようになりました。
3. 外側から期限を監視する
人が覚えないために、仕組みに覚えさせます。私はGoogle Apps Scriptで、管理サイトのSSL期限とドメイン期限を週1回チェックして、残り30日を切ったらSlackに通知する簡単なスクリプトを回しています。
既製の監視サービスでも構いません。大事なのは「期限が近いことを、管理者の記憶とは別の経路で知らせてくれる仕組み」があることです。
4. 切れたときの手順を先に書いておく
それでも切れることはあります。そのときに慌てないよう、「レジストラの復旧猶予期間」「連絡先」「DNSの再設定手順」をあらかじめメモしておくと、復旧までの時間が大きく変わります。
まとめ
- ドメインやSSLの更新漏れは「うっかり」ではなく、通知の宛先と運用の問題
- SSL証明書は2026年から有効期間が段階的に短縮され、最終的に47日になる
- 年1回の手動更新は破綻する前提で、自動更新と外部監視に切り替える
- 期限一覧・通知先の見直し・監視・復旧手順の4点セットで備える
47日化はまだ先ですが、200日化はすでに始まっています。「次の更新のときに自動化を考えよう」ではなく、今の更新のタイミングで仕組みを変えておくのがおすすめです。