これからWebサイトを運営する人に知ってほしい、SSL証明書更新で焦った話
はじめに
SSL証明書の更新はWebサイトの信頼を守るために欠かせない定期作業です。
余裕を持って準備を始めたつもりが、気づけば更新期限まであと3日に。。。
このような失敗体験をもとに、SSL証明書更新の落とし穴とその対策を備忘録としてまとめました。
今後、同じ作業をする方の助けになれば幸いです。
SSL証明書とは？
SSL証明書とは？
SSL証明書は「このサーバーは信頼できます」という“身分証明書”で、ブラウザとサーバー間の通信を暗号化（HTTPS）するために使われます。有効期限が切れると、ブラウザは警告を表示します。
主に以下の役割があります。
- 暗号化: ブラウザとサーバー間の通信を暗号化し、盗み見や改ざんを防ぐ
- 相手の確認: 証明書の発行元（認証局, CA）が「このサーバーはこのドメインの持ち主」と確認した印として機能
- 改ざん検知: 通信途中でデータが書き換えられていないかを検出
認証のやり方（所有確認の方法）
この記事では、個人や小規模サイトでよく使われる「DV（ドメイン認証型）証明書」の更新方法を扱います。
DV証明書は、「このドメインを本当に持っているか？」を確認するだけのシンプルな仕組みで、Let's Encryptや多くの商用CAでも基本的な手順は共通です。
※企業向けの「OV（組織認証型）」や「EV（拡張認証型）」は、別途書類審査が必要になるため、今回は対象外です。
所有確認の方法は主に3つ
SSL証明書の発行時には、ドメインの所有者であることを証明する必要があります。確認方法は以下の3つです。
- ファイル認証: 指定されたURLにファイルを置き、外部からHTTPでアクセスできるかを確認
- DNS認証: 指定のTXTレコードをDNSに追加し、権威DNSに反映されているかを確認
- メール認証: 指定されたメールアドレスに届く承認メールで所有者が確認
認証方式の比較表（メリット・デメリット）
| 認証方式 | メリット | デメリット |
|---|---|---|
| ファイル認証 | シンプルで手軽。 設定が正しければすぐに認証できる。 |
ファイアウォール/WAFの制限で外部からアクセスできないと失敗する。 TLSバージョンによっては失敗する。 |
| DNS認証 | サーバーが非公開でもOK。 ファイル配置が不要。 |
DNSの反映に時間がかかる。 TTL設定によっては数時間待つことも。 |
| メール認証 | メールが届けばすぐに確認できる。 ログで到達確認もしやすい。 |
メール受信環境が必要。 迷惑メール判定や転送設定で詰まることも。 |
SSL証明書更新でハマった体験談
SSL証明書更新作業にて認証方式ごとの特性について知らなかったのもあり、更新期限ぎりぎりまで沼にはまってしまいました。。
時系列に沿って説明していきます。
Day 1: ファイル認証を開始
更新作業は初めてなので、「余裕を持って進めよう」と思い、有効期限まで残り3週間くらいのタイミングで作業を開始しました。
指定されたURLに認証用のTXTファイルを配置し、HTTP通信で外部からアクセスできることを確認しました。
この対応で、あとは認証局がアクセスしてくれれば自動的に進むはず、と思っていました。
Day 3-14: 認証が一向に通らない
1〜2週間が経過しても認証が通らず。。
この頃、証明書の有効期限は残り約1週間に迫っていました。
原因を調べた結果、ファイアウォールによるIPアドレス制限が原因と判明しました。
もともとセキュリティのため外部アクセスを制限していたサイトだったため、 認証局のサーバーがファイルにアクセスできない状態になっていたのです。
Day 15: IPアドレス制限の緩和
「このままでは間に合わない」と判断し、IP制限の一時的な緩和を実施することにしました。
セキュリティ的には好ましくない対応のため、時間制限を決めた上で実施することにしました。
外部IPアドレスからのアクセス確認も完了。
TLS設定も見直して問題なし。
「これで数時間〜1日以内にはファイル認証が通るはず」と期待していました。
Day 16: 緩和後も認証が通らず
制限を緩和してから1日経っても認証は通らず。。
- 認証に本当に時間がかかっているのか？
- まだ設定に問題があるのか？
「設定ミス」なのか「時間の問題」なのか切り分けられない状況が最も辛かったです。
この時点で、証明書の有効期限は残り3日。
IP制限の緩和を続けるのも避けたかったため、別の方法を検討することにしました。
ここまでの作業で、ファイル認証は（おそらくDNS認証も）認証局がアクセスしてくるのを待つ必要があり、
「認証に失敗したときの原因が即座にわからない」という問題を感じていました。
そこで、以下の方針に変更しました。
- 対応が早そうなメール認証に切り替える
- ただし、ドメイン指定のメールアドレスで受信できる環境が整っていなかったため、まずはDNS認証に切り替えて、メール受信環境が整い次第メール認証へ移行する
メール受信には、ImproveMXというメール転送サービスを利用して環境を構築。
こちらはDNS設定後、実際に変更が反映されるまで数時間ほど待つ必要がありましたが、当日中に
- 指定ドメインのメールアドレスにテストメールが届くことを確認する
- メール認証開始 → 認証メールを開いて認証を通過させる
ことができました！
あとは証明書の発行を待つのみです。
Day 17: SSL証明書の発行
メール認証成功の翌日、証明書が発行されました！
認証成功後の発行時間は想定以上ではありましたが、何とか期限内に対応することができました。。。
反省と学び
| 項目 | 内容 | 次回に向けた対応 |
|---|---|---|
| 認証方式の選定ミス | ファイアウォール制限がある構成でファイル認証を選んでしまった | DNS認証を選ぶ。 外部アクセス制限がある場合はファイル認証を避ける。 |
| 切り替え判断の遅れ | 期限が迫ってもメール認証への切り替えが遅れた | ファイル/DNS認証は原因の特定が難しい。 期限が7日未満なら、到達確認が即できるメール認証に早めに切り替える。 |
| メール受信環境の準備不足 | ドメイン指定のメールアドレスが受信できない状態だった | 余裕がある場合は自前でメール受信環境を構築。 時間がない場合は転送サービスを活用できるよう、事前に選択肢を把握しておく。 |
| DNS反映・証明書発行の待ち時間 | DNS反映に数時間、発行に半日〜1日かかった | DNS反映や発行処理にはタイムラグがあることを前提に、 早めの設定変更と余裕あるスケジュールを組む。 |
この経験を通じて、認証方式の選び方と切り替えタイミングの重要性を強く実感しました。
以下に、更新期限に応じた認証方式の選び方をフローでまとめました。
- 残り7日未満: メール認証を最優先（1-2日で完了）
- 残り7-14日: メール認証への切り替え推奨
- 残り14日以上: DNS認証、ファイル認証（外部到達確認必須）も選択可
まとめ
SSL証明書の更新は誰もが遭遇する作業でありながら、失敗するとサイトの信頼性が損なわれるリスクがあります。
認証方式ごとの特性を理解して、状況に応じた適切な対応をしていきましょう！
この記事が、皆さんのSSL更新作業の一助になれば幸いです。
参考資料
DNS確認ツール
- Google Public DNS - パブリックDNSサーバーでDNSレコードを確認
- DNS Checker - DNS伝播状況を確認できるツール
- MxToolbox - メール設定やDNSレコードの確認ツール
メール認証関連
- ImproveMX - 無料メール転送サービス
Discussion