2026年3月15日以降に発行される公開SSL/TLSサーバー証明書の最大有効期間は、200日へ短縮されました。今後は、2027年3月15日以降に発行される証明書が最大100日、2029年3月15日以降は最大47日となる予定です。
なお、すでに発行されている証明書の有効期限が途中で短縮されるわけではありません。現在利用している証明書は、その証明書に設定された期限まで利用できます。
最大47日になると、証明書の更新は年間8回前後に増えます。年1回の手作業で回してきた運用は、そのままでは維持しにくくなります。
問題は更新回数だけではありません。
証明書を発行した後には、サーバーへの配置、設定への反映、動作確認、更新失敗時の復旧が必要です。有効期間の短縮後は、これらの作業を短い間隔で繰り返すことになります。
本記事では、Webサイトを運用する企業に向けて、証明書の有効期間短縮で何が変わるのかを整理します。対応方法の具体例として、AWS上でのACME、ACM、ALB、CloudFrontの利用についても解説します。
目次
SSL/TLSサーバー証明書の47日化で何が変わるのか
今回の変更は、Webブラウザ事業者や認証局などで構成されるCA/Browser Forumの決定によるものです。
公開SSL/TLSサーバー証明書の最大有効期間は、次のように段階的に短縮されます。
- 2026年3月15日以降に発行：最大200日
- 2027年3月15日以降に発行：最大100日
- 2029年3月15日以降に発行：最大47日
短期間で証明書を更新することで、問題のある証明書や古い暗号技術を長期間使い続けるリスクを抑えやすくなります。
一方、Webサイトの運用側では、更新作業が増えます。
- 更新期限を確認する
- 新しい証明書を発行する
- Webサーバーへ配置する
- 設定を反映する
- HTTPS通信を確認する
- 更新失敗を検知する
- 失敗した場合に復旧する
手動で更新している場合、作業回数が増えるほど、期限切れや設定ミスが起きる機会も増えます。
ここで必要になるのが、期限を忘れないための管理ではなく、証明書の発行から反映までを継続して回せる運用です。
問題はSSL/TLSサーバー証明書を取得することではない
SSL/TLSサーバー証明書の更新は、新しい証明書を取得すれば終わるわけではありません。
EC2上のApacheやNginxでHTTPS通信を受けている場合は、取得後に証明書と秘密鍵を配置し、Webサーバーの設定へ反映します。
反映後には、正しい証明書が使われているかを確認する必要があります。
複数のサーバーやドメインがある場合は、それぞれの配置先と更新状況も管理します。
つまり、確認すべき対象は有効期限だけではありません。
- 誰が証明書を更新するのか
- どのサービスやサーバーで使っているのか
- 更新後にどのように反映するのか
- 失敗をどのように検知するのか
- 誰が復旧対応を行うのか
この範囲が決まっていないと、自動更新を設定していても、失敗したときに対応が止まります。
まず現在のSSL/TLSサーバー証明書運用を確認する
対応方法を決める前に、現在の運用を確認します。
次の項目にすぐ回答できるでしょうか。
- 利用している証明書の発行元を把握している
- 証明書を更新する担当者が決まっている
- 更新が手動か自動かを把握している
- 発行だけでなく、サーバーへの配置・反映まで自動化されている
- 更新に失敗した場合に検知できる
- 証明書を利用しているサーバーやサービスを把握している
- 自社と保守会社の責任範囲が決まっている
- 担当者が変わっても同じ手順で対応できる
- 最大47日になった後も現在の運用を継続できる
回答できない項目がある場合は、証明書の有効期間短縮を機に運用を見直す必要があります。
特に、証明書管理を制作会社やサーバー保守会社へ任せている場合は、「自動更新に対応しているか」だけでは足りません。
更新後の反映、失敗の検知、復旧対応まで、誰がどこまで担当するのかを確認します。
AWS上のWebサイトで考えられる3つの対応方法
対応方法は一つではありません。
現在の構成を維持して更新を自動化する方法もあれば、SSL/TLSサーバー証明書管理をWebサーバーから切り離す方法もあります。
EC2上でACMEを利用する
EC2上のApacheやNginxで直接HTTPS通信を受けている場合は、ACME（アクミー）クライアントを使って、証明書の発行・更新・配置を自動化できます。
AWS Certificate Manager（ACM）も2026年7月にACMEプロトコルへ対応し、Certbotやacme.shなどのACMEv2互換クライアントから、Amazon Trust Servicesが発行する公開証明書を取得できるようになりました。ACMのACMEエンドポイントから発行される証明書の有効期間は45日です。
ここで注意したいのは、ACMのACME証明書と、ALBやCloudFrontで利用する通常のACM証明書では、更新方法が異なることです。
ACMEを利用する場合は、ACMEクライアントが秘密鍵を保持し、証明書の更新と利用環境への配置を行います。一方、ALBやCloudFrontなどのAWS統合サービスで通常のACM証明書を利用する場合は、ACMが秘密鍵と証明書のライフサイクルを管理します。
ACMEは、現在のサーバー構成を大きく変えずに証明書更新を自動化したい場合に適しています。ただし、次の運用はEC2側に残ります。
- ACMEクライアントの設定
- 自動更新処理の監視
- Webサーバーへの配置・反映
- 証明書と秘密鍵の管理
- 更新失敗時の原因調査と復旧
証明書の発行・更新は自動化できますが、証明書管理そのものがWebサーバーから切り離されるわけではありません。
ALBとACMを利用する
証明書更新は自動化できますが、証明書管理そのものがWebサーバーからなくなるわけではありません。
Application Load Balancer（ALB）でHTTPS通信を受け、AWS Certificate Manager（ACM）の証明書を利用する方法です。
ALBが利用者からのHTTPS通信を受け、EC2などの接続先へリクエストを転送します。利用者へ提示する証明書はALB側で管理するため、EC2上で証明書を入れ替える必要がありません。
Amazonが発行したACM証明書は、ALBやCloudFrontなどのAWSサービスに関連付けられ、マネージド更新の条件を満たしている場合に自動更新されます。
ALBのHTTPSリスナーへデプロイされたACM証明書は、更新後も同じ証明書ARNで管理され、新しいリクエストには更新後の証明書が使われます。
ただし、外部の認証局で取得してACMへインポートした証明書は、自動更新の対象外です。
CloudFrontとACMを利用する
Amazon CloudFrontでHTTPS通信を受け、ACM証明書を利用する方法です。
CloudFrontは、世界各地の拠点からコンテンツを配信するCDNです。証明書管理に加えて、画像やCSSのキャッシュ、表示速度の改善、オリジンサーバーへのアクセス削減、AWS WAFとの連携まで見直したい場合に適しています。
CloudFrontで利用者向けのACM証明書を使う場合は、米国東部（バージニア北部）リージョンで証明書を用意する必要があります。
また、CloudFrontと接続先のWebサーバー間もHTTPSにする場合は、接続先側にも証明書が必要です。
CloudFrontを導入すれば、必ずWebサーバー側の証明書管理がなくなるわけではありません。
ACMEとALBは同じ役割ではない
ここで重要なのは、ACMEとALBが単純な代替関係ではないことです。
ACMEは、証明書の発行・更新を自動化するための仕組みです。
ALBは、WebサイトのHTTPS通信をEC2の前で受けるサービスです。ALBとACMを組み合わせることで、証明書の管理場所をEC2からAWSのマネージドサービス側へ移せます。
判断するポイントは、「自動更新できるか」だけではありません。
証明書管理を各Webサーバーに残すのか、Webサーバーから切り離すのか
ここが、EC2上のACMEとALB＋ACMの大きな違いです。
ALBとACMが向くケース
証明書更新の自動化だけであれば、ALBが必須とは限りません。
EC2上のACMEで対応できる場合もあります。
一方、次の条件に当てはまる場合は、ALBとACMが有力な選択肢になります。
証明書管理をEC2から切り離したい
EC2上で証明書を管理すると、サーバーごとに証明書や秘密鍵を配置し、更新処理を監視する必要があります。
ALBでHTTPS通信を受ければ、利用者へ提示する証明書をEC2上で管理する必要がなくなります。
複数サイトの運用を揃えたい
サイトごとに証明書の発行元や更新方法が異なると、管理手順が増えます。
ALBは、同じHTTPSリスナーへ複数の証明書を設定し、複数ドメインに対応できます。ACMへ証明書管理を集約することで、更新方法を統一しやすくなります。
AWS WAFも利用したい
ALBは、AWS WAFの保護対象にできます。
証明書更新だけでなく、Webサイトへの不正アクセスや攻撃への対策も見直す場合は、ALB＋ACM＋AWS WAFをまとめて検討できます。
将来的に冗長化したい
ALBは、複数のEC2などへアクセスを振り分けるロードバランサーです。
将来的に複数台構成や複数のアベイラビリティーゾーンで運用する場合は、ALBを構成に組み込む必要性が高まります。
ただし、ALBを置くだけでは冗長化は完成しません。
接続先がEC2一台だけであれば、ALBが障害を検知しても、アクセスを切り替える別のサーバーがありません。EC2、データベース、ファイル、バックアップを含めて設計する必要があります。
サーバー交換時のSSL/TLSサーバー証明書作業を減らしたい
証明書をEC2上で管理している場合、サーバーを交換・再構築するときに、証明書や秘密鍵、Webサーバー設定も移行します。
証明書をALB側で管理していれば、接続先のEC2を交換しても、利用者へ提示する証明書を移行する必要はありません。
サーバーの変更と証明書管理を分けられるため、移行や構成変更を行いやすくなります。
SSL/TLSサーバー証明書の47日化だけでALBを導入するわけではない
ALB＋ACMは、証明書管理をEC2から切り離す方法です。
ただし、証明書の有効期間短縮だけを理由に、すべてのWebサイトへ導入するものではありません。
EC2上のACMEで対応できる場合もあります。また、ALBには稼働時間やLCU使用量などに応じた継続的な利用料金が発生します。
導入を判断する際は、次の点を確認します。
- 現在の証明書更新方法
- サーバーやドメインの数
- 更新失敗を監視する体制
- Webサイトが停止した場合の影響
- AWS WAFの必要性
- 将来的な冗長化の予定
- サーバー交換や移行の予定
- ALBの追加費用
- 自社と保守会社の責任範囲
証明書更新だけを自動化するのか、証明書管理をEC2から切り離すのか、Webサイト基盤全体を見直すのかによって、適した対応は変わります。
まとめ：まず現在の更新方法を確認する
2026年3月15日以降に発行される公開SSL/TLSサーバー証明書の最大有効期間は200日です。今後は、2027年に最大100日、2029年に最大47日まで段階的に短縮されます。
今後は、担当者が期限を確認して手動で更新する運用を維持しにくくなります。
ただし、必要な対応はWebサイトごとに異なります。
- EC2上のACMEによる自動更新で対応する
- ALBとACMで証明書管理をEC2から切り離す
- CloudFrontやAWS WAFを含めて配信構成を見直す
- すでに自動化されているため、現在の構成を維持する
最初に行うべきことは、ALBの導入ではありません。
現在どの証明書を、誰が、どの方法で更新しているのかを確認することです。
クロジカクラウドサーバー管理では、SSL/TLSサーバー証明書の有効期間短縮に備え、現在の証明書更新方法とサーバー構成を確認します。
証明書更新の自動化だけで対応できるのか、ALBとACMなどへの構成変更が適しているのか、運用体制、セキュリティ要件、費用を踏まえてご案内します。
お気軽にお問い合わせください。
コーポレートサイトをクラウドでセキュアに
クラウドサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカクラウドサーバー管理の主な機能
- 導入事例
- 導入までの流れ
