各種アプライアンス・ミドルウェアにおける対応状況および解説

はじめに：証明書の有効期間短縮と自動化

TLS/SSL証明書の有効期間は、CA/Browser Forumの決定（Ballot SC-081v3）により段階的に短縮されています。従来の最大有効期間は398日（約13ヶ月）でしたが、2026年3月から最大200日への短縮が開始されており、最終的には2029年3月以降に最大47日となる見込みです。有効期間の短縮は、秘密鍵の漏洩リスク低減や暗号アルゴリズムの更新迅速化につながる一方で、手動による更新作業の負荷が増大するため、運用の自動化が求められます。

証明書の自動更新を支えるプロトコルとして、RFC 8555で標準化された「ACME（Automated Certificate Management Environment）」が利用されています。ACMEプロトコルは、HTTP-01やDNS-01などのチャレンジ（所有権検証）を用いてドメインの所有権を確認し、証明書の発行・更新を自動で実行します。取得した証明書のサーバへの適用（デプロイ）は、各クライアントのデプロイフック等で別途対応します。

UPKI電子証明書発行サービスなどの外部ACMEサーバーを利用する場合、アカウントの認証と紐付けを行う「EAB（External Account Binding）」の指定が必要になります。EABは、ACMEアカウントと既存のアカウント情報（Key ID と HMAC Key）を紐付ける仕組みであり、許可されたクライアントのみが証明書を取得できるように制限します。

本ドキュメントでは、EABへの対応状況（UPKI等の外部ACMEサーバーへの適用可否）を含め、主要なアプライアンスやミドルウェア製品のACME対応状況、自動化の方法、および制限事項について解説します。

ネットワーク・トラフィック制御

ネットワーク製品はSSL/TLSターミネーションを処理するため、ACMEプロトコルの導入が進んでいる領域です。

ロードバランサおよびADC（アプリケーション・デリバリ・コントローラ）

F5 BIG-IP: BIG-IP単体ではACMEに対応していませんが、外部クライアントであるDehydratedのラッパー「Kojot Acme」を利用することでEABに対応可能です。これによって、EAB認証を用いる外部ACMEサーバーへ証明書を直接要求できます。（参考: Kojot-ACME GitHubリポジトリ）
Citrix ADC (NetScaler): NetScaler Console経由での自動更新に対応していますが、連携可能な認証局が特定のサービスに限定されており、任意のEAB資格情報（クレデンシャル）を用いた外部ACMEサーバーとの連携はサポートされていません。
HAProxy: バージョン3.2の組み込みACMEクライアント、またはサードパーティ製クライアント（Certbot等）を使用します。Certbot等の外部ツールはEABをサポートしているため、スクリプト等を併用することでUPKIとの連携が可能です。（参考: HAProxy 3.2 設定マニュアル §12.8 ACME）
AWS ALB: AWS Certificate Manager (ACM) と統合されていますが、ACM自体に外部ACMEサーバーから証明書を自動で取得・更新する機能はないため、UPKI等の外部CAとの自動連携はできません。（参考: AWS ACM 外部証明書インポート仕様）

CDN（コンテンツ配信ネットワーク）

Cloudflare、Akamai、FastlyなどのCDNサービスは、提供元が管理する証明書や特定のCAと連携した証明書の自動取得機能を提供しています。しかし、ユーザー独自のEAB資格情報を用いた外部ACMEサーバーとの連携には対応していません。（参考: Cloudflare カスタム証明書アップロード要件）

リバースプロキシとAPIゲートウェイ

Traefik: 設定ファイル内に eab の項目を定義することでEABに対応しており、UPKIと連携できます。（参考: Traefik ACME EAB 公式ドキュメント）
Squidなどのプロキシサーバー: Certbotなどの外部クライアントを利用したスクリプト運用によって対応可能です。
Kong API Gateway: ACMEプラグインで eab_kid および eab_hmac_key を指定することで、EABに対応しています。（参考: Kong ACMEプラグイン公式ドキュメント）

ネットワーク制御領域

製品名	ACME対応状況	EAB対応(UPKI等)	自動化のメカニズムと構成
F5 BIG-IP	非対応（単体）	△ 外部連携で可能	Kojot AcmeやAnsibleを使用。iRuleでチャレンジを転送する。
Citrix ADC	特定サービス連携	✕ 非対応	NetScaler Consoleの機能を利用（特定CA限定）。
AWS ALB (ACM)	マネージド	✕ 非対応	ACM自体に外部ACME連携機能はなく、任意のEABは非対応。
Cloudflare等CDN群	マネージド	✕ 非対応	提供元指定のCAによる自動更新のため、任意のEABは非対応。
HAProxy / Squid	外部連携等	△ 外部連携で可能	外部クライアントでEABを指定して取得し、デプロイフックで反映する。
Traefik	対応	◯ 対応	Legoライブラリを内蔵。設定項目でEABの指定が可能。
Kong API GW	対応	◯ 対応	ACMEプラグインでEABを指定可能。

セキュリティ製品

WAF（Web Application Firewall）

Imperva: 提供元が管理するマネージド証明書機能は、外部のEAB付きACMEに対応していません。API経由で外部からカスタム証明書をアップロードする構成をとる必要があります。（参考: Imperva Cloud WAF API ドキュメント）
Barracuda WAF: WAF-as-a-Serviceにおいて、管理画面にACMEクライアント機能があり、「EAB KID」および「HMAC Key」を入力する設定項目が用意されています。（参考: Barracuda WAF-as-a-Service 公式ドキュメント）

!!! warning "ファームウェアバージョンの確認" 任意のEAB資格情報を入力するUI項目は、ファームウェアのバージョンによって利用が制限される場合があります。事前に機器のバージョンおよびベンダーのリリースノートを確認してください。

VPNゲートウェイとリモートアクセスサーバー

Palo Alto Networks (GlobalProtect): 外部のACMEクライアント（acme.sh等）で取得した証明書を、API経由でインポートする方式が用いられます。（参考: acme.sh panosフック仕様）
OpenVPN等のVPNサーバー: OpenVPN自体にはACMEクライアント機能がありません。Certbot等の外部クライアントで証明書を取得し、更新時にデプロイフックでOpenVPNプロセスを再起動する構成で対応します。
Cisco Secure Firewall (FMC/FTD): 一部バージョンでACME連携の機能が追加されつつありますが、EAB設定には対応していないため、UPKIの証明書を利用する場合は外部連携方式をとる必要があります。外部のACMEクライアントで証明書を取得し、FMC APIまたは管理コンソール経由でインポートする構成が推奨されます。（参考: Cisco FMCを用いたFTDの証明書インポートガイド）

セキュリティ製品領域

製品名	ACME対応状況	EAB対応(UPKI等)	自動化のメカニズムと構成
Imperva WAF	非対応（外部インポートのみ）	△ 外部連携で可能	提供元指定のCAによる自動更新のため、任意のEABは非対応。API経由で証明書をインポートする。
Barracuda WAF	対応	◯ 対応	WAF-as-a-Serviceなどの管理GUIにEAB設定項目があり、直接の連携が可能。
Palo Alto GlobalProtect	非対応（単体）	△ 外部連携で可能	外部ツールで取得後、API経由でインポートする。
Cisco Secure Firewall	限定的	△ 外部連携で可能	EAB非対応のためUPKIでは外部連携が必要。FMC APIまたはコンソールからインポートする。
OpenVPN等	非対応（単体）	△ 外部連携で可能	外部クライアントで取得後、フックを用いてサービスを再起動する。

コミュニケーション・ファイル転送

メールサーバ（SMTP / IMAP）とファイル共有（FTPS）

Postfix / Dovecot / vsftpd: デーモンプロセス単体ではACMEに対応していないため、外部のACMEクライアント（Certbot等）を利用します。証明書取得プロセスに --eab-kid と --eab-hmac-key を指定することで、UPKIとの連携が可能です。
Microsoft Exchange Server: Windows用のACMEクライアント「win-acme」やPowerShellベースの「Posh-ACME」を利用することで、IISバインディングとExchange各サービスへの割り当てを含めた自動更新およびEABへの対応が可能です。（参考: win-acme Exchangeマニュアル）
FileZilla Server等のFTPSサーバー: 一部バージョンではLet's Encrypt向けの簡易ACME機能を内蔵しますが、EABには対応していません。UPKIを利用する場合は、外部ACMEクライアントで証明書を取得後、FileZillaの設定ファイルを更新してサービスを再起動する構成をとります。

チャット / メッセージングサーバ

ejabberd や Mattermost などの組み込みACME機能は、主にLet's Encrypt等の特定のパブリックCAを想定しており、EABパラメータに対応していない場合があります。UPKIを利用する場合は、前段のNGINXやTraefik（EAB対応）でTLSターミネーションを集約するか、外部のCertbotを利用する構成をとります。（参考: ejabberd ACME公式ドキュメント）

コミュニケーション・ファイル転送領域

製品名	ACME対応状況	EAB対応(UPKI等)	自動化のメカニズムとアーキテクチャ
Postfix/Dovecot等	外部連携	△ 外部連携で可能	取得後、`--deploy-hook` を使用してファイル更新時にプロセスを再起動する。
Microsoft Exchange	外部ツール統合	△ 外部連携で可能	win-acme等を用いて複数サービスへの証明書割り当てを自動化する。
FileZilla Server等	限定対応	△ 外部連携で可能	内蔵ACME機能はパブリックCA向け限定。UPKIは外部ツールで取得後、設定更新・再起動で適用する。

インフラストラクチャ・ミドルウェア

コンテナ基盤とサービスメッシュ

Kubernetes環境では、cert-manager を使用してEABを構成できます。Issuer または ClusterIssuer のリソース定義において externalAccountBinding を設定し、Key IDとKubernetesのSecretに保存したHMACキーを参照することで、UPKI等の外部ACMEサーバーと連携します。（参考: cert-manager EAB 公式ドキュメント）

データベースやディレクトリサーバー（Active Directory、LDAPなど）はACMEに非対応であるため、cert-managerやHashiCorp Vaultなどの証明書管理システムを経由して証明書を取得・適用する構成が用いられます。

ミドルウェア領域

製品名	ACME対応状況	EAB対応(UPKI等)	自動化のメカニズムと構成
DB / ディレクトリ等	非対応（単体）	△ 外部連携で可能	Vault等の証明書管理システムを経由するか、外部クライアントと連携する。
K8s Ingress / Istio	プラットフォーム統合	◯ 対応	cert-managerのEAB設定を利用し、Secretからキーを参照する。

管理・運用ツール

統合管理コンソールとハイパーバイザー

Proxmox VE: バージョン8.2からGUIおよびCLIでEABに対応しています。管理画面にEABの情報を設定することで、外部ACMEサーバーから証明書を取得できます。（参考: Proxmox VE 8.2 管理ガイド Certificate Management）
VMware vCenter Server: 内蔵のACME機能はないため、外部サーバーのPowerShellスクリプト（Posh-ACME等）で証明書を取得し、API経由でvCenterに適用する構成をとります。（参考: Posh-ACME 公式ドキュメント）

運用管理領域

製品名	ACME対応状況	EAB対応(UPKI等)	自動化のメカニズムと構成
Proxmox VE	対応	◯ 対応	v8.2からGUI/CLIでEABを用いたカスタムACMEプロバイダー設定に対応。
VMware vCenter	非対応（単体）	△ 外部連携で可能	外部スクリプト（Posh-ACME等）を利用してAPI経由で反映する。

まとめ

外部のACMEサーバーと連携して自動更新を行うには、対象の製品がEAB（External Account Binding）に対応しているかどうかが要件となります。

Traefik、cert-manager、Proxmox VE（v8.2以降）、Barracuda WAFなどの製品は、設定ファイルや管理画面（GUI）でEABをネイティブにサポートしているため、UPKI等の外部ACMEサーバーと直接連携して証明書の自動更新が可能です。

一方で、CDNや一部のマネージドサービス、特定の認証局のみとの連携を想定して設計されている製品では、任意のEABを用いた外部ACME連携はサポートされていません。このような環境では、外部の汎用ACMEクライアント（Certbot、acme.sh、win-acme、Posh-ACMEなど）を用いて証明書を取得し、スクリプトやAPIを介して各システムへデプロイする構成をとる必要があります。