SSL/TLS証明書の有効期限短縮について
SSL/TLS証明書の最大有効期限の段階的な短縮スケジュールについて以前弊社ブログで紹介させていただきました。今回はそのブログに関連する内容となりますので、まだご覧になられていない方は、まず下記のブログを参照いただけるけると幸いです。
上記ブログでは、SSL/TLS証明書の最大有効期間の短縮スケジュールおよびACMEの紹介、F5の3つのプロダクトにおける証明書有効期限短縮に関する対応状況についての紹介を行いました。
本執筆時点（2026年4月）ではすでに段階的な証明書有効期限の短縮が進み、有効期限は最長で200日（2026年3月15日～）となっています。すでに期限短縮の対応を済ませたお客様も多い一方で、対応方針を検討中の方もいらっしゃるのではないでしょうか。
本ブログでは、BIG-IPに関する証明書自動更新について詳しく解説します。
BIG-IPにおけるSSL/TLS証明書更新自動化ソリューション
先述のブログでも触れておりますが、BIG-IPに導入できるSSL/TLS証明書管理の自動化ソリューションとして、KOJOT-ACMEが提供されています。
KOJOT-ACME
https://github.com/f5devcentral/kojot-acme
KOJOT-ACMEは、BIG-IPにインストールすることが可能なACME v2クライアントです。KOJOT-ACMEを利用することで、証明書の更新および証明書のBIG-IPへのインポート処理を定期実行することができ、BIG-IPにおける証明書管理を容易にします。
※留意事項
KOJOT-ACMEは本ブログ執筆時点※2026/3 でF5 contributed softwareです。メーカおよび弊社のサポート対象外であること予めご了承ください。
次項で、実際にBIG-IPをACME v2クライアントとして動作させるために必要となる設定、Smallstep CAコンテナ（動作確認用にKOJOT-ACMEのGitHubリポジトリでyamlファイルが公開されています）を用いた証明書更新の動作について解説させていただきます。
設定・動作説明 <ACME基本設定>
まず、BIG-IPと認証局となるACMEサーバの関連について簡単に整理したいと思います。
これ以降は下記の構成を前提として説明しますが、動作を確認するためのシンプルな内容なので、ざっくりと構成を理解頂ければ問題ありません。
なお、KOJOT-ACMEはHTTP-01/DNS-01のACMEチャレンジタイプをサポートしておりますが、ここではHTTP-01を用います。
ACME チャレンジとは、証明書更新対象のドメイン所有の確認を行う方法です。HTTP-01の仕組みを簡単に説明すると、Webサーバ/認証局 間でHTTP通信により特定の応答を返せるかどうかで、ドメイン所有していることを証明する方式です。
<本解説におけるBIG-IPのACME動作フロー>
KOJOT-ACMEにおけるHTTP-01チャレンジでは、BIG-IPのHTTP仮想サーバおよびiRuleをACMEサーバからのドメイン所有確認先として利用します。本来であれば、対象のWebサーバへドメイン所有確認のためのページを置く必要がありますが、KOJOT-ACMEではBIG-IPの設定のみでHTTP-01チャレンジを用いた証明書更新を行うことができます。また、BIG-IPでは発行した証明書の配置に加えて、証明書のインポートを行う必要がありますが、KOJOT-ACMEの処理に証明書のインポートまでが包含されています。
認証局（ACMEサーバ）
本動作検証ではSmallstep CAをコンテナで起動し、ACMEサーバとして利用します。
本ブログではACMEサーバについての説明は省略いたします。
DevCentral(メーカコミュニティサイト)で設定手順が公開されておりますので、実際に動作させてみたい方はこちらをご覧ください。
Automating ACMEv2 Certificate Management on BIG-IP
https://community.f5.com/kb/technicalarticles/automating-acmev2-certificate-management-on-BIG-IP/328935
・ACMEv2 Server Setup
BIG-IP（ACMEクライアント）
BIG-IPでACMEを動作させるために必要となる設定は下記となります。
1.KOJOT-ACMEコンポーネントのインストール
2.data group(dg_acme_config)の設定
3.インストールされたACMEクライアントの設定(/shared/acme/config)
4.HTTP仮想サーバ設定
ここまでの設定を行うことでKOJOT-ACMEは動作します。
ただし、ここまでの設定のみでは自動で更新を行うことはできません。スケジューリングを行うことで証明書更新を自動で実施することができます。また、更新実行時の更新の成功/失敗について通知を行うことも可能です。
どちらも実装頂くことが多い機能かと思いますので、この2つについても”設定・動作説明<オプション>”項で解説を行います。
5.スケジュール
6.通知設定
それでは早速設定に進んでみましょう。
1.KOJOT-ACMEコンポーネントのインストール
まずはBIG-IPにSSH接続し、コンポーネントインストールを実行します。
# curl -s https://raw.githubusercontent.com/f5devcentral/kojot-acme/main/install.sh | bash
なお、本検証では下記のKOJOT-ACMEを使用しています。
https://github.com/f5devcentral/kojot-acme/releases/tag/20251217
今回はStandalone構成のBIG-IPで実施しますが、HA環境では両方のBIG-IPインスタンスでこの操作を実行してください。
コマンド実行後、/shared/acmeフォルダに必要なコンポーネントがインストールされます。
# ls /shared/acme/
bin ca-bundle.crt config config_reporting dnsapi f5acmehandler.sh f5hook.sh
#
また、この時点でこれ以降に使用する設定がBIG-IPに投入されます。
参考までに、インストール前後での設定差分としては下記となります。
# diff conf_bf.txt conf_af.txt
> ltm rule /Common/acme_handler_rule {
> when RULE_INIT { set static::DEBUGACME 0 };when HTTP_REQUEST priority 2 {if { [string tolower [HTTP::uri]] starts_with "/.well-known/acme-challenge/" } {set response_content [class lookup [substr [HTTP::uri] 28] dg_acme_challenge];if { $response_content ne "" } { if { $static::DEBUGACME } { log local0. "[IP::client_addr]:[TCP::client_port]-[IP::local_addr]:[TCP::local_port] Good ACME response: $response_content" };HTTP::respond 200 -version auto content $response_content noserver Content-Type {text/plain} Content-Length [string length $response_content] Cache-Control no-store } else { if { $static::DEBUGACME } { log local0. "[IP::client_addr]:[TCP::client_port]-[IP::local_addr]:[TCP::local_port] Bad ACME request" };HTTP::respond 503 -version auto content "<html><body><h1>503 - Error</h1><p>Content not found.</p></body></html>" noserver Content-Type {text/html} Cache-Control no-store };unset response_content;event disable all;return}}
> }
> ltm data-group internal /Common/dg_acme_challenge {
> type string
> }
> ltm data-group internal /Common/dg_acme_config {
> type string
> }
#
上記より
iRule：acme_handler_rule
data group ：dg_acme_challenge
data group ：dg_acme_config
が追加されていることが確認できます。
2.data group(dg_acme_config)の設定
ここではdata groupのdg_acme_configに対して、管理対象ドメイン（証明書のサブジェクト）ごとにエントリを追加します。
設定するエントリはドメインとそれに対応する”--ca”の値(ACMEサーバのディレクトリURL)です。設定内容は認証局の設定によって異なりますが、ここでは前項で起動させたSmallstep CAを指定します。
設定はGUI/CLIいずれからも実施可能です。
今回は下記の設定を行っています。
# tmsh list ltm data-group internal dg_acme_config
internal dg_acme_config
ltm data-group internal dg_acme_config {
records {
fuga.tmxlabs.com {
data "--ca https://<ACMEサーバ>:9000/acme/acme/directory"
}
hoge.tmxlabs.com {
data "--ca https:// <ACMEサーバ>:9000/acme/acme/directory"
}
}
type string
}
#
3.インストールされたACMEクライアントの設定(/shared/acme/config)
プロバイダ設定ファイルの更新を行います。
プロバイダ設定ファイルは、証明書の更新時のACMEクライアント/認証局 間のACMEの動作に関するパラメータを定義するファイルです。チャレンジ方式(HTTP-01/DNS-01)や証明書更新時の秘密鍵の再利用要否(ALWAYS_GENERATE_KEY)、更新までの猶予期間(THRESHOLD)やTimeout(ORDER_TIMEOUT等)などをここで定義します。
本設定はご利用の環境やACMEサーバの仕様に合わせて調整して頂く必要がございます。設定可能な項目については、GitHubのProviders Configuration Options 項目を確認ください。
今回は証明書更新の動作を確認するため、証明書の更新しきい値をデフォルトの30日から1日に変更します。これ以外の設定はデフォルトのままです。
変更箇所は下記となります。
# cd /shared/acme
# cat config
～省略～
## Threshold in days when a certificate must be renewed (default: 30 days)
#THRESHOLD=30
THRESHOLD=1
～省略～
#
4.HTTP仮想サーバ
BIG-IPにHTTP仮想サーバを設定します。
これはACMEサーバが名前解決を行って取得したIPアドレスに対してHTTPリクエストを送信し、正しいレスポンスを返すための仮想サーバとなります。
以下にhoge.tmxlabs.comに対応する仮想サーバの設定例を記載します。
# tmsh list ltm virtual HTTP-VS
ltm virtual HTTP-VS {
address-status no
destination 10.xx.xx.100:http
ip-protocol tcp
mask 255.255.255.255
profiles {
http { }
tcp { }
}
rules {
acme_handler_rule
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
type automap
}
translate-address enabled
translate-port enabled
vs-index 4
}
#
ここで重要なのは、HTTP仮想サーバに設定するIPアドレス、およびiRuleの設定です。
IPアドレスは認証局からのHTTP GETリクエストの宛先となるので、IPアドレスは正しく設定を行って下さい。
iRuleは、項番1.で確認したacme_handler_ruleを設定します。
このiRuleによって、認証局からのリクエストに対して正しい応答を返すことができます。
これで設定は完了したので、さっそく動作を確認します。
動作確認のため、下記の2通の証明書を用意しています。
hoge.tmxlabs.com証明書は失効まで猶予がありますが、fuga.tmxlabs.com証明書は失効まで1日を切った状態です。
3.でしきい値を1 日に変更しているので、手動で証明書更新操作を実行してみましょう。
下記のコマンドにて、手動で証明書更新操作を実行します。
# date;./f5acmehandler.sh --verbose
Tue Feb 17 11:56:07 JST 2026
実行後の証明書は下記になります。
手動実行時の時刻付近で証明書の有効期限が更新されていることが確認できます。
なお、fuga.tmxlabs.com証明書の有効期限が手動更新の24時間後になっているのは、使用しているSmallstep CAがデフォルトで24時間後に失効する短寿命証明書を発行するためです。
fuga.tmxlabs.com証明書が更新されたことは確認できたので、hoge.tmxlabs.com証明書も確認します。
下記が証明書更新操作後のhoge.tmxlabs.com証明書ですが、有効期限に変化がないことが確認できます。
ここで手動更新操作時のログを見てみます。
・fuga.tmxlabs.com
>> [2026-02-17_11:56:09] DEBUG: ALWAYS_GENERATE_KEY is true, certificate exists, and THRESHOLD (1) -ge date_test (1) - Starting renewal process for fuga.tmxlabs.com
ログから、fuga.tmxlabs.comは閾値(1 day)を下回っているため証明書の更新処理をおこなうプロセスが動作し、hoge.tmxlabs.comは閾値を上回っているため更新処理プロセスがスキップされていることが分かります。
このように、閾値を基準として証明書更新を行っていることが確認できます。
設定・動作説明 <オプション>
ここまででBIG-IPのACMEクライアントとしての動作を確認頂けたかと思います。ただ、これだけでは自動更新、更新の成功/失敗を動的に通知することはできません。ここからは自動更新のためのスケジュール、通知設定について実際の設定、動作を解説します。
5.スケジュール
毎週月曜日の午前4時に更新チェックを開始する週単位のスケジュールを設定するには下記のスケジュール定義を実行します。
./f5acmehandler.sh --schedule "00 04 * * 1"
ここではテストのために8:20、13:20、18:20の3回更新チェックが行われるように下記の設定を行います。
# ./f5acmehandler.sh --schedule "20 08,13,18 * * *"
The f5acmehandler script has been scheduled. Current crontab:
20 08,13,18 * * * /shared/acme/f5acmehandler.sh
#
fuga.tmxlabs.com証明書の有効期限は先ほどの手動更新によってFeb 18 2026 11:56:09 JSTとなっており、13:20にチェックが行われた場合は閾値を下回っているため、自動更新が実行され有効期限が13:20近辺に更新されているはずです。
それでは13:20を過ぎたタイミングでfuga.tmxlabs.com証明書の有効期限を確認してみましょう。
有効期限がFeb 18 2026 13:20:04 JSTとなっていることが確認できます。
>> [2026-02-17_13:20:03] DEBUG: ALWAYS_GENERATE_KEY is true, certificate exists, and THRESHOLD (1) -ge date_test (1) - Starting renewal process for fuga.tmxlabs.com
ログからも13:20に更新チェック/更新が行われたことできます。
このように、スケジュールを設定することで証明書の更新を自動で実行することが可能です。
6.通知設定
f5acmehandlerユーティリティで更新に関するレポートを生成し、SMTP設定を介してメールを送信できます。この設定は/shared/acme/config_reportingファイルで行います。
ここではメール送信のため、下記の様な設定を行います。
# cat config_reporting
～一部抜粋～
## Set to SMTP host:port
MAILHUB=10.x.x.1:25
## Set email address of sender
REPORT_FROM="admin@acme.lab"
## Set email report Subject line
REPORT_SUBJECT="BIG-IP ACMEv2 Renewal Report"
設定後、証明書更新を行った際に通知されたメール内容が下記になります。
From: admin@acme.lab
Subject: BIG-IP ACMEv2 Renewal Report
ACMEv2 Renewal Report: Wed Feb 18 10:55:07 JST 2026
Command Line Option Specified: --verbose
Processing renewals:
Processing for domain: fuga.tmxlabs.com
ALWAYS_GENERATE_KEY is true, certificate exists, and THRESHOLD (1) -ge date_test (1) - Starting renewal process for fuga.tmxlabs.com
Updating existing cert and key.
Processing for domain: hoge.tmxlabs.com
ALWAYS_GENERATE_KEY is true, certificate exists, and bypassing renewal process for hoge.tmxlabs.com - Certificate within threshold
.
送信元アドレスやタイトルがconfig_reportingで設定されたものになっています。本文を見てみると、fuga.tmxlabs.comは”Updating existing cert and key.”となっており、証明書が更新されたことが確認できます。hoge.tmxlabs.comは” bypassing renewal process for hoge.tmxlabs.com”となっており、更新処理をバイパスされたことが分かります。
この通り、KOJOT-ACMEは証明書有効期限を定期的に確認し、必要に応じて証明書を更新、その結果のレポートをメールで通知することができるツールであることをご理解いただけたかと存じます。
おわりに
今回はBIG-IPのSSL/TLS証明書更新自動化ソリューションとして、KOJOT-ACMEを紹介しました。
SSL/TLS証明書の有効期限の短縮が迫っており、弊社にも問い合わせが増加傾向にあることからも、注目が集まっているソリューションだと考えております。先述の通り、KOJOT-ACME は現時点ではF5 contributed software扱いとなっています。今後、正式にサポートされることが期待されます。
本記事をご覧頂き、F5社でも証明書自動化に向けた取り組みが進められていることをご認識頂ければ幸いです。
最後になりますが、弊社ではこれ以外にも様々なソリューションを取り扱っております。
もし気になるソリューションがございましたら、ぜひ弊社へお問い合わせください。
