SSL証明書の有効期限が半分に短縮されようとしています。Web証明書の60%を支えるLet's Encryptは、最大有効期限を90日から45日に移行します。GoogleのCA/ブラウザフォーラムの提案も、この方向性を踏襲しています。証明書業界全体が、セキュリティ標準として有効期限の短縮を推進しており、タイムラインはもはや机上の話ではありません。
何百、何千ものドメインにまたがるリダイレクト基盤を運用するチームにとって、これは単なる軽微な調整ではなく、運用上の掛け算です。年にドメインあたり4回必要だった更新が、すぐに8回になります。90日ではかろうじて機能していた手作業のプロセスは、45日では完全に破綻します。
このチェックリストは、6つの重要な領域（自動化、監視、更新タイミング、アラート、ワイルドカード戦略、災害復旧）にわたって、インフラチームの準備状況を評価できるように設計されています。各セクションには自己評価の質問と目標状態が含まれています。最後には、インフラがどこに立っているのか、そして45日運用の時代が来る前に何を変える必要があるのかが明確になります。
1. 自動化：ゼロタッチ証明書ライフサイクル#
準備状況の評価で最も重要な質問：発行および更新されるすべての証明書が、人の介入なしに行われていますか？
答えが、揺るぎない「はい」以外なら問題があります。45日という有効期限では、手作業の証明書運用は、驚くほど小さな規模でも持続不可能になります。ドメイン50件のポートフォリオでも、年間400回の証明書操作が必要です——毎日、週末や祝日も含めて、1日1回以上です。
現状の自己評価：チームは現在、証明書のプロビジョニングをどのように行っていますか？答えが、カレンダーのリマインダー、スプレッドシート、手作業でのCSR生成、「誰かがだいたい対応している」といった内容なら、手作業の領域です。ワークフローの一部をスクリプト化していても、そのスクリプトがすべてのドメインをカバーし、あらゆる例外ケースを処理し、すべての失敗から人のエスカレーションなしに復旧できるかを確認してください。
目標状態：リダイレクト基盤のすべてのホスト名が、DNSが設定された瞬間にACME経由で自動プロビジョニングされます。証明書の発行、インストール、更新は、人の操作なしで行われます。システムは新しいドメインを検出し、DNS-01チャレンジで所有権を検証し、証明書を要求し、エッジノード全体にインストールし、次回の更新をスケジュールします——ホスト名が追加されてから数秒以内にすべて完了します。
サーバーごとに証明書を管理するのではなく、ホスト名ごとにSSLを管理するリダイレクト基盤は、自動化ギャップを完全に解消します。DNSが基盤に委任されると、SSLは誰かのToDoリスト上の作業ではなく、インフラの属性になります。
2. 監視：壊れる前に把握する#
自問してみてください：すべてのドメインで、証明書の有効期限切れを監視していますか？
監視は、自動化の下にあるセーフティネットです。ACMEベースの更新があっても、問題が起こることはあります。DNSレコードが変更される、レート制限が発動する、認証局（CA）が障害を起こすなどです。監視がなければ、有効期限切れの証明書を発見する方法はユーザーと同じになります。つまり、ブラウザの警告を通じて気づくのです。
しかし監視は、有効期限の日付を確認するだけではありません。リダイレクト基盤に対する効果的な監視とは、複数のグローバルな場所からのヘルスチェックを行うことです。オフィスからは有効に見えても、エッジへの伝播遅延やCDNのキャッシュの影響で、ユーザーの場所では失敗する可能性があります。
現状のセルフアセスメント：すべてのドメインについて、証明書の有効期限を表示するダッシュボードまたはアラートシステムはありますか？証明書が更新されたとき、リアルタイムで更新されますか？期限が近づいているドメインと、すでに失敗しているドメインを一目で把握できますか？
目標状態：複数のグローバルなエッジ拠点からの継続的な証明書ヘルス監視。システムは、有効期限の参照だけでなく、アクティブなTLSハンドシェイクのチェックを実行して、すべての証明書が有効で、信頼され、正しく配信されていることを確認します。ダッシュボードは、すべてのドメインのリアルタイムなステータスを表示します。監視は自動化されています。新しいホスト名が追加されると、設定なしで監視が開始されます。
3. 更新タイミング：バッファゾーン#
質問：更新は、多日間の障害を乗り切れるほど十分に早いタイミングで試みられていますか？
90日間の証明書なら、有効期限の7〜14日前に更新することで、十分なバッファを確保できました。45日間の証明書では、同じバッファが証明書の総利用可能期間の15〜30%を食い潰します。計算上、トレードオフが生じます。早すぎる更新をすると証明書を常に入れ替えることになり、遅すぎる更新をすると、一時的なCA障害が本番インシデントになります。
Let’s Encryptのレート制限も、もう一つの要素を加えます。同一のホスト名セットに対する「重複証明書（Duplicate Certificate）」の上限は週5枚で、「登録済みドメイン（Certificates per Registered Domain）」あたりの上限は週50枚です。45日間の更新サイクルでは、大規模なドメインポートフォリオが、想定より早くこれらの上限に近づく可能性があります。特に、新しいドメイン向けの証明書も同時にプロビジョニングしている場合は注意が必要です。
現状のセルフアセスメント：更新ウィンドウはどのように設定されていますか？チームが証明書を手動で更新している場合、有効期限の少なくとも15日前から更新を開始していますか？証明書が1つも期限切れにならずに、5日間のCA障害を乗り切れますか？更新の試行が失敗した場合に何が起きるかをテストしましたか。システムは自動でリトライしますか、それとも人の介入を待ちますか？
目標状態：自動更新は有効期限の30日前から開始され、指数バックオフのリトライロジックで再試行します。最初の試行が失敗した場合、更新は増加する間隔で再試行されます（1時間、4時間、12時間、24時間）。更新が成功するまで繰り返します。レート制限は自動的に追跡され、確実に順守されます。システムは、CA（認証局）の複数日間の障害が発生しても、いずれのドメインも期限切れの日付に到達しません。更新を十分に早く開始しているため、常に少なくとも15日分のバッファがあるからです。
4. アラート：前に、後ではなく#
問い：正しい人が、証明書の有効期限が切れる「前」に通知されるのでしょうか？「後」ではなく。
アラートは、非イベントとインシデントの違いです。証明書の更新が失敗した場合、次の2つが必要です。1つはシステムが自動的に再試行すること（第3節参照）、もう1つは適切な担当者がそれを把握していることです。監視で期限切れの証明書を検知しても誰にも通知されないなら、ギャップがあります。単に、より早くそれを知っているだけです。
アラートは重大度と対象者で段階付けすべきです。30分後に再試行が成功した更新失敗は、午前2時のページ（呼び出し）を必要としませんが、日次ダイジェストには表示されるべきです。有効期限まで残り72時間を切っているのに、正常に更新できていない証明書は、重大なアラートであり、オンコールエンジニアに直ちに届く必要があります。
現状の自己評価：証明書が期限切れ間近になったとき、誰に通知されますか？重大度の異なる段階付けされたアラートシステムはありますか？緊急度に応じて、アラートは適切なチャネル（Slack、メール、PagerDuty）に送られますか？一次オンコール担当者が利用できない場合、アラートはエスカレーションされますか？
目標状態：3段階のアラート。Info（更新を試行、日次ダイジェスト）、Warning（更新失敗、7日間の猶予、Slack/メール）、Critical（更新が繰り返し失敗、72時間の猶予、PagerDuty/オンコールへのエスカレーション）。アラートには、ドメイン名、有効期限、最終更新試行時刻、失敗理由を含めます。ポートフォリオ内のすべてのドメインをカバーします。例外なし。「あれは手動で監視するから大丈夫」ということはありません。
5. ワイルドカード証明書：便利さとリスク#
問い：ワイルドカード証明書は適切に扱われていますか？それとも単一障害点を作ってしまっていますか？
ワイルドカード証明書は魅力的です。*.example.com の1つの証明書で、すべてのサブドメインをカバーできます。更新は1回。期限切れ日は1つ。管理する対象は1つ。ですが、その「管理する対象」が同時に「失敗し得る対象」でもあります。そしてそれが起きたとき、すべてのサブドメインが同時に暗転します。
リダイレクト基盤に限って言えば、ワイルドカードは別の問題を生みます。ワイルドカード証明書のDNS-01チャレンジには、エイペックスドメインのDNSゾーンへのアクセスが必要です。リダイレクトドメインが複数のレジストラやDNSプロバイダに分散している場合（大規模なポートフォリオではよくあること）、単一のワイルドカードに対するDNS-01チャレンジの管理は、ホスト名ごとの証明書を管理するよりも大幅に複雑になります。
現状の自己評価： リダイレクトドメインにワイルドカード証明書を使用していますか？ ワイルドカード証明書の更新に失敗した場合、影響を受けるドメイン数はどれくらいですか？ テスト済みのロールバック計画はありますか？ ワイルドカードは、ドメインごとの証明書を管理する同じチームが管理していますか、それとも別のプロセスで、担当者が異なりますか？
目標状態： ホスト名ごとの証明書がデフォルトです。各ドメインに独自の証明書を発行し、独立してプロビジョニングおよび更新します。これにより分離が実現します。あるドメインの更新失敗が、他のドメインに影響しません。ワイルドカードは、明示的に必要な場合にのみ使用します（例：共有サブドメイン配下の内部サービス）。また、監視とアラートは別に行い、ドキュメント化されたテスト済みの復旧手順も用意します。
6. 災害復旧：CAがダウンしたら#
問い： あなたの証明書発行局（CA）が5日間利用できない場合、証明書は生き残りますか？
Let’s Encryptは過去に数時間単位の障害を経験しています。証明書の有効期間が90日なら、2〜3日間の障害は許容可能でした。証明書に十分な残存有効期間があり、障害をやり過ごせたためです。ところが有効期間が45日だと、同じ障害でも、CAがオンラインに戻る前に証明書が更新期限を過ぎてしまう可能性があります。
SSLの災害復旧は、CAだけの話ではありません。DNSです。DNSプロバイダがDNS-01チャレンジのウィンドウ中に障害を起こすと、チャレンジが失敗し、更新がブロックされます。エッジへの伝播も重要です。更新された証明書が、古い証明書が期限切れになる前にすべてのエッジノードへ伝播しない場合、一部のユーザーにエラーが表示されます。そして更新パイプライン自体も問題になります。自動化プラットフォームが障害を起こした場合、更新はキューに積まれるのか、それとも破棄されるのか？
現状の自己評価： 5日間のCA障害時に何が起きるかをモデル化していますか？ ポートフォリオ全体で最短の証明書有効期間はどれくらいですか？ フォールバックCAを設定していますか。それともすべての証明書が単一のプロバイダに紐づいていますか？ チャレンジのウィンドウ中にDNSインフラが障害を起こしても耐えられますか？
目標状態： 証明書は十分に早いタイミングで更新され、各ドメインが少なくとも15日分のバッファを常に維持します。現実的なCA障害を乗り切るのに十分な余裕です。更新パイプラインは耐障害性があります。CAが利用できないことが原因で更新に失敗した場合、CAが復旧するとシステムが自動的に再試行します。監視は証明書の有効期限だけでなく、依存関係の全チェーン（DNS、CA、エッジ伝播）をカバーします。重要なドメインにはフォールバックCAを設定し、チームには、CAが長時間障害の間に証明書を手動でプロビジョニングするための、ドキュメント化されたテスト済みの手順書（runbook）があります。
自己評価： あなたの準備状況をスコア化する#
以下の6つの領域それぞれについて、インフラの評価を行ってください。正直に — 低いスコアは失敗ではなく、ロードマップです。
採点：1＝手動／機能なし、2＝部分的に自動化／不足あり、3＝ほぼ自動化／軽微な不足、4＝完全に自動化／不足なし、5＝完全に自動化＋テスト済み／耐障害性あり
| Domain | あなたのスコア（1〜5） | Priority if < 4 | 最初のアクション |
|---|---|---|---|
| ① Automation | __ | Critical | 現在の手動ステップを監査する — 1つの領域を選び、完全に自動化する |
| ② Monitoring | __ | High | すべての領域について、30日間の警告しきい値で有効期限監視を実装する |
| ③ 更新タイミング | __ | Critical | すべての更新を、有効期限の最低30日前にトリガーされるよう設定する |
| ④ Alerts | __ | High | 少なくとも2段階のアラートを設定：警告（7日）と重大（72時間） |
| ⑤ Wildcards | __ | Medium | ワイルドカード証明書をすべて棚卸しし、証明書ごとの影響範囲（ブラス卜半径）を文書化する |
| ⑥ ディザスタリカバリ | __ | Medium | 5日間のCA障害シナリオを想定し、生存ギャップを記録する |
合計の解釈：
24-30: 準備はできています。インフラは自動化され、監視され、耐障害性があります。この状態を維持し、復旧手順を定期的にテストすることに注力してください。
18-23: 土台はしっかりしていますが、まだギャップがあります。まず「クリティカル」領域を優先してください。自動化と更新タイミングが最も費用対効果の高い改善です。45日間のタイムラインは、現在のセットアップに大きな負荷をかけます。
12-17: インフラは45日間の証明書に対応できていません。90日で機能する手作業プロセスは、45日では破綻します。まず自動化（ドメイン①）から始めましょう。1つだけ直すなら、自動の証明書発行と更新を行えるようにすることです。
6-11: リスクが高い状態です。ポートフォリオ内のすべてのドメインが、カレンダーのリマインドを1回見落とす、またはCA障害が起きるだけで脆弱になります。ギャップを素早く埋めるために、SSLの自動化をインフラとして扱うリダイレクト・プラットフォームへの移行を検討してください（タスクではなくインフラとして）。
ギャップはますます広がる#
45日証明書の時代は「将来の可能性」ではありません。明確なタイムラインを伴う業界の進行そのものです。360,000万以上のドメインに対して証明書を発行するLet's Encryptが、この変化をリードしています。GoogleのCA/Browser Forumの提案も、同じ方向性を示しています。標準は移行中であり、証明書の有効期間が短くなるほど、自動化されたインフラと手作業のインフラのギャップはさらに広がっていきます。
今すぐ自動化に取り組むチームは、この変化を「変化」として感じることはありません。ダッシュボードに更新が予定どおり完了する様子が表示されるだけです——毎回、すべてのドメインで、30日前倒しで完了します。一方で他のチームは、スプレッドシートを更新するのに追われます。上記のチェックリストは、単なる評価ツールではありません。業界が落ち着く証明書の有効期間（45日、30日、あるいはそれより短い期間）に対しても対応できるインフラへのロードマップです。
インフラをスコアリングし、ギャップを埋めましょう。45日証明書の時代がやってきます——リダイレクトドメインのことは、最後に心配すれば十分です。
よくある質問
Let's Encryptは、最大証明書の有効期限を90日から45日に短縮する計画を発表しました。この移行は2026年に始まると予想されています。GoogleのCA/ブラウザフォーラムも並行して提案を進めており、短い有効期限が業界標準になることを示唆しています — これはLet's Encryptのポリシーにとどまりません。
45日証明書の有効期限では、各ドメインは年間約8回の更新サイクルが必要です — 90日証明書の4回から増加します。500のリダイレクトドメインを管理するチームにとっては、年間4,000回の証明書操作が必要になるということです。
最も信頼性の高いアプローチは、ACMEベースの自動化です。リダイレクトインフラが自動的にDNS-01チャレンジを完了し、証明書を発行し、更新をスケジュールします。ホスト名ごとにSSLを処理するリダイレクトプラットフォームは、個々のドメイン間で証明書を手動で管理する必要を排除します。
リダイレクトドメインの証明書が期限切れになると、ブラウザはページを読み込む前にセキュリティ警告のインタースティシャルを表示します。これによりリダイレクトが完全にブロックされ — 訪問者は目的地に到達できません。マーケティングキャンペーンにとっては、クリックの損失、トラッキングの破損、信頼の低下を意味します。回復にはCAの伝播速度に応じて数時間から数日かかることがあります。
ワイルドカード証明書は、単一の頂点ドメインの下にあるサブドメインの管理を簡素化しますが、単一障害点を作成します — ワイルドカードが期限切れになると、すべてのサブドメインに影響が及びます。ドメインごとの証明書はより良い隔離を提供しますが、管理のオーバーヘッドが増加します。大規模なポートフォリオの場合、ACMEを介してホスト名ごとの証明書を自動的にプロビジョニングするリダイレクトプラットフォームが、管理の負担なしに隔離を提供します。
ベストプラクティスは、期限切れの少なくとも15日前に更新を開始することです — 重要なインフラの場合は30日前です。このバッファは、DNSの伝播遅延、CAの障害（数日間続くことがあります）、および再試行ロジックを考慮しています。45日証明書では、30日前の事前更新は、証明書が発行されるとほぼ同時に更新を行うことを意味し — 自動化が不可欠になります。
ACME（自動証明書管理環境）は、証明書のライフサイクル全体を自動化するプロトコルです：ドメインの検証、証明書の発行、インストール、更新。ドメイン所有権を確認するためにDNS-01またはHTTP-01チャレンジを使用し、その後、証明書機関との暗号交換を自動的に処理します。ACMEはLet's Encryptを支えるプロトコルであり、ゼロタッチのSSL自動化を可能にします。
はい。RedirHubは、プラットフォームに追加された各ホスト名に対してLet's Encryptを介してSSL証明書を自動的にプロビジョニングします。DNSがRedirHubのエッジにポイントされると、システムはホスト名を検出し、ACME DNS-01チャレンジを完了し、証明書を発行し、自動更新をスケジュールします — すべて手動の介入なしで行われます。更新は期限の30日前に開始され、自動再試行ロジックと失敗アラートが含まれます。
Linh handles the backend systems that keep RedirHub fast and reliable. Her work revolves around performance, scalability, and making sure redirects happen instantly, no matter where users are. She likes solving complex problems quietly.
