TLS証明書の有効期限はなぜ短くなるのか？ 47日化の背景から考えるセキュリティ設計

WebサイトのHTTPS通信で利用されるTLS証明書（SSL証明書）の有効期限が、今後段階的に短縮されることは、多くのWebサイト管理者、運用者の方はご存知のことかと思います。
2029年3月以降に発行される公開TLS証明書は、最長47日まで短縮される見込みとなっています。

出典：CA/Browser Forum

「更新作業が大変になるのではないか」
「なぜそこまで短くする必要があるのか」

と感じる方もいらっしゃるかもしれません。
しかし、この変更の本質は単なる運用ルールの変更ではありません。

実はWebの信頼性を支えるPKI（Public Key Infrastructure）には以前からいくつかの課題があり、その課題を根本的に改善する方法として「証明書の短期化」という考え方が広がっています。

本記事では、TLS証明書の有効期限が短縮される背景を追いながら、Webセキュリティの考え方がどのように変化しているのかを解説します。

証明書の短縮化は以前から進んでいた

TLS証明書の有効期限の短縮は今に始まったことではなく、これまで何度も短縮されてきました。

2012年頃までさかのぼると、当時は最長10年間有効な証明書を発行することができました。
しかし、それ以降、数年かけて段階的に短縮されています。

そして今後は、

• 2026年以降：約200日
• 2027年以降：約100日
• 2029年以降：47日

と移行していく予定です。

ではこれらは一体誰が決めているのでしょうか？

CA/Browser Forumとは

TLS証明書（PKI）に関するルール変更を決めているのが、CA/Browser Forumです。
CA/Browser Forumは、認証局（CA）とブラウザベンダーが参加する国際的な業界団体です。

認証局（CA）の例
• DigiCert
• GlobalSign
• Sectigo
：

ブラウザベンダーの例）
• Google Chrome
• Microsoft Edge
• Mozilla Firefox
• Apple Safari
：

簡単に言うと、「TLS証明書を発行する側と利用する側が集まり、証明書のルールを決める団体」です。証明書の有効期限や発行ルール、失効ルールなどもこの団体で議論されています。

TLS証明書におけるPKI（公開鍵基盤）の仕組み

HTTPS通信では、Webサイトと利用者のブラウザがお互いを信頼できることを確認するために、PKI（Public Key Infrastructure：公開鍵基盤）という仕組みが利用されています。

まず、サービス提供者がTLS証明書を申請すると、認証局（CA）がWebサイトの情報を確認し、TLS証明書を発行します。
サービス利用者がWebサイトへアクセスすると、ブラウザはその証明書を受け取り、信頼できる認証局が発行したものであるかを確認します。

その際に利用されるのが、CRL（Certificate Revocation List） と OCSP（Online Certificate Status Protocol） と呼ばれる仕組みです。ブラウザはこれらを利用して、証明書が失効していないかや、不正利用が報告されていないかを確認します。
問題がなければ、ブラウザとWebサイトの間でHTTPSによる安全な通信が開始されます。

つまり、HTTPSの安全性は単に証明書を持っているだけではなく、

• 認証局による信頼性の確認
• 証明書の有効性の確認
• 暗号化通信の実施

という複数の仕組みによって支えられているのです。

しかし、こうした仕組みによってHTTPSの安全性が支えられている一方で、PKIにはいくつかの課題が指摘されてきました。

PKIの課題

では、PKIにはどのような課題があるのでしょうか。

所有者情報が不正確になる

証明書の発行元には、証明書の種類によって、ドメイン名以外にも組織名や所在地、法人登録番号などの様々な情報が記載されています。
しかし、証明書は発行された瞬間の情報しか保証できません。

例えば、

• ドメイン所有者が変わる
• 会社が買収される
• 組織名が変わる
• 秘密鍵が漏えいする

といったことが発生しても、発行済みの証明書にはその情報が自動的に反映されるわけではありません。

つまり、「発行時には正しかった情報が、時間の経過とともに正しくなくなる」という問題があります。認証局は発⾏先を定期的に確認する義務がありますが、上記のような変更があっても即座に把握できるとは限りません。

Bygone SSL問題について

情報が不正確になることで、CA/Browser Forumが指摘している代表的な問題の一つが「Bygone SSL」です。

Bygone SSLの問題は、過去のドメイン所有者が取得した証明書が有効なまま残ってしまうことです。ここには主に次の二つの問題が発生します。

問題１：なりすまし攻撃・中間者攻撃のリスク

例えば、Aが過去にexample.comを所有しており、その際にTLS証明書と対応する秘密鍵を取得していたとします。その後、Aはドメインを更新せず、別の利用者であるBがexample.comを取得し、新たな証明書を発行したとします。

しかし、Aが取得した古い証明書は有効期限内であり、まだ失効されていません。
このとき、特定の条件下ではAは古い証明書を使って、

• example.comになりすます
• 利用者を偽サイトへ誘導する
• 通信を傍受する中間者攻撃（MITM）を行う

といった攻撃に利用できる可能性があります。

もちろん、実際に攻撃を成立させるためには通信経路の乗っ取りなど追加の条件が必要ですが、「すでにドメイン所有者ではない人物が、有効な証明書を保持し続けられる」という状況そのものが、PKIの信頼性を損なう要因になります。

問題2：証明書を簡単に取り消せない

「それなら古い証明書を失効すればよいのでは」と思うかもしれません。しかし実際には、Bが失効を申請したとしても容易でない場合があります。

例えばホスティング事業者では、1枚の証明書に複数のドメインを登録したSAN証明書を利用しているケースがあります。

CN = hosting.example（ホスティングサービスのドメイン）
SAN
– example.com（Eveのドメイン）
– abc.com（ホスティングサービス利用者のドメイン）
– xyz.jp（ホスティングサービス利用者のドメイン）
– sample.net（ホスティングサービス利用者のドメイン）

この場合、Aが所有していたexample.comだけが問題であっても、その証明書には他の利用者のドメインも含まれています。

そのため証明書全体を失効すると、

• abc.com
• xyz.jp
• sample.net

などの、まったく関係のない利用者のWebサイトまで影響を受ける可能性があります。

認証局やホスティング事業者は、他の利用者への影響を考慮しなければならないため、古い証明書をすぐに失効できないケースが発生します。つまり、古い証明書を残せばセキュリティリスクが生じるが、失効すると他の利用者に影響する可能性がある、というジレンマが発生するのです。
これがBygone SSL問題が長年指摘されてきた理由のひとつです。

このような問題は、証明書の有効期限を短くすることで影響期間そのものを短縮できます。仮に古い証明書が残っていたとしても、数年ではなく数十日で自然に失効するため、リスクを大幅に低減できます。

証明書失効の仕組み上の問題

PKIの説明でも軽く触れましたが、証明書の失効を確認するには、CRLとOCSPという二つの仕組みがあります。
どちらも利用者のブラウザやOSが「この証明書はまだ有効ですか？」を確認するための仕組みですが、簡単に説明すると、

CRL：失効した証明書の一覧表をまるごと配る方式
OCSP：証明書1枚ごとに問い合わせる方式

という違いがあります。
しかし、失効確認の仕組み自体にも課題があります。

OCSPに依存しすぎると何が起きるのか

2020年11月、Appleの証明書検証基盤に関連する障害の影響で、macOS上のアプリケーション起動が大幅に遅くなる事象が発生しました。
当時のmacOSでは、アプリケーションの起動時に証明書の状態を確認するため、AppleのOCSPサーバーに問い合わせを行う仕組みが採用されていました。

処理の流れを簡単に表すと次のようになります。

1 アプリ起動
↓
2 証明書の状態を確認
↓
3 OCSPサーバへ問い合わせ
↓
4 応答が返る
↓
5 アプリを実行

ところが、OCSPサーバー側に負荷がかかり応答が遅れたため、4の応答が返ってこず、アプリを実行することができない状態になってしまったのです。

つまり、証明書の安全性を確認するための仕組みそのものが、サービスの可用性に影響を与えてしまうという問題があるのです。

このほかにも、認証局の審査不備や運用ミス、申請側による証明書資産の管理不足による期限切れ、脆弱性が指摘された暗号アルゴリズムの継続利用、秘密鍵を更新せずに使い続けるといった問題が過去には発生しています。

証明書の有効期限短縮のメリット

証明書の有効期限が47日であれば、たとえ問題のある証明書が存在したとしても、長期間利用されるリスクを抑えられます。
また、秘密鍵漏えいやドメイン所有者の変更、組織情報の変化といった問題も早期に解消しやすくなります。

つまり、証明書の短期化は、失効確認への依存を減らすための施策とも言えます。

まとめ

TLS証明書の47日化は、単なる運用ルールの変更ではありません。

Bygone SSL問題や失効確認の限界、認証局や利用者による運用上の課題など、長年Web PKIが抱えてきた問題に対し、「問題が起きた後で対処する」のではなく、「問題が長期間残らないようにする」という考え方への転換でもあります。

証明書の有効期限短縮だけを見ると、「更新回数が増えて大変になる」という印象を受けるかもしれません。しかしその背景には、実際に発生してきたさまざまな課題があります。

つまり47日化は、証明書管理を厳しくするための制度ではなく、インターネット全体の信頼性を維持するための仕組みと捉えることができます。

ここまでの背景を知ると、セキュリティ対策はルールそのものではなく、「なぜそのルールが必要なのかを理解すること」が重要であると改めて感じられるのではないでしょうか。

企業における情報セキュリティ教育においても同様のことがいえます。

「パスワードを使い回してはいけない」
「不審なメールを開いてはいけない」

といったルールだけを伝えるよりも、なぜそのルールが必要なのかという背景や事例を理解することで、人は納得し、自ら判断できるようになります。

Selphishの情報セキュリティ教育

神戸デジタル・ラボが提供する標的型攻撃メール訓練・情報セキュリティ教育サービス「Selphish（セルフィッシュ）」では、標的型攻撃メール訓練に加え、情報セキュリティ全般を網羅したeラーニング教育機能を提供しています。

メール訓練に組み合わせて活用することで、訓練による気付きにとどまらず、情報セキュリティ意識と知識の定着、行動変容を促進します。

継続的な人的セキュリティ対策をご検討中の方は、ぜひご活用ください。

詳しくはこちらをご覧ください。

情報セキュリティ教育はこちら

※記載されている会社名、製品名、サービス名、ブラウザ名等は、各社の商標または登録商標です。