cert-managerを入れるか手動更新で回すか――証明書ライフサイクル自動化の範囲設計

証明書管理の自動化判断は「cert-managerを導入すれば解決する」という問題ではありません。証明書の種類・更新頻度・発行CA・配布先の組み合わせによって、自動化が有効に機能する範囲と除外すべき条件が変わります。無条件に全自動化を進めると商用CAや非コンテナ環境で制御が効かなくなり、逆に全手動を続けると90日周期のLet’s Encrypt証明書が更新漏れで本番障害に直結します。この記事では、自動化すべき範囲・手動で残すべき例外条件・混在期の整合性管理を判断軸ごとに整理します。

証明書の種類と更新頻度による自動化価値の判断軸

短命証明書が多い環境ほど自動化の費用対効果が高まる

Let’s Encryptが発行する証明書の有効期間は90日です。手動更新するとすれば年4回の作業が発生し、証明書が10枚を超えると年間40回以上の更新作業が積み重なります。更新忘れが1件でも起きればHTTPS通信が即座に遮断されるため、この台数を超えた時点で自動化の検討を前倒しすべき判断基準になります。一方、2年有効の商用CA証明書が5枚程度であれば、手動管理でもカレンダー設定と手順書の整備で十分に回せます。重要なのは件数と有効期間の積で年間作業量を見積もり、その負荷を客観的に比較することです。

証明書の種類別に自動化の適性を見極める

証明書の種類によって自動化の可否が大きく変わります。DV（ドメイン検証）証明書はACMEプロトコルによる自動更新に最も適しており、cert-managerが直接発行・更新を管理できます。OV（組織検証）証明書はCA側で人的審査が入るため自動更新が構造的に不可能であり、1〜2年周期の手動管理が前提となります。EV（拡張検証）証明書も審査が必須なため自動化の対象外です。ワイルドカード証明書はHTTP-01チャレンジが使えず、DNS-01チャレンジでのみ更新可能なため、DNSプロバイダーのAPI連携を別途設計する必要があります。手元の証明書をこの軸で分類することが、自動化設計の出発点になります。

更新頻度と管理台数のマトリクスで判断ラインを引く

証明書の枚数と有効期間を組み合わせると、自動化の優先度が明確になります。Let’s Encryptを使うDV証明書が10枚未満であれば手動管理でも許容範囲に収まる可能性がありますが、10枚を超えた段階では自動化の導入を積極的に検討すべきです。商用CA発行のOV証明書は枚数に関わらず手動管理が基本となります。この分類を設計書に明記しておくことで、新しい証明書を追加する際の管理方式の判断基準が現場で共有できます。

cert-manager導入と手動更新の運用コスト比較表

cert-manager導入と手動更新のどちらが適切かは、初期導入コスト・日常運用コスト・障害リスク・対応可能なCA・前提インフラという複数の軸で判断します。以下は想定例として整理した比較表です。実際のコストは環境規模・担当者のスキルセット・既存インフラの構成によって変動します。

比較軸	cert-manager（Kubernetes環境）	手動更新
初期導入コスト	高（Kubernetesクラスター・CRD設計が前提）	低（既存手順書・カレンダー設定）
日常運用コスト	低（更新作業はほぼゼロ）	高（証明書数×更新頻度に比例）
対応CAの種類	ACME対応CA（Let’s Encrypt等）が中心。商用CA連携は別途設計が必要	すべてのCAに対応可能
前提インフラ	Kubernetesクラスター必須	なし（既存環境で完結）
コンテナ外配布	単体では不可（外部連携が必要）	直接配置が可能
更新失敗リスク	設定誤りによるレートリミット到達リスクあり	人的ミス・更新漏れリスクあり

cert-managerの見落とされやすい導入コスト

cert-managerはKubernetes上で動作するCRDベースのツールです。Kubernetesクラスターを持たない環境に導入する場合、クラスター自体の構築・運用コストが新たに発生します。また、Issuerリソースの設計を誤ると証明書が意図せず繰り返し再発行され、Let’s EncryptのレートリミットであるドメインあたりMax50枚/週の上限に達するリスクがあります。開発・ステージング・本番が同一ドメインを使う構成では特に注意が必要で、環境ごとに異なるCA設定とドメイン分離を事前に設計することが求められます。

手動運用の隠れたコストを定量的に把握する

手動更新は単純作業に見えますが、担当者の属人化・手順書のメンテナンス・更新忘れのリスクが積み重なると実際の運用負荷は見た目より高くなります。想定例として、Let’s Encrypt証明書を20枚管理している環境で担当者が1名の場合、年間の更新関連作業は確認・実施・記録を含めて40時間前後に達する可能性があります。この数字を可視化した上で自動化の投資判断材料とする活用が、設計判断として適切です。担当者の異動・退職が発生した際の引き継ぎコストも見積もる必要があります。

自動更新の適用範囲と除外条件の設計

自動化に適した証明書の条件を定義する

自動化を適用すべき証明書の条件を明文化しておくと、後から追加する証明書の扱いも判断しやすくなります。適用条件の目安として次の4つが挙げられます。DV証明書またはLet’s Encrypt発行であること、Kubernetes Ingress/Serviceに直接紐づいていること、HTTP-01またはDNS-01チャレンジが利用可能なこと、CAのレートリミット内に収まる発行頻度であることです。これら4条件をすべて満たすものが自動化の第一候補になります。条件の一部が欠ける場合は除外条件との照合を行います。

除外条件を先に設計してアンチパターンを防ぐ

自動化設計でよくあるつまずきは、除外条件を定義せずに適用範囲を広げすぎることです。商用CAのOV/EV証明書は人的審査が必須なため自動化の対象外です。HSMやスマートカードに格納された証明書はcert-managerのKubernetes Secret管理と根本的に相性が悪く、自動化しようとすると鍵管理の整合性が崩れます。クラスター外のVM・ベアメタルサーバーに直接マウントされる証明書も、cert-manager単体では配布できません。これらを除外条件として設計書に明記することで、後から「なぜここだけ手動なのか」という問いに設計根拠で答えられます。

適用範囲の判断に使えるチェックリスト

個々の証明書に自動化を適用すべきかを判断する際の確認項目です。

• 証明書の種類はDV（Let’s Encrypt含む）か
• 配布先はKubernetesクラスター内のリソースか
• HTTP-01またはDNS-01チャレンジが利用可能な環境か
• 同ドメインの証明書発行数がLet’s EncryptのMax50枚/週の範囲内に収まるか
• HSM・スマートカード等の特殊な鍵格納は使っていないか
• OV/EV証明書ではないか（該当する場合は手動管理対象）

Let’s Encryptと商用CAの選定境界

Let’s Encryptが適する条件を整理する

Let’s Encryptは無償・自動更新・広く信頼されるルートCAという特性を持ち、DV証明書が必要なほぼすべての用途で選定の第一候補になります。内部APIエンドポイント・CI/CD環境・マイクロサービス間通信・開発/ステージング環境はいずれもOV審査が不要であり、Let’s Encryptで対応できます。ただし、Let’s EncryptはSLAや技術サポートを提供しないため、CAのサービス停止・仕様変更が発生した場合の代替手段を別途設計しておく必要があります。ACME対応の別CAへの切り替えを最低限の代替として設計に含めることが望ましいです。

商用CAを選定すべき条件と判断基準

法的・契約的にOV証明書以上が要求される業種（金融機関・医療・行政・特定のSaaS契約）では、Let’s Encryptを利用できません。商用CAのOV証明書が必須になります。EV証明書については、CA/Browserフォーラムの方針変更により主要ブラウザでのEV表示が縮小傾向にあることも考慮した上で、コンプライアンス要件として本当に必要かどうかを確認してから選定すべきです。またCDNサービスやクラウドのマネージドCAを利用する場合は、証明書のポータビリティ（他環境への移植性）を事前に確認することが重要です。

ハイブリッド構成のリスクを設計に織り込む

内部エンドポイントにLet’s Encrypt・外部公開サービスに商用CA OVというハイブリッド構成は広く採用されていますが、管理方式が二系統になることで混在期の整合性管理の難度が上がります。どのドメイン・サービスがどちらのCAを使うかを設計書の「CA選定マトリクス」として明文化し、新規サービス追加時のCA選定フローを標準化しておくことが、長期的な管理コストを下げる設計です。

更新失敗時の検知とアラートの設計

cert-manager環境での証明書ステータス監視

cert-managerはCertificateリソースのConditionフィールドに証明書の現在状態を反映します。Ready=Falseが30分以上継続した場合にアラートを発火させる設定が一般的な監視設計として用いられています。Prometheus/Alertmanagerを既に導入している環境では、cert-managerが公開するメトリクスを活用して有効期限が14日を下回った段階でアラートを上げる設計が有効です。この14日という閾値はLet’s Encryptの推奨更新タイミングから逆算した目安であり、更新に失敗した場合でもリトライの余裕を確保できます。

手動更新環境での期限監視の設計

手動更新環境では証明書の有効期限を定期チェックする外部監視を別途構築します。Nagios/Zabbix等の監視基盤が既にある環境では既存プラグインで対応できます。独自スクリプトで実装する場合は、対象ホストにTLS接続して有効期限を取得し、しきい値（一般的には30日前）を下回ったらSlack・メール等へ通知する仕組みが最小構成です。手動運用環境のよくあるつまずきは監視対象リストが更新されず、新たに追加したサービスが監視から漏れることです。証明書の新規発行時に監視対象リストへの追加を標準手順に組み込むことが重要です。

失敗検知から復旧までのエスカレーションパスを先に設計する

更新失敗を検知した後の対応フローを事前に設計しておかないと、障害発生時に行き詰まります。「自動更新失敗→アラート発火→手動対応手順書の確認→緊急発行手順の実行→最終確認者への連絡」というエスカレーションパスを設計書に含めます。特に深夜・休日に証明書が失効した場合の対応権限と連絡先を明確にしておくことが、SLAに影響する障害を防ぐ設計上の要点です。cert-manager環境であっても、自動更新が失敗した際のフォールバック手順を持たないまま運用すると発覚が遅れる傾向があります。

コンテナ外サーバーへの証明書配布方式の判断

cert-managerの管理範囲はKubernetes内にとどまる

cert-managerが発行・更新した証明書はKubernetes Secretとして格納されます。クラスター内のIngressやPodからはシームレスに利用できますが、クラスター外のVMやベアメタルサーバーへの配布はcert-manager単体では対応できません。この前提を理解せずにcert-managerを全環境の証明書管理基盤として位置づけると、コンテナ外環境で別途手動管理が残り、自動化の恩恵が限定的になります。

コンテナ外への配布設計パターン

コンテナ外サーバーへ証明書を配布する方式は大きく2つに分類できます。1つ目はSecretを外部シークレットストアに同期する方式で、External Secrets OperatorやVault Agent Injectorを使いKubernetes SecretをVault/クラウドのシークレット管理サービス等に同期し、VMサイドのエージェントがそこから取得します。2つ目はクラスター外で直接ACMEを利用する方式で、acme.shやcertbotをVM上で動かしcert-managerとは独立して証明書を管理します。前者は一元管理に向きますが追加の運用コストが発生し、後者は構成がシンプルな分管理点が分散します。

混在環境での統合管理の判断基準

VM10台以上とKubernetesクラスターが混在する環境では、Vaultを中央配布ハブとして設計することで証明書の所在・有効期限・更新状態を一元的に把握しやすくなります。一方でVault自体の構築・HA設計・バックアップという管理コストが新たに発生します。VM数台程度の小規模環境ではこの投資が割に合わないことが多く、VM上のcertbot独立運用の方が運用負荷は低くなります。環境規模と管理の一元化ニーズのバランスで判断することが重要です。

移行期における手動・自動混在時の整合性保ち方

移行期の二重管理が生む最大のリスク

手動更新からcert-managerへの移行期に最も起きやすいつまずきは、同一証明書を手動とcert-managerの両方が管理してしまう状態です。cert-managerが自動更新した直後に運用担当者が古い証明書を手動で上書きすると、どちらが実際に使われているか不明瞭になります。逆にcert-managerへの移行を途中で中断して手動更新を再開しても台帳に記録されない場合、次の更新タイミングで混乱が生じます。この状態は証明書の失効を招きやすく、移行期の最大リスクとして認識する必要があります。

移行をドメイン・サービス単位で段階的に切り替える

移行はインフラ全体を一括で切り替えるのではなく、ドメインまたはIngress単位で段階的に進めることが整合性を保つ上で重要です。切り替え済みのリソースにはcert-managerのCertificateリソースのアノテーションで管理状態を明示し、手動管理台帳から削除します。「移行対象・移行済み・手動管理継続」という3つの状態を管理台帳で可視化し、毎週の状態確認を移行完了まで継続することが二重管理の発生を防ぐ設計上の基本です。

混在期の整合性チェックと廃止タイミングの設計

混在期の整合性を保つために、cert-manager管理対象のドメインに手動証明書が混入していないかを週次または日次で自動チェックする仕組みを構築します。Kubernetes APIで管理対象ドメインの証明書シリアル番号を取得し、実際にTLS接続で提示される証明書のシリアル番号と突合することで食い違いを検出できます。この仕組みは移行完了後に廃止する時限的なものとして設計し、完了後も残り続けるオーバーヘッドを生まないようにします。移行の完了定義と廃止タイミングを最初から決めておくことが、整合性チェック自体の負債化を防ぎます。