LASSIC Media らしくメディア
SSL証明書の短命化、更新自動化を外注で対応
LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託
この記事のポイント
- SSL/TLS証明書の有効期間の上限は、CA/Browser Forumの決定に基づき今後段階的に短縮されます。
- 有効期限切れによるサイト停止を防ぐには、ACME(自動証明書管理環境)を使った発行・更新の自動化が実務上の前提になります。
- 内製での自動化運用に必要なスキル・体制の確保が難しい場合は、外部委託(外注)も選択肢の一つです。
目次
- SSL証明書の有効期間短縮とは — 398日から47日への段階規定
- なぜ有効期間を短くするのか — CA/Browser Forumが可決したSC-081v3
- 2026年3月・2027年3月・2029年3月 — 3段階の移行スケジュール
- ACME(自動証明書管理環境)とは — 発行・更新を自動化する仕組み
- Let’s Encryptも45日証明書へ — 更新頻度急増と手動運用の限界
- 内製でACME自動化を運用する場合に必要なスキルと体制
- 自動化移行の実務ステップ — 棚卸から本番切替まで
- 外部委託する場合の対応範囲と内製との違い
- まとめ — SSL証明書短命化に備える3つの判断軸
- よくある質問
SSL証明書の有効期間短縮とは — 398日から47日への段階規定
SSL証明書の有効期間短縮とは、CA/Browser Forum(認証局とブラウザベンダーで構成する業界団体)が定めた業界規定を指します。この規定により、公開SSL/TLS証明書の有効期間の上限は398日から47日まで段階的に短くなります*1。
短縮は2026年3月に始まり、2029年3月の最終段階まで3段階で進みます*1。対象はDV(ドメイン認証)・OV(組織認証)・EV(拡張認証)の全種別で、ワイルドカード証明書や複数ドメインをまとめて保護するSAN証明書も含まれます*1。
なぜ有効期間を短くするのか — CA/Browser Forumが可決したSC-081v3
CA/Browser Forumは2025年4月11日、Ballot SC-081v3を可決しました*1。証明書発行者側の投票は25票対0票(棄権5)、証明書利用側の投票は4票対0票という結果で、反対票はありませんでした*1。
CA/Browser Forumはこの決定の狙いを、証明書が発行時点の状態を写し取ったものである点に求めています*1。ドメインの管理者や組織の実態は時間とともに変わるため、有効期間が長いほど証明書内の情報が実態とずれるリスクは高まります*1。
有効期間を短くし、発行時の検証をより頻繁に繰り返せば、実態とずれた情報を含む証明書が有効なまま使われ続ける可能性を抑えられます*1。CA/Browser Forumはこの取り組みを、TLS Baseline Requirementsの初版以来続く継続的な課題と位置づけています*1。
CA/Browser Forumはさらに、証明書発行時の検証情報を再利用できる期間(データ再利用期間)についても、あわせて短縮する方針を示しています*1。発行に使う検証情報をより頻繁に取り直すよう求めることで、不適切な発行のリスクを抑える狙いがあります*1。証明書そのものの有効期間短縮と、検証情報の再利用期間短縮は、同じBallot SC-081v3の中で対になって進められる規定です*1。
2026年3月・2027年3月・2029年3月 — 3段階の移行スケジュール
証明書の有効期間の上限は、3段階で段階的に短縮されます*1。2026年3月15日から200日、2027年3月15日から100日、2029年3月15日からは47日となります*1。
| 適用開始日 | 証明書の有効期間の上限 |
|---|---|
| 2026年3月15日 | 200日 |
| 2027年3月15日 | 100日 |
| 2029年3月15日 | 47日 |
現在398日(約13カ月)まで許容されている有効期間は、2029年3月には47日、約1カ月半に縮まります*1。年に1回程度だった更新作業は、最終段階では年8回前後に増える計算です。
ACME(自動証明書管理環境)とは — 発行・更新を自動化する仕組み
ACMEとは、証明書の発行・更新を自動化する通信プロトコルです*3。正式名称はAutomatic Certificate Management Environment(自動証明書管理環境)といいます*3。ドメイン所有権の確認から証明書の受け取りまでの手続きが対象で、IETF(インターネット技術の標準化団体)がRFC 8555として標準化しています*3。
HTTP-01・DNS-01 — 2種類のドメイン所有権確認方式
ACMEクライアントは、HTTP-01やDNS-01といった手法でドメインの所有権を確認します*3。HTTP-01はWebサーバー上に指定ファイルを設置する方式、DNS-01はDNSにTXTレコードを設置する方式です*3。確認が完了すると、認証局は自動で証明書を発行します。
Let’s Encryptはこのプロトコルを採用する代表的な認証局です*2。CertbotやACME.shなど複数のACMEクライアントが公開されており、サーバーへの証明書配置まで自動化する構成が広く使われています*6。
ARI(ACME Renewal Information)が伝える推奨更新時期
ARI(ACME Renewal Information)とは、認証局がACMEクライアントに対して証明書ごとの推奨更新時期を通知する仕組みです*2。対応クライアントを使えば、更新タイミングの判断を自動化できます*2。
Let’s Encryptも45日証明書へ — 更新頻度急増と手動運用の限界
Let’s Encryptは2026年5月13日、tlsserverプロファイルで45日証明書の提供を始めます*2。既定のclassicプロファイルも2027年2月10日に64日、2028年2月16日に45日へと段階的に切り替わります*2。
6日間だけ有効なshortlivedプロファイルも2026年1月にGA(一般提供)となりました*5。証明書の有効期間が短くなるほど、手動での更新作業では追いつきにくくなります。
更新を数日でも見誤ると、証明書は失効しブラウザに警告画面が表示されます。ECサイトであれば、警告表示中に離脱した利用者の売上機会は戻ってきません。有効期間が47日まで縮まれば、更新間隔のわずかな見落としが失効に直結しやすくなります。
内製でACME自動化を運用する場合に必要なスキルと体制
ACMEによる自動更新を内製で構築するには、DNS API連携・サーバー設定・監視の3領域の知識が必要です。DNS-01方式を使う場合は、利用するDNSサービスのAPI仕様を理解し、TXTレコードの自動更新処理を組む必要があります。
証明書を複数のWebサーバーやロードバランサーに配布する構成では、更新後の再読み込み処理や証明書ストアの同期も自動化の対象に含める必要があります。構成が増えるほど、対応すべき箇所は比例して増えていきます。
更新の失敗を検知する監視体制も欠かせません。ARIに対応したクライアントを使えば更新タイミングの判断は自動化できますが*2、監視ツールとの連携設定やアラートの通知先整備は別途必要です。
自動化移行の実務ステップ — 棚卸から本番切替まで
有効期間短縮への対応は、思いつきで着手するとサーバーの取りこぼしや設定ミスにつながります。次の4ステップで進めると、対象範囲を漏らさず自動化に移行しやすくなります。
- 現状棚卸:稼働中のドメインと証明書の発行元・更新方式(手動/自動)を一覧化します。
- ACMEクライアントの選定:利用中のDNSサービス・Webサーバー・ロードバランサーに対応したクライアントを選びます。
- 検証環境での自動更新テスト:本番投入前に、発行から配置・再読み込みまでの一連の流れをリハーサルします。
- 本番移行と監視体制の構築:更新失敗を検知するアラートを設定し、段階的に対象サーバーを切り替えます。
最初の棚卸を省くと、後になって自動化の対象から漏れたサーバーが見つかり、そこだけ手動更新が残るという事態になりやすくなります。棚卸の段階で、社内の複数部署が管理するドメインまで含めて洗い出しておくことが、後工程の手戻りを防ぎます。
検証環境でのテストでは、更新処理が正しく反映されるかを確認します。DNS-01方式であればTXTレコードの自動更新、HTTP-01方式であればロードバランサー経由でも認証用ファイルに到達できるかがポイントです。この工程を省いて本番へ直接投入すると、初回更新時の失敗に伴う切り戻し対応に追われやすくなります。
外部委託する場合の対応範囲と内製との違い
前節では、内製で自動化を構築する場合に必要な知識と実務ステップを確認しました。本節では、外部委託した場合にどこまでの対応範囲を任せられるかを整理します。
| 比較軸 | 内製で対応する場合 | 外部委託する場合 |
|---|---|---|
| 初期構築 | DNS API連携やACMEクライアントの選定・検証を自社で行います。 | 実績のある構成をそのまま適用できます。 |
| 更新頻度増加への対応 | 短縮された周期の更新監視を担当者が継続します。 | 監視・アラート対応を委託先が担います。 |
| 障害時の切り戻し | 対応経験を持つ担当者が限られると復旧が遅れやすくなります。 | 専門チームが切り戻し手順をあらかじめ保有しています。 |
| 対象範囲の拡張 | サーバー追加のたびに設定を作り込みます。 | 委託範囲内で横展開しやすくなります。 |
内製と外部委託の違いは、構成を新規に作る負荷と、既存の運用ノウハウを使う負荷の差にあります。自社でACME連携の経験を積んだ担当者がいない場合、初期構築の試行錯誤に時間を要しやすくなります。
まとめ — SSL証明書短命化に備える3つの判断軸
本稿では、CA/Browser Forumの決定によるSSL/TLS証明書の有効期間短縮と、ACMEによる自動化への対応を整理しました。要点は3つに集約できます。第一に、証明書の有効期間の上限は2026年3月から200日、2029年3月には47日まで短くなります*1。第二に、Let’s Encryptを含む主要な認証局はこの動きに沿って、ACME対応の自動更新を前提にした運用へ移行しています*2。第三に、内製での自動化構築には複数領域の知識と継続的な監視体制が必要で、体制確保が難しい場合は外部委託も判断材料になります。
よくある質問
証明書の有効期間はいつからどれくらい短くなりますか。
CA/Browser Forumが可決したBallot SC-081v3により、公開SSL/TLS証明書の有効期間の上限は段階的に短くなります*1。2026年3月15日から200日、2027年3月15日から100日、2029年3月15日からは47日です*1。対象はDV・OV・EVの全種別で、ワイルドカード証明書やSAN証明書も含まれます*1。
Let’s Encryptの証明書もすぐに45日になりますか。
Let’s Encryptはまず2026年5月13日にtlsserverプロファイルで45日証明書の提供を始めます*2。既定のclassicプロファイルは2027年2月10日に64日、2028年2月16日に45日へと段階的に切り替わる計画です*2。
ACMEを導入すれば手動での更新作業は不要になりますか。
ACME(自動証明書管理環境)に対応したクライアントを使えば、ドメイン所有権の確認から証明書の発行・配置までを自動化できます*3。ただしDNS連携やサーバーへの配布設定は事前の構築が必要で、導入後の監視・障害対応の体制づくりは別途欠かせません。
更新頻度の増加で新規発行のレート制限に達しやすくなりますか。
Let’s Encryptは既存証明書の更新について、新規発行のレート制限を適用しない扱いとしています*4。そのため証明書の更新頻度が増えても、新規ドメインの発行枠を圧迫する心配は基本的にありません*4。
著者:テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典:CA/Browser Forum「Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods」(https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/)(2025年)
- *2 出典:Let’s Encrypt「Decreasing Certificate Lifetimes to 45 Days」(https://letsencrypt.org/2025/12/02/from-90-to-45)(2025年)
- *3 出典:IETF「RFC 8555: Automatic Certificate Management Environment (ACME)」(https://datatracker.ietf.org/doc/html/rfc8555)(2019年)
- *4 出典:Let’s Encrypt「Shorter Certificate Lifetimes and Rate Limits」(https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs)(2026年)
- *5 出典:Let’s Encrypt「6-day and IP Address Certificates are Generally Available」(https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability)(2026年)
- *6 出典:Let’s Encrypt「ACME Client Implementations」(https://letsencrypt.org/docs/client-options/)