SSL/TLS証明書の「有効期間47日短縮」問題とは?
2026年以降、SSL/TLSサーバ証明書の最長有効期間を「最長47日」へ短縮する動きが急速に進んでいます。
これまで「年1回の更新」で済んでいた証明書管理ですが、47日短縮化が適用されると年間8回以上の更新作業が必要になります。手動更新を続けている場合、運用負荷の大幅な増加はもちろん、「更新忘れによるサイト停止(証明書切れ)」という深刻なビジネスリスクに直面することになります。
この短期間化の対策として、証明書運用の自動化を検討するケースが多くなりました。
ACMEプロトコルなどを用いて、サーバーが自動で証明書を更新し続ける仕組みが構築できていれば、期限は問題にはなりません。
しかし、すべてのサーバー環境でこの自動化が容易に実現できるわけではありません。
自社サーバーにおける自動化の障壁
自社サーバー(オリジンサーバー)側で自動更新を実装・維持しようとする際、以下のような課題が生じることがあります。
- システムの制約: 利用しているOSやミドルウェアが古く、自動更新ツールが動作しない。
- ネットワークポリシー: 更新時の認証に必要な外部通信(ポート80番の開放等)を許可できない。
- 運用コスト: 自動更新プログラムが正常に動作しているかを監視し、エラー時に対応する体制を新たに整える必要がある。
このように「自社側での完全自動化」が難しい環境において、Cloudflareの導入 は有力な選択肢となります。
Cloudflareによる「運用の分離」がなぜ解決策になるのか?
Cloudflareを導入すると、Webサイトの通信区間が以下の2つに分離されます。

- ① 【閲覧者 ⇔ Cloudflare】の通信(エッジ証明書)
ブラウザ側が求める短命なSSL証明書をCloudflareが自動発行・管理します。 - ② 【Cloudflare ⇔ 自社サーバー】の通信(オリジン証明書)
ブラウザの有効期限ルールが適用されないため、長期間有効な証明書を利用できます。
この「運用の分離」により、自社サーバー側の複雑な自動化を行わずに、証明書問題を根本から解決できます。
Cloudflareで利用できるエッジ証明書の種類
通信のフロントエンド(閲覧者とCloudflareの間)で利用される「エッジ証明書」には、要件や規模に応じて主に3つの選択肢があります。
| 証明書タイプ | 費用 | 認証レベル | 自動更新 | 主な特徴・使い分け |
|---|---|---|---|---|
| Universal SSL | 無料 | DVのみ | ◯(完全自動) | 標準で利用可能。一般的なWebサイトやブログなどに最適。 |
| Advanced Certificate Manager (ACM) | 有料オプション | DVのみ | ◯(完全自動) | 1ゾーン最大100枚作成可能。複数サブドメイン管理やTLSバージョンの細かい制御が必要な中〜大規模サイト向け。 |
| Custom Certificate (カスタム証明書) | 持込費用等 (Enterprise等で無料枠あり) | DV / OV / EV | ×(手動更新) | 自社で発行・購入した外部証明書をアップロードして利用。企業認証(OV)やEV証明書が必須の場合に使用。 |
※Cloudflareが直接提供・自動発行する証明書は「DV(ドメイン認証)」のみとなります。組織認証(OV)や拡張認証(EV)が必要な場合は、カスタム証明書を準備して持ち込む必要があります。
各エッジ証明書の特徴の詳細
1. Universal SSL(無料・標準機能)
Cloudflareを利用する全ユーザーに無料で提供される標準証明書です。
- フルセットアップ時: ネイキッドドメインおよび1階層上のサブドメインに対応(例:
example.com、*.example.com)。 - CNAMEセットアップ時: FQDNごとに証明書が個別に生成されます。
2. Advanced Certificate Manager:ACM(有料オプション)
より高度な証明書構成や柔軟な設定が求められる企業向けのオプションです。
- 1ゾーンあたり最大100枚の証明書を作成可能
- 1つの証明書につき最大50個のSAN(主体者代替名)を設定可能
- TLSバージョンやCipher Suite(暗号化アルゴリズム)の細かな制御・チューニングが可能
3. Custom Certificate:カスタム証明書(持ち込み)
既存のOV/EV証明書を使い続けたい場合や、特定の認証局(CA)を指定したい場合に使用します。自動更新の対象外となるため、有効期限の管理は自社で行う必要があります。
バックエンド(オリジンサーバー間)を守る「Origin CA証明書」
Cloudflareと自社サーバー間の通信保護(上図②の区間)には、Cloudflareが独自に提供している「Origin CA証明書」の活用が推奨されます。
15年間更新不要!サーバー側の手間解消
Origin CA証明書をCloudflareダッシュボードで発行し、自社サーバーにインストールしてもらうだけで、その区間のSSL通信が確立されます。最大の特徴は、最長15年の有効期限が設定可能な点です(3年・2年・1年なども選択可能)。
- 長期的な運用負荷軽減: サーバー側の証明書入れ替え作業を長期間不要にできます。
- 自社サーバー側の自動化が不要: サーバー側でACMEツールなどの自動更新プログラムを構築・維持する手間をなくせます。
- 確実な暗号化: Cloudflareとオリジン間を確実にフル暗号化できます。

(画像:CloudflareダッシュボードでのOrigin CA証明書発行画面。有効期間を15年に設定可能)
【導入時の前提知識】Origin CA証明書の通信仕様とCloudflareの信頼性
Origin CA証明書は、Cloudflareを導入したWebサイトのセキュリティを簡潔かつ強力に保つための優れた仕組みです。スムーズな運用を行うために、以下の通信仕様とCloudflareの基盤構築への取り組みについて理解しておきましょう。
1. Origin CA証明書の動作仕様(プロキシ機能とセットで利用)
Origin CA証明書は、「Cloudflareのプロキシ機能(DNS設定のオレンジ色の雲マーク)」を通した通信を前提として設計されています。
そのため、もしCloudflareで障害が起きた場合、証明書も無効になります。
- プロキシ機能がON(標準状態):
閲覧者とCloudflare間は「エッジ証明書」、Cloudflareと自社サーバー間は「Origin CA証明書」で通信が安全に暗号化され、正常にアクセスできます。 - プロキシ機能をOFF(DNSを直接オリジンに向けた場合):
Origin CA証明書はCloudflare専用の証明書であるため、ブラウザが直接自社サーバーへアクセスすると証明書を信頼できず、SSLエラーとなります。
このように、「自社サーバー側での証明書更新作業を15年間不要にする」という大きなメリットを得るトレードオフとして、通信は常にCloudflareを経由する構成となります。
2. インフラの安定性を極限まで高める「Project Code Orange」
「常にCloudflareを経由する」という構成になるからこそ、プラットフォーム全体の安定性や可用性(途切れにくさ)が極めて重要になります。
Cloudflareでは、昨年の大規模障害を受け、サービスの継続性を極限まで引き上げるための全社的な品質改革プロジェクト「Project Code Orange」を実施しました。
この取り組みにより、ソフトウェアデプロイプロセスの見直しや設定配信の段階化、障害モードの再設計など、プラットフォーム全体のレジリエンス(障害復旧力・耐性)が根本から強化されています。
Webサイト運営者は、自社で複雑な冗長化構成を組むことなく、Cloudflareの高可動なインフラ基盤の上で安心してOrigin CA証明書を長期運用することが可能です。
詳しい取り組みの内容については、以下のCloudflare公式ブログにて公開されています:
https://blog.cloudflare.com/ja-jp/tag/code-orange/
まとめ:証明書短命化時代の最適解はCloudflare
SSL/TLS証明書の「47日短縮化」により、従来の「年1回の手動更新」運用は限界を迎えます。
特別な理由でOV/EV証明書(カスタム証明書)が必要な場合や、Cloudflareへの極端な依存を避ける高度な冗長設計が必要な場合を除き、大多数のWebサイトでは「Cloudflareのエッジ証明書(Universal SSL / ACM)」による自動更新と、「Origin CA証明書(15年有効)」を組み合わせることで、運用負担と証明書切れリスクをほぼゼロに抑えることが可能です。
CloudflareもCode Orangeプロジェクトにより、より信頼性の高いプラットフォームへと進化しています。証明書の運用更新に課題を感じている場合は、早めのCloudflare移行・導入を検討しましょう。
Web表示スピード改善・セキュリティ対策のCloudflare
導入のご相談だけでなく、運用フェーズでのサポートも承ります。
DDoS攻撃や悪質なBot(ボット)からのアクセスを防ぎたい方、WAF機能やプランの詳細を知りたい方、
国内エンジニアによる安心の運用サポートをご希望の方も、ぜひお気軽にお問い合わせください。

