公開証明書の自動更新をどう設計するか – HTTP-01、DNS-01、混在環境の責任境界

公開証明書の自動更新は、もはや「期限が近づいたら証明書を入れ替える」という作業では済まなくなっています。公開 TLS 証明書の有効期間は短くなる方向にあり、手動更新を前提にした運用は、更新頻度、対象数、確認漏れの面で限界が出やすくなります。

ただし、ここで間違えやすいのは、自動更新を certbot や cert-manager の導入問題としてだけ見てしまうことです。実際には、証明書を取得するだけでは足りません。秘密鍵をどこで作るのか、DNS 検証権限をどこに置くのか、どの機器へ配布するのか、どのサービスを reload するのか、外側から本当に新しい証明書で応答しているかまで確認する必要があります。

この記事では、公開証明書の自動更新を、ACME クライアントの選定ではなく、HTTP-01、DNS-01、秘密鍵、配布、反映、監視の責任境界として整理します。対象は、Linux Web サーバー、リバースプロキシ、ロードバランサー、Kubernetes、オンプレ VM、ネットワーク機器が混在する環境です。

証明書取得だけを自動化しても足りない

公開証明書の更新には、いくつかの段階があります。証明書を発行できた時点では、まだ利用者に新しい証明書が提供されているとは限りません。証明書ファイルが配置され、秘密鍵と対応し、中間証明書が正しく揃い、対象サービスが再読込され、実際の TLS 応答が新しい証明書になって初めて、更新が完了したと言えます。

段階	見ること	失敗しやすい点
発行	ACME や CA API で証明書を取得できるか	HTTP-01 / DNS-01 の検証失敗、CAA、DNS 伝播
鍵	秘密鍵をどこで生成し、どこに保管するか	中央生成による影響範囲拡大、鍵と証明書の不一致
保管	証明書、秘密鍵、中間証明書を安全に置けるか	権限、バックアップ、平文配置、Secret 管理
配布	Nginx、Apache、BIG-IP、Kubernetes などへ届けられるか	形式違い、配置先違い、対象漏れ
反映	reload、restart、import、commit が完了するか	ファイルは更新されたがプロセスが古い証明書を保持
確認	外側から新証明書で応答しているか	内部更新は成功したが、LB や proxy の手前で古い証明書が出る
監視	期限、失敗、未反映を検知できるか	期限監視だけで実応答を見ていない

したがって、自動更新の設計では、どのツールを使うかより先に、どの段階を誰が責任を持つのかを決める必要があります。

HTTP-01 は単純だが、公開経路に依存する

HTTP-01 は、Web サーバーに一時的な検証用ファイルを置き、CA 側から HTTP で到達できることを確認する方式です。単一の公開 Web サーバーで、80/tcp を外部に公開でき、証明書更新後に Web サーバーを reload すればよい環境では、比較的分かりやすい方式です。

しかし、HTTP-01 は公開経路に依存します。リバースプロキシ、WAF、CDN、ロードバランサー、Kubernetes Ingress が間に入ると、CA が見に来る URL がどこへ届くのかを設計しなければなりません。さらに、ポリシーとして 80/tcp を開けたくない環境では、その時点で HTTP-01 は使いにくくなります。

向いている環境	注意点
単一の公開 Linux Web サーバー	Web サーバー reload まで同じホストで閉じやすい
リバースプロキシ配下の Web サーバー	検証 URL をどのバックエンドへ流すかを決める必要がある
Kubernetes Ingress	Ingress Controller と cert-manager の責任分界を決める必要がある
WAF / CDN 配下	検証パスが遮断、書き換え、キャッシュされないようにする必要がある

DNS-01 は柔軟だが、DNS 権限の設計になる

DNS-01 は、DNS の TXT レコードを使ってドメイン所有を検証する方式です。ワイルドカード証明書を発行できる点、HTTP の公開経路に依存しにくい点で便利です。内部向けサービスやロードバランサー配下のサービスでも使いやすい場面があります。

一方で、DNS-01 は証明書更新の問題を、DNS 更新権限の問題へ移します。_acme-challenge の TXT レコードを書き換える必要があるため、DNS API の認証情報をどこに置くのか、どの範囲まで書き込みを許すのか、誰がその権限を管理するのかが重要になります。

各サーバーに DNS API の強い権限を配る設計は、便利ですが危険です。1 台の侵害が DNS ゾーン全体の改ざんにつながる可能性があります。DNS-01 を使うなら、権限を _acme-challenge に限定する、委任ゾーンを使う、中央の発行基盤に閉じる、Secret 管理を厳格にする、といった設計が必要になります。

方式	強み	主な制約
HTTP-01	単純な公開 Web サーバーでは構成しやすい	80/tcp 到達性、経路制御、WAF / proxy の影響を受ける
DNS-01	ワイルドカードや非公開経路のサービスに向く	DNS API 権限、Secret 管理、DNS 伝播を設計する必要がある
TLS-ALPN-01	443/tcp で検証できる	終端装置やプロキシ構成によって扱いが難しくなる

混在環境ではラストワンマイルが問題になる

Linux Web サーバーだけなら、ACME クライアントが証明書取得から reload まで担当できる場合があります。しかし実際の環境には、Nginx、Apache、HAProxy、BIG-IP、Palo Alto、Kubernetes Secret、Java keystore、Redmine、Nextcloud、メールサーバーなど、さまざまな証明書利用先があります。

このような混在環境では、発行よりも配布と反映が難しくなります。PEM のままでよい対象もあれば、PKCS#12、JKS、機器固有の import、管理 API、GUI 操作、commit が必要な対象もあります。

対象	反映で考えること
Nginx / Apache	ファイル配置、権限、reload、外形確認
HAProxy	証明書バンドル形式、reload、接続影響
BIG-IP	証明書と秘密鍵の import、Client SSL Profile への反映、ConfigSync
Kubernetes	Secret 更新、Ingress Controller の再読込、namespace 境界
Java アプリケーション	JKS / PKCS#12、プロセス再起動、truststore と keystore の分離
メールサーバー	Postfix / Dovecot の reload、証明書チェーン、SNI の有無

このラストワンマイルを無視すると、証明書は発行できているのにサービスでは古い証明書が出続ける、という状態になります。

CLM 製品と Ansible の役割を分ける

証明書が増えると、Certificate Lifecycle Management（CLM）製品が候補になります。CLM 製品の強みは、証明書の棚卸し、期限管理、ポリシー統制、承認、監査、通知にあります。どの証明書がどこで使われているかを見える化するには強い選択肢です。

ただし、CLM 製品を入れればすべての配布先が自動的に解決するわけではありません。対応している CA、対応している機器、対応している API、対応している配布形式には境界があります。

一方で Ansible は、証明書専用の inventory 製品ではありません。しかし、対象ごとの配布、変換、reload、外形確認をつなぐ実行基盤として使いやすいです。CLM 製品を司令塔、Ansible を実行部隊として分けると、混在環境では現実的な構成になりやすいです。

層	役割
CLM 製品	証明書 inventory、期限管理、ポリシー、承認、監査
ACME クライアント	証明書発行、HTTP-01 / DNS-01 / TLS-ALPN-01 の実行
Ansible	配布、形式変換、reload、import、commit、外形確認
監視基盤	期限、TLS 応答、証明書チェーン、更新失敗、未反映を検知

監視は期限だけでは足りない

証明書監視というと、有効期限の監視だけを想像しがちです。しかし、それだけでは不十分です。重要なのは、実際のサービスが新しい証明書で応答しているかです。

たとえば、証明書ファイルは更新されていても、Nginx が reload されていなければ古い証明書が出続けます。Kubernetes Secret が更新されていても、Ingress Controller が期待通りに再読込していなければ反映されません。BIG-IP に import されていても、Client SSL Profile に紐づいていなければ使われません。

監視	目的
期限監視	失効が近い証明書を検知する
外形 TLS 監視	実際に利用者へ出ている証明書を確認する
SAN / CN 監視	期待した名前が証明書に含まれているか確認する
チェーン監視	中間証明書を含めて正しく提示されているか確認する
シリアル番号監視	更新後の証明書に切り替わったか確認する
内部ジョブ監視	発行、配布、reload、import の各段階が成功したか確認する

設計時に決めるべきこと

公開証明書の自動更新を設計する時は、ツール名から入るより、先に責任境界を決めた方がよいです。

論点	決めること
発行責任	誰が ACME / CA API を実行するのか
DNS 権限	DNS-01 の更新権限をどこに置き、どこまで限定するのか
秘密鍵	どこで生成し、外へ出すのか出さないのか
配布	どの対象へ、どの形式で、どの経路で配るのか
反映	reload、restart、import、commit を誰が実行するのか
検証	どの時点で更新完了と判断するのか
失敗時	失敗した時に戻すのか、再実行するのか、手動介入するのか

この表を埋められない状態で自動更新だけを始めると、最初は動いても、対象が増えた時に破綻しやすくなります。

まとめ

公開証明書の自動更新は、証明書を取得するだけの問題ではありません。HTTP-01 を使うのか、DNS-01 を使うのか、秘密鍵をどこで生成するのか、どの対象へ配布するのか、どのサービスに反映するのか、実際に新しい証明書で応答しているかまでを含めて設計する必要があります。

単純な公開 Web サーバーであれば、ACME クライアントだけで閉じることがあります。しかし、リバースプロキシ、ロードバランサー、Kubernetes、オンプレ VM、ネットワーク機器が混在する環境では、証明書発行よりも配布、反映、確認の設計が重要になります。

公開証明書の自動更新は、ツール選びではなく、責任境界の設計です。どこで発行し、どこで鍵を持ち、どこへ配り、どこで反映し、どこから確認するのか。その線引きができて初めて、自動更新は運用として成立します。

参考情報

関連する記事