インフラエンジニアのSSL証明書更新ガイド｜更新漏れでサイトを落とさないための「段取り」の極意

2026年2月18日

インフラエンジニアにとって、もっとも心臓に悪い瞬間の一つ。それは、管理しているサイトを開いたときに「この接続はプライベートではありません」という警告が出ることです。

原因はSSL証明書の期限切れ。たった一つのファイルの更新漏れで、企業の信頼は一瞬で損なわれてしまいます。

実は私も若手の頃、苦い経験をしました。「まだ期限まで数日あるから」と作業を後回しにしていたら、いざ申請した後に証明書が発行されるまで予想以上に時間がかかり、当日ギリギリまで冷や汗を流すことになったのです……。

今日は、そんな私の失敗を教訓に、若手の皆さんに伝えておきたい「絶対にサイトを落とさないための更新術」、そして迫りくる「証明書の短命化」への備えについてお話しします。

この記事の想定読者

この記事を読むことでのメリット

SSL証明書更新の「基本ワークフロー」

サーバーがApacheでもNginxでも、あるいは私の環境のようにIIS（Internet Information Services）であっても、やるべきことの本質は変わりません。

ここが私の最大の反省点です。SSL証明書は、ポチッと押せばすぐ届くものではありません。 特に「新規取得」の場合は、認証局側の審査や確認に時間がかかるケースが多いです。「更新だからすぐ終わるだろう」という思い込みは捨て、余裕を持って動くのが鉄則です。

「自分のPCでは鍵マークが出ているのに、他の人のスマホだと警告が出る」という現象。これは、サーバー証明書と一緒に届く「中間証明書」を入れ忘れているときに起こります。ブラウザによって挙動が変わるため、見落としやすいポイントです。

これは私が手順書に必ず入れる「こだわり」です。証明書を切り替えた直後、確認しても「あれ、期限が変わっていない？」となることがあります。実はこれ、ブラウザ側に古い証明書のキャッシュが残っているだけというパターンが非常に多いのです。

もっちのアドバイス： 更新後の動作確認では、必ず「ブラウザキャッシュのクリア」または「シークレットモードでの確認」を行うよう、手順書に明記しておきましょう。これだけで、不要な混乱を防げます。

ここからは、すべてのインフラエンジニアが直視すべき未来の話です。

セキュリティ向上（暗号強度の維持と鍵盗難時の被害最小化）を目的に、証明書の有効期間は段階的に短縮されることが決定しています。

これまでのように「1年に1回の定例作業」という感覚では、到底追いつかなくなります。

有効期間が47日になれば、手動更新はミスとコストの温床になります。私たちは今、運用のあり方を変えるべき岐路に立っています。

自動更新ツールの導入（不可欠）： Let’s EncryptのようなACMEプロトコルを用いた自動更新や、Windows/IIS環境なら「Win-ACME」などのツールの活用が当たり前になります。
サブスクリプション型の導入： GMOグローバルサインなどが提供している「1年契約で複数回発行するサブスク型モデル」への切り替えが進んでいます。契約事務の手間を減らしつつ、技術的な更新頻度に対応する現実的な解です。
クラウドマネージドサービスの活用： AWS（ACM）などのクラウド環境であれば、マネージドサービスによる自動更新に任せるのが正解です。