
2026年3月15日、SSL/TLS 証明書の状況は大きく変化します。証明書の最大有効期間は398日からわずか200日に短縮されます。 SSLは3月11日から200日間の証明書の発行を開始するこれにより、組織が更新しなければならない頻度が実質的に 2 倍になります。 あなたの会社は 200 日の証明書期限に備えていますか?
何が変わっているの?
2026年3月15日以降に発行される証明書は、新しい200日間の最大有効期間に準拠する必要があります。 (SSLは3月11日から200日間の証明書の発行を開始します。これにより、適切な自動化が導入されていないと、すでに要求の厳しい更新プロセスがまったく管理不能なものになってしまいます。
これは一度きりの調整ではありません。業界は100日や1000日といった、さらに短い寿命へと向かっています。 最終的には47日間の証明書が2029年3月15日までに到着する証明書ライフサイクルの短縮が加速するにつれ、今すぐに自動化を導入する組織は、依然として手動プロセスに依存している組織よりも、証明書管理を成功させる上ではるかに有利な立場に立つことになります。
SSLのACMEソリューションが200日間のデジタル証明書の準備をする方法
SSLのサポート ACME(自動証明書管理環境)プロトコル まさに今、組織が必要としているメリットです。ACMEは、発行、更新、インストールを含む証明書ライフサイクル全体を自動化します。手動による介入を排除し、証明書を常に最新の状態に保ちます。
SSL.com による自動証明書管理によって実現されるものは次のとおりです。
- ゼロタッチ更新: 一度設定すると、ACMEは手動での更新サイクル全体を自動的に管理します。 CSR 生成、検証手順、インストールなど、すべての手順を省略できます。証明書は毎回、スケジュールどおりに、例外なく更新されます。
- シームレス統合ACME は、cPanel、Plesk、Kubernetes、クラウド インフラストラクチャなどの広く使用されているプラットフォームと連携し、環境を大幅に変更することなく既存のワークフローに直接適合します。
- 拡張性: 管理する証明書が10個でも1万個でも、ACMEは容易に拡張できます。インフラストラクチャが拡張されても、証明書管理はシンプルさを保ちます。
- ダウンタイムリスクの軽減自動化により、突然の有効期限切れの脅威がなくなります。週末の緊急更新もなくなり、顧客の信頼を損なうセキュリティ警告もなくなります。
- 将来を見据えたアプローチ: 業界が 100 日または 47 日の証明書に移行すると、中断なくさらに短い有効期間を処理できるインフラストラクチャがすでに整っていることになります。
証明書管理の自動化を開始するには、今すぐ SSL にお問い合わせください。
なんでこんなことが起こっているの?
この変更は、SSLを含む個々の認証局の決定ではありません。これは、業界全体の要件であり、公的に信頼されているすべての認証局に求められています。 CA/ブラウザフォーラム(CABF)は、認証局、ブラウザベンダー、オペレーティングシステムプロバイダーで構成される管理機関であり、 ベースライン要件 公的に信頼されたSSL/TLS 証明書。
証明書の有効期間が短くなる理由は明らかです。
- セキュリティの強化証明書の有効期限を制限することで、証明書が侵害されたり誤発行されたりした場合のリスクを軽減できます。鍵を頻繁に交換するのと同じように考えてみてください。鍵の流通期間が短ければ短いほど、全体的なリスクは低くなります。
- 暗号化の俊敏性の向上証明書の有効期限が短くなることで、新しいアルゴリズムやセキュリティ基準の更新が容易になります。量子コンピューティングの脅威が拡大するにつれ、証明書を迅速にローテーションする能力がますます重要になります。
- より強力な検証手法: 更新頻度が上がると、ドメインと組織の検証がより定期的に行われることになり、証明書所有者の正当性と認可の維持が保証されます。
これらの改善はインターネット全体のセキュリティを強化する一方で、自動化をまだ導入していない企業にとっては、運用上の大きな課題となる可能性があります。200日間のデジタル証明書への移行により、更新回数、検証要件、そして人為的ミスの発生機会が倍増します。
手動証明書管理の実際のコスト
200 日間の世界では、手動での証明書管理がどのようになるかについて率直に考えてみましょう。
- 継続的な更新サイクル: 2倍以上の頻度で更新することになり、 CSR 生成、検証、インストール、およびテスト。
- 証明書の有効期限切れのリスクが高い更新期間が短縮されるにつれ、ミスを許容する余地は消滅します。たった一度の更新漏れでも、ウェブサイトの停止、APIの不具合、顧客離れにつながるセキュリティ警告、そしてコンプライアンス違反の可能性につながる可能性があります。
- チームの燃え尽き症候群ITスタッフとDevOpsスタッフは証明書の管理に多くの時間を費やし、戦略的な業務に費やす時間が減ることになります。証明書関連のトラブルへの対応は例外的なものではなく、日常的なものとなり、エラーの増加につながります。
解決策は、人員を増やしたり、労働時間を延ばしたりすることではありません。証明書のライフサイクル全体をお客様に代わって管理する自動化ツールを導入することです。
今すぐ準備しましょう: 次は2027年3月
SSL.comは、期限前に証明書プロファイルを自動的に更新し、証明書ライフサイクルの今後の変更に対応いたします。また、現在お持ちのお客様は、年間購入期間の残り期間をカバーするため、代替証明書をリクエストいただけます。
前述の通り、200日間の移行は始まりに過ぎません。2027年3月15日には、デジタル証明書の有効期間が再び短縮されます。次回の短縮期間はわずか100日です。つまり、200日間の要件に対応しつつも、依然として手動プロセスに依存している組織は、12ヶ月後にはさらに大きなプレッシャーにさらされることになります。
今すぐ行動を起こしましょう。SSLのACMEソリューションが、証明書管理を自動化し、ビジネスを保護し、ライフサイクルのあらゆる変化に先手を打つ方法をご確認ください。
その他の鍵 CABFベースライン要件 2026年3月15日発効の変更点:
|
コンプライアンス |
セクション |
概要説明(詳細は全文を参照) |
|
2026-03-15 |
3.2.2.4 |
プライマリネットワークによるドメイン認可または制御の検証に関連するすべてのDNSクエリに対して、IANA DNSSECルートトラストアンカーへのDNSSEC検証を実行する必要があります。 |
|
2026-03-15 |
3.2.2.4 |
CA は、ドメイン認証または制御の検証に関連する DNS クエリで DNSSEC 検証を無効にするためにローカル ポリシーを使用してはなりません。 |
|
2026-03-15 |
3.2.2.8.1 |
プライマリ ネットワーク パースペクティブによって実行される CAA レコード検索に関連付けられたすべての DNS クエリに対して、IANA DNSSEC ルート トラスト アンカーへの DNSSEC 検証を実行する必要があります。 |
|
2026-03-15 |
3.2.2.8.1 |
CA は、CAA レコード検索に関連する DNS クエリで DNSSEC 検証を無効にするためにローカル ポリシーを使用してはなりません。 |
|
2026-03-15 |
3.2.2.8.1 |
プライマリ ネットワーク パースペクティブによって観測された DNSSEC 検証エラー (例: SERVFAIL) は、発行許可として扱われてはなりません。 |
|
2026-03-15 |
4.2.2 |
CA は、IP 逆ゾーン サフィックスで終わるドメイン名を含む証明書を発行してはなりません。 |
|
2026-03-15 |
4.2.1 |
サブジェクト ID 情報検証の最大データ再利用期間は 398 日です。 |
|
2026-03-15 |
4.2.1 |
ドメイン名と IP アドレスの検証の最大データ再利用期間は 200 日です。 |
|
2026-03-15 |
6.3.2 |
加入者証明書の最大有効期間は 200 日です。 |
|
2026-03-15 |
7.1.2.4 |
CA は、事前証明書を発行するために事前証明書署名 CA を使用してはいけません。また、CA は、セクション 7.1.2.4 で規定されている技術的に制約された事前証明書署名 CA 証明書プロファイルを使用して証明書を発行してはいけません。 |