かつては3年、そして2年、1年へと短縮され、現在はさらに短い期間への移行が議論されています。重要なのは、正確な日数ではありません。問題の本質は「更新頻度が増える」という一点に集約されます。

更新頻度が増えるということは、
更新作業の回数が増えるということです。

更新作業の回数が増えるということは、
人的ミスの確率が上がるということです。

ここに自動化の必然性があります。

なぜ有効期間は短縮され続けるのか

証明書の有効期間短縮は、セキュリティ強化という大義のもと進められています。暗号アルゴリズムの変化、鍵管理の高度化、失効処理の迅速化など、インターネット基盤の信頼性を高める目的があります。

仮に秘密鍵が漏えいした場合、有効期間が短ければ被害の持続期間も短くなります。また、組織情報の正確性確認も、より頻繁に行われることになります。これは理論的には合理的な方向性です。

しかし運用現場に目を向けると、別の現実が見えてきます。

証明書の更新は、単なるボタン操作ではありません。
CSR生成、ドメイン認証、証明書取得、サーバ反映、再起動確認、チェーン確認、疎通確認。

これらを半年ごと、あるいはそれ未満の周期で実施することは、実務負荷として決して軽くありません。

だからこそ、ACMEによる自動更新が「推奨」から「前提」へと変わりつつあるのです。

ACMEとは何か──自動更新の基盤

ACME（Automatic Certificate Management Environment）は、証明書の発行・更新・失効をAPIで自動化するための標準プロトコルです。Let’s Encryptの普及により広く知られるようになりましたが、現在は商用認証局でも対応が進んでいます。

ACMEの本質は、人間の手作業を排除することにあります。

サーバにACMEクライアントを設置し、定期実行（cronなど）を設定することで、証明書の更新は自動的に行われます。期限が近づくと新しい証明書が取得され、既存証明書と置き換えられます。

これにより、更新忘れによるサイト停止リスクを大幅に低減できます。

問題は、「どのACMEサービスを選ぶか」です。

DigiCertのACME運用モデル

DigiCertは、エンタープライズ市場を主戦場とするグローバル認証局です。そのACME対応は、単なる自動更新機能ではなく、証明書ライフサイクル管理全体の一部として設計されています。

多くのケースでは、CertCentralという統合管理コンソールを中心に運用が構築されます。このコンソールでは、証明書の発行状況、更新履歴、承認フロー、監査ログなどが一元管理されます。大規模組織におけるガバナンス要求に応える設計です。

つまりDigiCertのACMEは、「組織統制の中に組み込まれた自動化」です。

ただし、この管理基盤は主にエンタープライズ向け契約と親和性が高く、小規模導入や単一ドメインの自動化ではやや構成が重くなる可能性があります。ACME機能単体だけを軽量に利用するというよりも、包括的な契約の中で活用するイメージです。

その代わり、複数部署を横断する管理や、厳格な承認プロセス、内部監査対応などが求められる環境では非常に強力です。

ACME | 統合パートナー | DigiCert

DigiCert® CertCentral と Trust Lifecycle Manager は、ACME および ACME 更新情報（ARI）プロトコルをサポートしているため、デジサート証明書の発行と更新の自動化が可能です。

www.digicert.com

FujiSSL-ACMEの設計思想

FujiSSL-ACMEは、より実務に寄り添った設計がされています。

最大の特徴は、1ライセンスから導入できる点にあります。大規模契約を前提とせず、特定ドメインのみを自動更新対象とすることも可能です。これは、中小規模の事業者や、特定の重要サービスだけを自動化したいケースに適しています。

管理コンソールの構築を必須とせず、ACMEアカウントの発行、クライアントツールの設置、定期実行設定というシンプルな構成で導入できます。

設計思想は明確です。

「軽量で、確実に、自動更新へ移行できること。」

決済はクレジットカードによるサブスクリプション方式のみ対応しています。これは大企業の購買フローとはやや相性が分かれるかもしれませんが、技術部門主導で迅速に導入できるという利点があります。

自動更新（ACME） | FujiSSL-安心・安全の格安SSLサーバ証明書

最新のセキュリティでウェブサイトを保護しながら、証明書管理がこれまで以上に簡単に！ FujiSSLのACME対応により、証明書の発行・更新がすべて自動化され、スムーズな運用が可能です。 FujiSSL ACME 導入の必要性 SSL証明書の...

www.fujissl.jp

比較

規模と統制を重視するならDigiCert。一方、少数ドメインから段階的に自動更新へ移行したい場合、FujiSSL-ACMEは導入ハードルが低く、現場に馴染みやすい構成といえます。

結論──自動化は避けられない

有効期間短縮は止まりません。
更新頻度は増えます。
手動更新はリスクになります。

選択肢は「自動化するかどうか」ではなく、
「どの形で自動化するか」です。

エンタープライズ統制を最優先にするならDigiCert。
軽量で機動的に自動更新へ移行したいならFujiSSL-ACME。

重要なのは、規模に合った判断です。

カウントダウンは、すでに始まっています。

はじめに

2023年から2025年にかけて、SSL/TLSサーバ証明書業界において、ルート証明書および中間証明書の大規模な更新が相次いで実施されました。業界全体として見ても、これほど広範囲に渡るルート・中間証明書の移行は稀であり、ユーザーや企業にとっては運用上の配慮や再確認が求められる重要な時期と言えます。

この記事では、業界で主に使用されている三大ブランド「DigiCert」「GlobalSign」「FujiSSL」を例に、それぞれの証明書チェーンの構造や更新前後の違い、なぜ今このタイミングでルート更新が必要だったのか、その背景を丁寧に解説していきます。また、ルート認証局（Root CA）選定がWebサイトやサービスの信頼性に与える影響についても触れつつ、更新された階層構造がどのような意図で設計されたかを紐解いていきます。

SSL証明書の基礎と階層構造の重要性

SSL証明書の信頼性は、「ルート証明書（Root CA）」を頂点とする証明書の階層構造（証明書チェーン）によって担保されます。

この構造は以下のように構成されます。

• ルート証明書（Root Certificate）
  信頼の最上位。OSやブラウザに事前にインストールされている。
• 中間証明書（Intermediate Certificate）
  ルート証明書から発行され、エンドエンティティ証明書との間を中継。
• エンドエンティティ証明書（Leaf Certificate）
  Webサーバにインストールされる証明書。

ルート証明書の信頼は絶対的であり、その管理・運用には非常に高いセキュリティ要件が課せられています。

なぜ今、ルート・中間証明書の更新が必要なのか

今回の更新には、以下のような背景があります。

1. セキュリティ要件の厳格化（CA/Bフォーラムの勧告）
   • 有効期間の短縮（825日ルール→90日ルール）
   • 暗号アルゴリズムの進化（RSA 2048bit以上、ECDSA対応など）
2. 古いルート証明書の期限切れとサポート終了
   • 各ルート証明書には有効期限がある。
   • 期限切れ前に新しいルートへ移行することで信頼を継続。
3. 新しいプラットフォームやデバイスへの対応
   • モバイル・IoT環境での互換性確保

これらの要因が重なり、各認証局は自社の証明書体系を見直し、より長期的に安定した信頼性を確保できる新しいチェーンを整備する必要に迫られました。

各ブランドの証明書階層構造の比較

以下に、各ブランドの更新前・更新後の証明書チェーン構造を紹介します。

DigiCert

更新前

• Root：DigiCert Global Root CA
• Intermediate：DigiCert TLS RSA SHA256 2020 CA1

更新後（2024年以降）

• Root：DigiCert Global Root G2（G3）
• Intermediate：DigiCert TLS RSA SHA256 2024 CA1 など

コメント

DigiCertではルートG2やG3への移行を進めており、一部用途において新しい仕様にも対応していますが、構造としては従来と大きく変わらない印象です。一般的なWeb用途では大きな違いを感じにくく、必要十分といったところでしょう。

GlobalSign

更新前

• Root：GlobalSign Root R3
• Intermediate：GlobalSign RSA OV SSL CA 2018 など

更新後

• Root：GlobalSign Root R6
• Intermediate：GlobalSign RSA OV SSL CA 2024 など

コメント

GlobalSignでは、証明書管理の利便性向上に向けてルートR6への切り替えが始まっていますが、階層構造の刷新というよりは従来の踏襲に近い形で、インフラ的なアップデートが中心となっています。

FujiSSL

更新前

• Root：USERTrust RSA Certification Authority
• Intermediate：FujiSSL SHA2 Domain Secure Site CA など

更新後（2025年1月27日以降）

• Root：USERTrust RSA Certification Authority
• CrossRoot：Sectigo Public Server Authentication Root R46
• Intermediate：FujiSSL RSA Domain Validation Secure Server CA 2

※ 上記2つのルート証明書から中間CAを共有する「クロスルート構成」であり、異なるクライアント環境に応じて適切なルートを選択できる柔軟なチェーン設計です。

中間証明書・ルート証明書切り替えのお知らせ | FujiSSL-安心・安全の格安SSLサーバ証明書

いつも弊社のSSLサービスをご利用いただき、誠にありがとうございます。このたび、弊社が提供するSSLサーバ証明書において、中間証明書およびルート証明書の切り替え（変更）を実施いたします。 なぜ切り替えるのか？ 本対応は、最新のセキュリティ基...

www.fujissl.jp

コメント

  ┌ USERTrust RSA Certification Authority
  │
  └ Sectigo Public Server Authentication Root R46
     └─ FujiSSL RSA Domain Validation Secure Server CA 2
        └─ エンドエンティティ証明書（例：*.example.com）

上記のクロスルートの階層構造により、最新のOSやブラウザへの適合と、既存環境との互換性を両立しています。信頼性、将来性、互換性のバランスを図った更新であり、Web環境の多様化に対応した構造と言えます。

階層構造の違いがもたらす実務への影響

• OSやブラウザにおけるルート認識の差異
  • 古いルートはサポート対象外のリスクがある（例：Android 7以前など）
• 証明書チェーン構築の失敗による接続エラー
  • 適切な中間証明書の設置が重要
• 自動更新スクリプトやAPIとの整合性
  • ACMEなどの自動化処理ではチェーンの変更が障害になるケースも

ルート認証局選定と信頼性への影響

エンドユーザーにとっては、どの認証局の証明書を選ぶかがWebサイトの信頼性やアクセス性に直結します。特にルート証明書の普及度や認定状況は以下の点で重要です：

価格面や日本語サポートの観点から見ると、FujiSSLは現実的な選択肢として多くの企業に受け入れられやすい構成です。中堅・中小企業でも導入しやすいバランスが整っており、証明書選定において重要なポイントをおさえている印象です。

おわりに

SSL/TLS証明書の更新において、ルート証明書・中間証明書の理解は不可欠です。今回のような業界全体の動きを受けて、各ブランドはセキュリティ強化と将来性を見据えたチェーンへの移行を進めています。

DigiCertは新しいルートG2やG3への移行を進めていますが、構造的な刷新よりも従来の形式を維持しながらの更新という印象が強く、既存の利用環境を大きく変えることなく対応しているといえます。GlobalSignも同様に、ルートR6を中心とした移行を進めていますが、階層設計としては大きな変化を伴わない構成であり、機能面のアップデートが主軸となっています。

一方でFujiSSLにおいては、異なるルート証明書を併用できるクロスルート構成を取り入れることで、旧環境との互換性を保ちつつ、将来的なブラウザやOSの変化にも柔軟に対応できる仕組みを備えています。信頼性、コスト、互換性、日本語サポートといった実務的な観点を総合的に満たしており、多様な現場で扱いやすい構成が特長です。

証明書の選定においては、単にブランドの知名度だけでなく、自社の利用環境や運用リソース、セキュリティポリシーに合った設計を見極めることが重要です。今後も変化するインターネットの信頼基盤に柔軟に対応するために、最新の証明書階層構造への理解を深め、継続的な見直しと対応を怠らない姿勢が求められます。