TLSの有効期間47日へ

SSL/TLS証明書の有効期間短縮(いわゆる「47日問題」)

証明書の最大有効期間は、2029年までに47日へ短縮されます

何が起きるのか

CA/Browser Forumは2025年4月、パブリックTLS証明書の最大有効期間を段階的に短縮する決議(Ballot SC-081v3)を、賛成29票・反対0票の全会一致で可決しました。
現在398日となっている最大有効期間は、2026年から2029年にかけて3段階で短縮され、最終的に47日になります。
提案はApple社が行い、Apple・Google・Mozilla・Microsoftの主要ブラウザベンダー4社すべてが賛成しています。

証明書の最大有効期間の短縮スケジュール
適用開始日最大有効期間
現行398日
2026年3月15日200日
2027年3月15日100日
2029年3月15日47日

DigiCertは、この2026年3月の節目に余裕を持たせるため、2026年2月24日以降、最大199日の証明書を発行しています。
2027年の100日フェーズについても、各認証局が同様に前倒しで対応することが見込まれます。

あわせてドメイン検証(DCV)の再利用期間も短縮されます

今回の決議には、証明書の有効期間だけでなく、ドメイン検証(DCV: Domain Control Validation)の結果を再利用できる期間の短縮も含まれています。
DCVの再利用期間は、証明書の有効期間と同じスケジュールで、現行の398日から2026年に200日、2027年に100日、2029年に10日へと段階的に短縮されます。
これにより、証明書を更新するたびにドメイン検証をやり直す必要がある場面が増えます。

ACMEプロトコルとは

ACME(Automatic Certificate Management Environment)は、証明書の発行・更新を自動化するためのプロトコルで、IETFのRFC 8555(2019年3月、R. Barnes氏ほか著)として標準化されています。
Let's Encryptがこの仕組みを普及させた代表例ですが、現在はDigiCert、Sectigo、Google Trust Servicesなど、多くの認証局がACMEでの発行に対応しています。

ACMEの登場人物は、証明書を取得したい側の「ACMEクライアント」と、認証局側の「ACMEサーバー」の2者です。
標準的な手続きの流れは、おおむね次の通りです。

この一連の流れをすべてソフトウェアで完結させられる点がACMEの核心です。
実務では、Certbotやacme.sh、Kubernetes環境向けのcert-managerなど、様々なACMEクライアントが使われています。
証明書の最大有効期間が47日まで短縮される中、こうしたACMEクライアントによる自動化は、選択肢の一つというより、実務上の前提になりつつあります。

ドメイン検証の主な方式:HTTP-01とDNS-01

証明書の自動更新に使われるACMEプロトコル(RFC 8555)では、ドメインの管理権を確認するための複数の検証方式(チャレンジ)が定義されています。
実務で使われる代表的な方式が、HTTP-01とDNS-01です。

HTTP-01
Webサーバー上のhttp://<対象ドメイン>/.well-known/acme-challenge/<トークン>に、指定されたファイルを設置して確認する方式です。
設定が比較的簡単で、多くのACMEクライアントで標準的にサポートされています。
一方で、80番ポートで外部からアクセスできるWebサーバーが前提となるため、ワイルドカード証明書の発行には使えません。
CDNやロードバランサーの背後にオリジンサーバーがある構成では、チャレンジ用のリクエストが正しくオリジンまで届かず、検証に失敗することがあります。
DNS-01
対象ドメインのDNSに _acme-challenge.<対象ドメイン> というTXTレコードを設置して確認する方式です。
DNSゾーンを管理できれば検証できるため、Webサーバーを外部に公開していない環境や、CDN・ファイアウォールの背後にあるオリジンサーバーでも利用できます。
ACMEのチャレンジ方式の中で、唯一ワイルドカード証明書(*.example.com)の発行に対応しています。
一方で、DNSプロバイダーのAPIを通じてTXTレコードを自動で書き換えられる仕組みが必要になるため、DNS管理をACMEクライアントと連携させる設計が求められます。

証明書の更新頻度が上がるほど、手作業でのファイル設置やメール認証を前提としたHTTP-01ベースの運用は負荷が大きくなります。
CDNの背後にオリジンサーバーを置く構成や、ワイルドカード証明書を使う構成では、DNS-01への切り替えを検討することをお勧めします。

なぜ短縮するのか

CA/Browser Forumが挙げている主な理由は、証明書が有効なまま失効すべき状態になっている期間(失効リスクの露出期間)を短くすることです。

なお、SC-081v3の審議過程では、47日への短縮が更新頻度・運用コストの急増を招くとして、一部の認証局(HARICA等)が懸念を示したうえで反対票を投じています。
業界内でも、短縮のペースについては意見が分かれていた点は押さえておく価値があります。

PQC(耐量子暗号)との関係

今回の短縮ルール(SC-081v3)自体は、PQC(Post-Quantum Cryptography:耐量子暗号)への対応を直接の目的として決議されたものではありません。
決議文が挙げる主な理由は、前述の失効リスクの露出期間短縮です。
一方で、決議を推進したSectigo社などは「量子コンピューティング時代への備え」を関連するメリットとして掲げており、更新頻度を上げることで培われる自動化の運用能力(暗号アジリティ)が、将来PQCアルゴリズムへ切り替える際の土台になる、という位置づけで語られています。

PQCの標準化自体は、今回の決議とは別の取り組みとして、NISTが主導する形で進んでいます。
NISTは2024年8月13日、量子コンピューターによる解読に耐えることを目的とした3つの標準を確定しました。

NISTが確定したPQC標準(2024年8月時点)
規格番号アルゴリズム用途
FIPS 203ML-KEM(旧CRYSTALS-Kyber)鍵カプセル化(鍵交換)
FIPS 204ML-DSA(旧CRYSTALS-Dilithium)デジタル署名
FIPS 205SLH-DSA(旧SPHINCS+)デジタル署名(ハッシュベースの予備方式)

NIST IR 8547では、RSAやECC(楕円曲線暗号)といった現行の公開鍵暗号について、2030年以降は非推奨、2035年以降は使用禁止とする方針が示されています。
この移行期限が、企業のPQC対応を検討する際の一つの目安になります。

Webサイトの証明書における現状

PQCへの対応は、「鍵交換」と「証明書の署名」で進み方が異なります。
TLS 1.3の鍵交換については、ChromeがX25519MLKEM768という方式で2024年4月リリースのバージョン124から既定で対応しており、量子コンピューターによる「今のうちに通信を盗聴・記録しておき、将来解読する(Harvest Now, Decrypt Later)」攻撃への対策が、ブラウザ側で既に広く展開されています。

一方、証明書そのものの署名アルゴリズムをML-DSA等のPQCに切り替える動きは、まだ実用段階にありません。
CA/Browser Forumのベースライン要件は、パブリックに信頼された証明書でのML-DSA利用をまだ許可しておらず、主要ブラウザのルート証明書ストアにも、ML-DSAで署名されたルート証明書は2026年時点で登録されていません。
DigiCertは、社内システム向けなどの非公開のプライベート認証局(Private CA)であれば、既にML-DSAやSLH-DSAでの証明書発行に対応していますが、これは一般公開されたWebサイト向けの証明書とは別の話です。

まとめると、今回の47日への短縮は、PQCアルゴリズムそのものを証明書に導入するものではありません。
ただし、短い周期での自動更新を前提とした運用体制を今のうちに整えておくことは、将来パブリックな証明書でもPQC対応が可能になった際に、同じ自動化の仕組みで対応できるという意味で、有効な準備になります。

実務への影響

最大有効期間が短くなるほど、証明書の更新頻度は上がります。
1年更新の運用に慣れている組織ほど、次の変化への対応が急務になります。

このため、業界全体でACMEプロトコルやDNS-01方式による証明書発行・更新の自動化が前提になりつつあります。
自動化を前提とすると、まず「どの証明書が、どのサーバーで、いつ発行され、いつ切れるのか」を正確に把握できていることが出発点になります。
自己流のExcel管理や、担当者の記憶に依存した運用では、更新漏れによるサイト停止のリスクが高まります。

CDN(Cloudflare、Gcoreなど)を利用している場合

CDNを経由している構成では、「利用者のブラウザとCDNエッジの間」の証明書と、「CDNエッジとオリジンサーバーの間」の証明書は別物であり、それぞれ管理主体が異なります。

Cloudflareをご利用の場合
Cloudflareのプロキシ機能(オレンジクラウド)を有効にしたドメインでは、利用者のブラウザに提示されるエッジ証明書は、Let's Encryptなどの公的な認証局からCloudflareが発行を受けており、公開されたパブリックTLS証明書として今回の短縮ルールの対象です。
ただし、この証明書の発行・更新はCloudflare側が自動で行うため、通常は利用者側で個別に対応する必要はありません。
一方、CloudflareエッジからオリジンサーバーへのHTTPS通信には、Cloudflare独自の「Origin CA」証明書を使うこともできます。
Origin CA証明書はパブリックな認証局が発行するものではなく、Cloudflareのエッジのみが信頼する証明書のため、今回のCA/Browser Forumの決議の対象外であり、最長15年程度の長期の有効期間を選択できます。
オリジン側にパブリックな認証局発行の証明書を使っている場合は、そちらは今回の短縮ルールの対象になるため、別途自動更新の仕組みが必要です。
Gcore CDNをご利用の場合
Gcore CDNでは、カスタムドメインに対して無償のLet's Encrypt証明書を発行でき、発行後は自動更新されるため、エッジ証明書について利用者側で個別の更新作業は不要です。
既定ではHTTP-01方式でドメイン検証が行われますが、マルチCDN構成やCNAME Flatteningの設定によっては、この検証が失敗することがあります。
ワイルドカード証明書が必要な場合や、HTTP-01でのドメイン検証がうまくいかない場合は、GcoreのDNS APIと連携したDNS-01方式(GcoreはCertbot用のDNSプラグインを提供)への切り替えが選択肢になります。
Cloudflareの場合と同様に、CDNエッジより先にあるオリジンサーバー側の証明書は別管理であり、パブリックな認証局発行の証明書を使っていれば、今回の短縮ルールの対象として自動更新の対象に含める必要があります。
お客様がDigiCertの証明書をCDNで使いたい場合
CloudflareもGcore CDNも、CDN自身が無償で発行するLet's Encrypt証明書であれば自動更新されますが、DigiCertなど特定の認証局を指定した証明書を使う場合は、両CDNとも「カスタム証明書」としてアップロードする形になります。
Cloudflareの公式ドキュメントでは、カスタム証明書についてCloudflare側で発行・更新の管理は行わないと明記されており、有効期限までにアップロードし直す作業は利用者側の責任となります。
なお、Cloudflareの上位プラン向け機能であるAdvanced Certificate Managerでは、以前は発行元CAとしてDigiCertを選択し、Cloudflare管理下で自動更新させることも可能でしたが、Cloudflareは今後DigiCertをこの選択肢から段階的に外す方針を示しており、この経路には今後頼らない前提で検討することをお勧めします。
Gcore CDNの「ご自身のSSL証明書」機能も同様に、アップロード後の自動更新は行われません。
そのため、DigiCertの証明書をCDNで使いながら短期の自動更新に対応するには、次のような構成が現実的です。

この構成により、DigiCertの証明書を使いながら、CDN側の手作業を挟まずに47日サイクルへの対応が可能になります。
自動化パイプラインの構築自体は、DigiCertのACME連携部分と、CDN側のAPI操作部分の両方の実装が必要になるため、弊社にご相談いただければ設計・構築を支援します。

まず着手すべきこと

証明書棚卸し
社内外のサーバー・CDN・ロードバランサーで使われている証明書を洗い出し、発行元・有効期限・設置場所を一覧化します。
存在を忘れられた証明書ほど、更新漏れによる障害の原因になりやすいためです。
自動更新の仕組みの整備
ACMEクライアントの導入や、DNS-01方式によるドメイン検証の自動化など、手作業を介さない更新フローを整備します。
DNSのAPI経由でのレコード操作が可能な体制になっているかも、あわせて確認が必要です。
DCV方式の見直し
メール認証やファイル設置(HTTP-01)による手動に近いドメイン検証は、今後の更新頻度の増加に耐えられません。
CDNの背後にオリジンサーバーがある構成や、ワイルドカード証明書が必要な構成では、前述のDNS-01方式への切り替えを検討してください。

弊社では、証明書の棚卸しから自動更新フローの設計、DNS設定の見直しまで、まとめてご相談いただけます。
全国7都市の計測センターによる証明書の実測監視と、CDN上でのDigiCert証明書の自動更新パイプライン構築については、SSL証明書のプロフェッショナルサービスをご覧ください。

お問い合わせフォーム

本サービスのご相談やお見積り、事例についてなど、お気軽にお問い合わせ下さい。

➡ サービス、製品に関するお問い合わせ