【皆さんのTLS（SSL）証明書は大丈夫？】段階的に有効期間が短くなっていく中で、行うべき対策を解説

こんにちは、ゼノクリース合同会社の齋藤です。このコラム記事では、企業のWebガバナンスや最新情報について紹介しています。

私の経験上、Webサイトが突然表示されなくなる原因は、WordPressプラグインの不具合やプログラムのエラーだけでなく、むしろSSL証明書の更新が原因であることが多いです。変更と同時に動かなくなるのではなく、「サイトを編集していないのに、ある日期限が切れて表示されなくなった」という形なので、むしろプログラムのエラーよりも怖い印象があります。

「SSL証明書の更新?毎年やってるから大丈夫だよ」

そう思っている方に、重要な情報があります。2026年3月15日から、TLS証明書の最大有効期間が398日から200日に短縮されます。そして、2029年3月15日には最大47日になります。

これは「いつか対応すればいい」話ではありません。あと1ヶ月半後に始まる話です。

そもそも「SSL」と「TLS」は何が違うのか？

冒頭で「SSL証明書」と書きましたが、本文では「TLS証明書」と表記しています。この違いについて、まず整理しておきましょう。

SSL (Secure Sockets Layer) は、1990年代にNetscape社が開発した暗号化通信プロトコルです。Webブラウザとサーバー間の通信を暗号化し、盗聴や改ざんを防ぐ目的で作られました。

しかし、SSLにはセキュリティ上の脆弱性が発見され、SSL 2.0は2011年に、SSL 3.0は2015年に廃止されています。

参考:

• RFC 6176
• RFC 7568

現在使われているのは、SSLの後継として開発された TLS (Transport Layer Security) です。TLS 1.0は1999年に策定され、現在は TLS 1.2(2008年)と TLS 1.3(2018年)が主流です。

つまり、技術的に正確な表現は「TLS証明書」ですが、SSLという名称が長く使われてきた歴史から、今でも「SSL証明書」「SSL/TLS証明書」と呼ばれることが多いのです。この記事では、正式名称である「TLS証明書」を使用します。

【スケジュール】証明書は、段階的に短縮されてくる・・・

以下が、今後の短縮スケジュールです。

適用開始日	証明書の最大有効期間	ドメイン検証の再利用期間	年間の更新回数目安
〜2026/3/14	398日	398日	約1回
2026/3/15〜	200日	200日	約2回
2027/3/15〜	100日	100日	約4回
2029/3/15〜	47日	10日	約8回

2029年以降はドメイン検証の再利用期間がわずか10日になるという点にも注目です。証明書を更新するたびに、ほぼ毎回ドメインの所有権確認が必要になります。

47日という数字は一見すると中途半端ですが、

47日 = 31日(最大月の日数) + 15日(半月分の猶予) + 1日(調整)

という計算になっています。

なぜ、TLS証明書は短縮されるのか？

CA/B Forumがこの短縮を決めた背景には、以下の理由があります。

1) 秘密鍵漏えい時のリスク期間を制限

証明書の有効期間が長いほど、万が一秘密鍵が漏えいした場合の「悪用可能な期間」も長くなります。有効期間を短くすることで、被害を限定できます。

2) 証明書情報の鮮度維持

証明書に含まれる組織情報は、発行時に認証局が審査した内容です。時間が経過するほど、その情報が変更されている可能性が高まり、信頼性が低下します。

また、TLS証明書は発行されているものの、使用されていないサイトも多いです。そのため、証明書の有効期間を短くすることで今生きている証明書の数を削減できます。

3) 新しい暗号規格への迅速な対応

将来、現在の暗号方式が脆弱になった場合(量子コンピュータが発達して、RSAやSHA-1がすごい計算力で破られるようになったようなケースなど)、短い有効期間であれば、新しい暗号方式への移行を素早く行えます。

TLS証明書への対応は、属人作業から「自動化+監視+棚卸し」へ

では、どのように対応すればよいでしょうか。およそ年に一回であれば手動で更新するのも良いですが、47日間になることに備えて自動化するのが良いでしょう。

ステップ1: 現状の棚卸し

まず、自社で管理している証明書を棚卸ししましょう。

「証明書の管理台帳がない」という会社は、まずここから始めると良いです。

ステップ2: ACMEプロトコルによる自動化

証明書の自動更新を実現する標準プロトコルが ACME(Automated Certificate Management Environment) です。IETFが標準化したRFC 8555として定義されています。

ACMEを使えば、以下の流れを自動化できます。

代表的なACMEクライアントは Certbot です。多くのOSで動作し、ドキュメントも充実しています。

参考：動作の仕組み – Let’s Encrypt

ステップ3: 監視体制の構築

自動化しても、「本当に更新されているか」の監視は必要です。これらのような項目です。

「自動化したから安心」ではなく、「自動化+監視」までセットで行うと良いです。

KUSANAGIでLet’s Encryptを使った証明書を自動更新

超高速&セキュアなCMS実行環境「KUSANAGI」では、Let’s Encryptを使った証明書の自動取得・自動更新が標準で組み込まれています。

# 証明書の取得

    kusanagi ssl --email your@email.com プロファイル名

    # 自動更新の有効化

    kusanagi ssl --auto on

このコマンドだけで、cronによる自動更新が設定されます。手動での更新作業は不要です。

参考:

• kusanagi sslで簡単にSSL設定を行う | KUSANAGI Tech Column
• ssl – 超高速CMS実行環境 KUSANAGI

商用証明書 (OV/EV) を使っている場合

Let’s EncryptはDV(ドメイン認証)証明書のみを発行します。OV(組織認証)やEV(拡張認証)証明書を使っている企業は、別の対策が必要です。

多くの商用認証局は、年間サブスクリプション型の料金体系に移行しています。証明書の交換頻度が増えても追加料金は発生しないケースが多いですが、自動化の仕組みは自社で構築する必要があります。

2026年3月15日まで、あと約1ヶ月半！

「2029年の47日までにはまだ時間がある」と思うかもしれません。しかし、200日でも年2回の更新が必要になります。今のうちに自動化の体制を整えておき、余裕を持って対応できるように進めていくことがおすすめです。

プライム・ストラテジーでは、WordPressサイトの運用標準化を支援するサービスを提供しています。

• 証明書管理を含めた運用を標準化したい方： CMS/Webプラットフォーム統合サービス
• 「社内に詳しい人がいない」「運用を丸ごと任せたい」方： KUSANAGIマネージドサービス

証明書の更新は、これまで「年に1回の定型作業」でした。しかし、これからは「自動化されていて当たり前」の時代になります。

この機会に、証明書管理を「属人作業」から「自動化+監視+棚卸し」の体制への移行を検討してみてください。