2025年4月にサーバ証明書の最大有効期間が段階的に短縮されることが、CA/Browserフォーラムによって決定されました。この決定により、パブリックの認証局で発行されたサーバ証明書の更新頻度は大幅に増加し、手動での更新は今まで以上に運用負荷が高まります。
本記事では、証明書管理の自動化を実現するプロトコルである ACME(Automatic Certificate Management Environment)とF5 BIG-IPを組み合わせたサーバ証明書の自動更新についてご紹介します。
- ライター:津久井 俊也
- 2020年、ネットワンシステムズに入社。
入社当初は、CiscoのCatalystスイッチに関する性能/機能検証、案件支援などの業務を主に担当。
2022年度からF5製品の担当として活動中。
目次
1. サーバ証明書 最大有効期限の短縮について
インターネットのセキュリティ強化を目的とした世界的な取り組みの一環として、GoogleやAppleはサーバ証明書の最大有効期間を短縮する提案を行いました。この方針は2025年4月にCA/Bフォーラム(Certification Authority/Browser Forum)で正式決定されました。
2026年3月15日以降、パブリックの認証局で発行されたサーバ証明書の最大有効期間は段階的に短縮される予定です。
| 証明書の発行日 | 最大有効期限 |
| 2026年3月15日 まで | 398日間 |
| 2026年3月15日 から 2027年3月15日 まで | 200日間 |
| 2027年3月15日 から 2029年3月15日 まで | 100日間 |
| 2029年3月15日 以降 | 47日間 |
(最新のベースライン要件 |CA/ブラウザフォーラム より)
サーバ証明書の最大有効期間が短縮されることで、古い暗号化方式や鍵長を使用した証明書が長期間利用されるリスクを軽減できるメリットがあります。一方でサーバ証明書の更新頻度が高くなるため、手動で更新を行っている環境では、更新漏れや作業ミスが発生しやすくなり、場合によってはサービス用通信に影響を与える可能性があります。
2. ACMEプロトコルとKOJOT-ACMEについて
ACME(Automatic Certificate Management Environment)はRFC8555で定義された、証明書の管理を自動化するプロトコルです。ACMEを利用する事により、サーバ証明書の更新を自動化することができます。
ACMEを利用するには、下記3つを準備する必要があります。
- ACMEプロトコルに対応した認証局(CA):Let's Encrypt等
- ACMEクライアント:acme.shやCertbot等
- ドメイン検証に使用するDNSサーバまたはWEBサーバ:実装方法によって選択
F5では、BIG-IPで利用できるACMEクライアントとして、KOJOT-ACME(acme.sh)を提供しています。KOJOT-ACMEはメーカサポートの対象外にはなりますが、無償で利用することができます。
3. KOJOT-ACMEによるサーバ証明書の自動更新
今回はリバースプロキシ構成のBIG-IPを用いて、サーバ証明書の自動更新を検証しました。
サーバ証明書を自動更新するには、自身が対象ドメインの所有者であることを認証局(CA)に証明する必要があります。本検証では、KOJOT-ACMEで対応している認証方式として、HTTP-01とDNS-01の2つを使用して動作を確認しました。
- HTTP-01 : ACMEクライアントを利用して認証局から発行したチャレンジトークンを指定されたURLに配置します。認証局がそのURLにアクセスしてトークンを確認できれば、ドメインの所有者として認証されます。
- DNS-01 : チャレンジトークンをDNSサーバのTXTレコードに登録することで、認証局がDNSサーバを通じてドメイン所有者を確認します。
それぞれの認証方式に対応するためには、BIG-IPで以下の設定が必要となります。
(1)BIG-IPで必要な設定
設定ファイルの設定
KOJOT-ACMEの設定ファイルで認証方式を指定します。必要に応じてコメントアウトを解除してhttp-01もしくはdns-01を有効化する必要があります。
## Option to select the ACMEv2 methods: http-01 (default) or dns-01 ## ACME_METHOD="http-01" ACME_METHOD=dns-01
HTTP-01用バーチャルサーバ(port80)の構築 ※HTTP-01の場合のみ
対象ドメインに対応するHTTP(Port 80)バーチャルサーバをBIG-IP上に作成し、KOJOT-ACMEに含まれる専用のiRuleを適用します。このバーチャルサーバは認証局がトークンの保管先にアクセスする際に使用されます。
DNSサーバとのAPI連携 ※DNS-01の場合のみ
本検証では、F5 Distributed Cloud Services(以降、略称のF5 XC Servicesと表記)をDNSサーバとして使用しています。
GitHubで公開されているF5 XC Services専用のスクリプトをBIG-IPにインポートする事でBIG-IPとF5 XC Services間でAPI連携することができます。これにより、サーバ証明書の新規作成と更新時に必要なTXTレコードの登録・削除を自動化できます。
データグループの設定
BIG-IPのDataGroupに対象ドメインと認証局のAPIエンドポイントを登録します。
(2)動作確認
f5acmehandler.shを実行すると、初回は証明書やRSA鍵が存在しない為、サーバ証明書とRSA鍵が新規作成されます。
定期的にサーバ証明書の有効性を確認したい場合は、f5acmehandler.shの実行時にscheduleコマンドのオプションを追加します。
例えば、毎週月曜日の18時に証明書の有効性を確認したい場合には、「./f5acmehandler.sh --schedule "00 18 * * 1"」コマンドを実行します。Scheduleオプションが設定されるとそのタイミングでサーバ証明書の更新が必要と判断された際に、自動でサーバ証明書が更新されます。
下記例では、動作確認の為に一部の閾値を変更して、通常よりも早いタイミングでサーバ証明書を自動更新しています。
4. Application Study Toolとの組み合わせ
過去のブログでもご紹介した Application Study Tool を併用することで、BIG-IPにインポートされている証明書を1つの画面で可視化できます。さらに、証明書の有効期限に応じて色分けされるため、視認性も高くなっています。具体的には、利用可能な期間に余裕がある場合は「緑」、期限が近づいている場合は「黄」、期限を超過している場合は「赤」で表示されます。また、これらの期限に関する情報はリアルタイムで反映されます。
5. まとめ
KOJOT-ACMEとBIG-IPの連携により、サーバ証明書の自動更新を実現しました。今後、サーバ証明書の最大有効期限は段階的に短縮される中で、証明書管理の自動化は、更新漏れや作業ミスによるセキュリティリスクの増加や、サービス停止を防ぐ有効な手段だと感じました。今回の検証では、ドメイン所有者の認証方式としてHTTP-01とDNS-01の2つの方式を使用しましたが、それぞれに特性があり、運用環境に応じて最適な認証方式を選定する必要があります。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
