内部認証局を持つかの判断 — 自前CA・マネージド・公開CAの選定

証明書管理の方針を設計段階で決めなければ、数年後には発行済み証明書の台帳もなく、有効期限も失効手続きも誰も把握できていない状態になる。自前CAを立てるか、マネージドPKIを選ぶか、ACMEで公開CAに任せるかは「内部証明書の量と内部通信の密度」が判断軸だ。この記事では三者の向き不向きを整理し、発行・更新・失効の運用設計と信頼チェーンの配布判断まで踏み込む。

証明書を場当たりで発行して管理不能になる構造

有効期限と発行台数が掛け算で膨らむ

証明書を計画なしに発行し始めると、サーバー10台程度の規模でも1〜2年後には「どこに何の証明書があるか誰も把握できていない」状態に陥りやすい。開発環境・ステージング・本番を分けていれば、同じサービスでも3倍の枚数になる。サービスが増えるたびに枚数は積み上がり、有効期限も揃っていないため更新作業が毎月散発的に発生する。あるインフラ担当者が経験した案件では、50台規模の環境で証明書台帳を整備しないまま2年運用した結果、更新漏れによるサービス停止が四半期に1回のペースで発生していた。台数と期限のかけ算が管理コストを押し上げる構造は、発行時の設計判断でしか断ち切れない。

失効処理を設計しないと信頼チェーンが崩れる

証明書は有効期限が来るまで「有効」なのではなく、鍵の漏洩やサーバー廃止の時点で失効させる必要がある。場当たり運用では失効の仕組み（CRLやOCSP）が最初から設計に入っていないことが多く、秘密鍵が漏洩してもクライアントは旧証明書を信頼し続ける状態が生まれる。内部向けサービスであっても、ゼロトラスト的な考え方を取り入れるなら失効処理は設計必須だ。公開CAのACMEであれば失効APIが整備されているが、自前CAで独自に構築する場合は失効インフラそのものの設計と運用が別途発生する点を見落としがちだ。

「誰も管理していない証明書」が生まれる構造

証明書発行の権限がチームに分散しているとき、あるいは担当者が交代したときに、旧担当者が発行した証明書の台帳が引き継がれないケースがある。こうして生まれた「誰も管理していない証明書」は、有効期限切れでサービスが止まるまで気づかれない。設計フェーズで「誰が発行権を持ち、誰が台帳を保持するか」を決めておくことが、証明書管理のアンチパターンを防ぐ最初の関門だ。発行ログを一元化するだけでもこのリスクは大きく下がる。

内部通信に自前CAが要る場面・公開CAで足りる場面の違い

自前CAが必要になる条件

インターネットに公開しないFQDNへの証明書が必要な場合（例: api.internal、*.prod.local）、マイクロサービス間のmTLS（相互TLS認証）を実装したい場合、公開CAから発行できないIPアドレス証明書やカスタム属性が必要な場合、そしてオフライン・エアギャップ環境でサービス間通信を暗号化したい場合に、自前CAまたはマネージドPKIの導入を検討する価値がある。特にmTLSを全サービス間で実装する構成では、サービス1つあたり1〜複数の証明書が必要になり、50サービス構成なら100枚以上の証明書が流通する規模になる。これを公開CAで管理しようとすると、ドメイン検証の手間と費用が割に合わなくなる。

公開CAで十分な場面

外部公開サービスのHTTPS証明書が主目的で、内部通信はVPNや別のレイヤで保護されており、証明書によるmTLSが不要な構成では、公開CAとACMEで大半をカバーできる。Let’s Encrypt等のACMEプロバイダーは90日有効期限と自動更新を前提に設計されており、certbot/acme.shなどのクライアントと組み合わせると更新を自動化できる。証明書の発行対象がすべてパブリックDNSで解決できるFQDNに限られるなら、管理すべき独自インフラが増えないため、運用負荷は三者の中で最も低い。

境界が曖昧になる混在構成の注意点

現場では「外部公開は公開CA、内部通信は自前CA」という混在構成が多い。問題は境界が曖昧になりやすいことだ。あるサービスが最初は内部向けだったのに後から外部公開に切り替わったとき、証明書の切り替えと信頼チェーンの変更が発生する。また、内部向けサービスを開発者のPCからデバッグするときに、自前CAのルート証明書を開発者端末に配布する必要が生じる。この「どこまで配布するか」の設計が混在構成では特に重要で、後から対処しようとすると工数がかさむ。

比較表: 自前CA・マネージドPKI・公開CA（ACME）の向き不向き

三者の位置づけと特性

自前CA・マネージドPKI・公開CAは「誰が証明書ライフサイクルの責任を持つか」という軸で性格が異なる。自前CAはすべての設計・運用が自チームの責任になる代わりに、発行できる証明書の自由度が最も高い。マネージドPKI（AWS Private CA、HashiCorp Vault PKIなど）はAPIと監査ログが整備されており、運用の自動化と規制対応を両立しやすい。公開CAはドメイン所有者認証を前提にした外部向けサービスで、内部証明書の発行には使えない。

観点	自前CA	マネージドPKI	公開CA（ACME）
内部ドメイン・IP証明書	◎ 任意のFQDN・IP対応	◎ 任意のFQDN対応	△ パブリックDNS必須
mTLS対応	◎	◎	× 事実上困難
初期費用	低（ソフトウェアのみ）	中〜高	無料〜低
運用負荷	高（全設計が自前）	低〜中（API完備）	低（自動更新）
監査ログ・規制対応	自前で構築が必要	ログ・監査機能あり	限定的
鍵管理	自前（HSMは別途）	HSM込みで提供	プロバイダー管理
証明書枚数のスケール	設計次第・手動管理	APIで自動化可	ACMEで自動更新

選定の分岐点

比較表から見えてくる選定の分岐点は「内部証明書の量」と「規制・監査要件の有無」の2軸だ。内部証明書が20枚未満で規制要件がない環境なら、自前CAの管理コストが利点を上回りやすく、公開CAだけで運用する構成の方がシンプルに収まる。証明書が50枚を超えた段階、あるいは監査ログの整備が求められる段階になったとき、マネージドPKIへの移行コストより自前運用のコストが高くなる分岐が生まれる。この分岐を意識せずに自前CAを立てた現場では、後から「作ったけれど運用が重い」という状況になるケースが目立つ。

発行・更新・失効を誰がどう回すかの設計

発行フローを人手に依存させない設計

証明書発行の承認フローを人手で行うと、発行までのリードタイムがボトルネックになる。CI/CDパイプラインやサービスメッシュ（Istio、Linkerdなど）のサイドカーが証明書を自動取得・更新する設計が理想だ。HashiCorp Vault PKIのように「サービスアカウントが自分の証明書を発行できる」権限モデルを設計しておくと、人手の介入なしに発行できる。ただし、権限の範囲（どのCNやSANを許可するか）をポリシーで制限しないと、意図しない証明書が発行できる状態になるため、ポリシー設計が先行しなければならない。手を動かす実装の詳細は別途セミナー・ハンズオンで確認してほしいが、設計上の判断としては「誰が・何のために・どの範囲で発行できるか」を先に決めることが重要だ。

更新の自動化設計

証明書の有効期限切れによる障害を防ぐには、有効期限の30〜50%を過ぎた時点で更新をトリガーする仕組みが必要だ。90日証明書なら45日前、1年証明書なら6ヶ月前が目安になる。更新スケジューラをCronベースで実装する場合、更新失敗時のアラートと再試行ロジックをセットで設計しないと、失敗が無音で終わる。PrometheusやDatadogで証明書有効期限をメトリクスとして監視し、閾値アラートを設定するパターンが現場では定着しつつある。更新の自動化とモニタリングはセットで設計することが原則だ。

失効インフラ（CRL/OCSP）の設計判断

自前CAを立てる場合、失効情報の配布インフラも自前で用意する必要がある。CRL（証明書失効リスト）はURLで公開するため、CRLを提供するHTTPエンドポイントが単一障害点にならないよう冗長化が必要だ。OCSPはリアルタイムで失効状態を返すため可用性要件が高く、小規模環境では維持コストが見合わないことも多い。内部のみで使う証明書であれば、クライアント側でOCSPチェックを無効化する設計も選択肢に入る。ただし、これは「失効証明書をクライアントが信頼し続けるリスクを許容するかどうか」の意思決定であり、セキュリティポリシーと照らし合わせて判断する必要がある。

信頼チェーンをどこまで配布するかの判断

信頼ストアへの登録戦略

自前CAのルート証明書は、そのCAが発行した証明書を信頼させたいすべての端末・コンテナ・サービスに配布する必要がある。OS・ブラウザ・言語ランタイムはそれぞれ独自の信頼ストアを持っており、OSレベルのシステムストアに登録しても、Javaアプリケーションが参照するJKSや、Node.jsのデフォルトバンドルには自動的に反映されない場合がある。配布漏れのリスクを下げるには、「どの信頼ストアに登録が必要か」をスタックごとに洗い出す作業を設計段階で行っておくことが重要だ。

コンテナ環境での配布漏れが生む障害パターン

コンテナイメージにルート証明書を含め忘れたとき、アプリはTLS接続に失敗する。これは自前CAを使う環境で繰り返し起きる障害パターンだ。Dockerfileのベースイメージ更新時にカスタムルート証明書のレイヤが消えたり、Kubernetesのサービスアカウントに証明書配布の仕組みが含まれていなかったりするケースが現場では報告されている。ConfigMap経由でルート証明書を配布し、Init Containerでシステムストアに登録するパターンが、Kubernetes環境での定番になってきている。配布の仕組みをIaCやHelmチャートに組み込んでおくと、再現性が上がりメンテナンス漏れを防ぎやすい。

開発者端末への配布設計

開発者が自前CAの証明書を使う内部サービスにアクセスするとき、ブラウザがTLS警告を出さないようにするには、ルート証明書をOSの信頼ストアに登録する必要がある。これを自動化するスクリプトを整備せず口頭で伝えるだけだと、開発者ごとに対応が違い「自分の環境ではつながる/つながらない」という差異が生まれる。オンボーディング手順にCA配布ステップを組み込む設計が必要だ。開発者端末が会社管理端末とBYODの混在になる場合は、「社内VPN内でのみ内部サービスにアクセスできる」構成とし、証明書配布の対象を管理端末に絞る判断も選択肢として成立する。

自前CAを持って運用が重くなる境界の見極め

運用コストが跳ね上がるトリガー

自前CAの運用コストが突然重くなるタイミングがいくつかある。ルートCAの秘密鍵をHSMで保護しようとした段階、中間CAを複数設けて部門ごとに管理しようとした段階、証明書発行の監査ログをISO 27001やPCI DSS等の規制要件に合わせて保存しようとした段階がそれだ。特にルートCAの鍵ローテーションは、発行済みの証明書がすべて再発行対象になるため、100枚以上の証明書が流通している環境では入れ替え工数が数日〜1週間規模に達することがある。これらのコストを事前に見積もらずに自前CAを選んだ現場では、後から運用の重さに気づいて立ち止まるケースが多い。

マネージドPKIへの移行を検討すべき指標

自前CAからマネージドPKIへの移行を検討すべき指標として、証明書枚数が50枚を超えた段階で管理が煩雑になってきたこと、セキュリティ監査でCAの鍵管理や監査ログの保全を指摘されたこと、CA担当者が1名しかおらずノウハウの属人化リスクが高いこと、発行・失効・更新の自動化をAPIで行いたいが自前実装のコストが合わないこと、が挙げられる。マネージドPKIは証明書ライフサイクルのAPIと監査ログを提供しており、自前で構築するより早く「監査に耐えうる状態」に持ち込める利点がある。運用人件費との比較で費用対効果を判断する材料として扱うのが適切だ。

撤退・移行時に踏む必要がある順序

既存の自前CAを廃止してマネージドPKIに移行するとき、移行期間中は旧CAと新CAが並走する。クライアントが旧ルート証明書を信頼したまま、新CAが発行した証明書を受け取っても検証に失敗するため、移行の順序が重要になる。正しい順序は「新CAのルートを先に全端末・コンテナに配布する」→「新CAで証明書を再発行する」→「旧CA発行の証明書がすべて入れ替わったことを確認する」→「旧CAのルートを信頼ストアから削除する」だ。この順番を誤ると一部の端末でTLS接続が失敗するため、移行計画に順序依存を明示し、各ステップの完了確認基準もあらかじめ定めておく必要がある。

認証局選定チェックリスト

以下のチェックリストで「Yes」が多い選択肢が、現在の環境に適した認証局の形態を示す。複数の形態に「Yes」が散らばる場合は、混在構成を前提に境界を設計することが先決だ。

自前CAを選ぶ前に確認すること

• 内部FQDNやIPアドレス宛てに証明書を発行する必要があるか
• サービス間のmTLSを設計に組み込む予定があるか
• 証明書ライフサイクル（発行・更新・失効）の全工程を自チームで設計・運用できるか
• ルートCAの秘密鍵をHSMまたはオフラインメディアで保護する手段があるか
• CRL/OCSPエンドポイントを冗長構成で提供できるか
• CA担当者が複数名おり、属人化リスクが低いか

マネージドPKIを選ぶ前に確認すること

• 証明書枚数が50枚以上、または今後急増する見込みがあるか
• ISO 27001・SOC 2・PCI DSS等の規制・監査要件があり、発行ログの保全が必要か
• 発行・失効・更新をAPIで自動化したく、自前実装コストを避けたいか
• HSMによる鍵管理を別途調達せずに済む構成を求めているか
• CA担当者が1名以下で属人化リスクを低減したいか

公開CA（ACME）で十分かを確認すること

• 証明書の発行対象がすべてパブリックDNSで解決できるFQDNに限られるか
• 内部サービス間のmTLSが不要で、外部公開サービスのHTTPS証明書が主目的か
• 証明書の自動更新をACMEクライアントで完結できる構成にできるか
• 有効期間90日・自動更新前提の運用で問題が生じないか