プライベート認証局とは？ 構築方法やパブリック認証局との違いを解説

電子証明書を社内向けに発行し、失効や更新まで自組織で管理するのがプライベート認証局です。公開Webサイトのように不特定多数へ信頼を示したい場面では、通常はパブリック認証局を使います。

見るべき点は、誰に信頼させるかと、発行した後の証明書を誰が管理するかです。プライベート認証局は自由に決められる範囲が広い一方で、失効、期限管理、配布、更新まで自組織で担う必要があります。

• 公開サイト向けか：不特定多数に信頼させるならパブリック認証局
• 社内利用か：端末認証や相互TLSなど限定用途ならプライベート認証局
• 管理を担えるか：失効、期限管理、配布、更新を自組織で実施できるかが分かれ目

そもそも認証局とは

認証局（CA：Certificate Authority）は、電子証明書を発行し、その証明書を無効にする必要が出たときに失効を扱う主体です。

• 発行：公開鍵と主体情報を結びつけ、証明書として署名して発行する
• 失効：秘密鍵の漏えい、端末の紛失、所属変更などが起きたときに、その証明書を有効ではない扱いにする

証明書は配って終わりではありません。端末の紛失や退職、侵害が起きた時点で、その証明書を引き続き使ってよいかを判断する必要があります。認証局は、その判断を実際の運用に落とし込む役割も持ちます。

パブリック認証局とプライベート認証局で違うのは、発行や失効という基本機能ではなく、誰に信頼させるかと、その後の管理を誰が担うかです。

プライベート認証局とは

プライベート認証局は、社内など限られた範囲で使う認証局です。有効期間、発行条件、失効条件、配布方法などを自組織の実情に合わせて決められます。

よく使われる場面

• 端末認証：許可したPCやスマートデバイスだけを社内ネットワークやクラウドへ接続させる
• 相互TLS（mTLS）：サーバーだけでなくクライアント側も証明書で確認する
• 社内システムの署名と改ざん確認：業務アプリやワークフローで、誰が処理したかと内容の改変有無を確かめる

導入しただけでは終わらない

自由に決められる範囲が広い一方で、管理が弱いと事故のきっかけになります。紛失した端末の証明書が失効されないまま残る、期限切れで業務が止まる、秘密鍵の保護が不十分になる、といった問題は、機能不足より管理不足で起こりやすいものです。導入時点で、発行、配布、更新、失効、一覧確認までを業務として定めておく必要があります。

パブリック認証局とは

パブリック認証局は、不特定多数が使うサービス向けに証明書を発行する認証局です。公開WebサイトのSSL/TLS証明書で使われることが多く、利用者側が追加設定なしで検証できる点が大きな特徴です。

その前提になっているのが、主要なOSやブラウザの信頼ストアに、信頼されたルート証明書があらかじめ入っていることです。利用者は、そのルート証明書を起点に証明書の正当性を確認できます。

一方で、パブリック認証局の証明書は、種類や検証レベル、枚数に応じて費用が発生することがあります。発行条件や監査の枠組みも、認証局側のルールに従います。

プライベート認証局とパブリック認証局の違い

両者の違いは、誰に信頼させるかと、発行後の証明書を誰が管理するかです。

証明書の規格そのものが大きく違うわけではありません。差が出るのは、どこで信頼を成立させるかと、発行した後の証明書を誰が管理するかです。

パブリック認証局は、利用者端末の信頼ストアにルート証明書が入っていることを前提にしやすい一方で、プライベート認証局は、どの端末にルート証明書を配布して登録するかを自組織で決める必要があります。

選び方の目安

• 公開Webサイトや外部公開サービス：通常はパブリック認証局
• 社内ネットワーク、端末認証、相互TLS：プライベート認証局
• 管理要員が限られる場合：自前構築より、管理しやすい製品や仕組みを優先

プライベート認証局をどう作るか

プライベート認証局は、オープンソースのソフトウェアで作ることもできます。ここでは一例として、OpenSSLを使う流れを簡単に示します。

1. OpenSSLをインストール
2. コマンドでルートCA用の秘密鍵と証明書、中間CA証明書を発行するための中間CA用の秘密鍵と証明書を作成
3. サーバー証明書とクライアント証明書を作成
4. サーバーや認証基盤へ証明書を設定
5. クライアント端末へルート証明書を配布して登録

ただし、作成だけで終わりではありません。期限切れを防ぐこと、失効を適切に扱うこと、鍵を保護すること、配布と更新を継続して行うことまで含めて決める必要があります。ここで手順が曖昧だと、運用の負荷が急に高くなります。

使うときに起こりやすい問題

• 有効期限の管理：期限切れは業務停止につながりやすい
• 秘密鍵の保護：漏えいすると、なりすましに使われるおそれがある
• 配布と更新の手段：端末台数が増えるほど手作業は維持しにくい
• 失効の扱い：紛失や退職、侵害が起きたときに、無効化をどう徹底するかが課題になる

失効が滞ると証明書は使い続けられてしまう

証明書は、信頼できる主体だと確認できることを前提に使われます。ところが、端末の紛失や退職が起きても失効が徹底されなければ、本来は無効にすべき証明書が残り続けます。発行だけでなく、担当者、手順、一覧確認、例外時の扱いまで決めておく必要があります。

もっと手間を抑えて作る方法

OpenSSLで作る以外にも、プライベート認証局を実装する方法はあります。細かく作り込みたいのか、日常の管理負担を抑えたいのかで、向く手段は変わります。

• 自前構築が向く場面：設計や保守を担える人材がいて、構成を細かく決めたい場合
• 製品導入が向く場面：発行、配布、更新、失効まで含めた日常の管理負担を抑えたい場合

たとえば、弊社のNetAttest EPSは、電子証明書を使うネットワーク認証に必要な機能をまとめたアプライアンス製品です。利用者や端末を識別する認証基盤を組みやすく、プライベート認証局の機能も管理画面から扱えます。

NetAttest EPSのプライベート認証局機能では、Web管理画面から電子証明書を発行できます。コマンド操作に不慣れな場合でも扱いやすく、大量発行や社内向けの運用方針を決める際の負担も抑えやすくなります。

プライベート認証局は、発行と失効を自組織の方針で管理できる一方、構築後の責任も自組織が負います。OpenSSLで作ることもできますが、発行後の管理まで考えると負担は軽くありません。日常の管理を進めやすくしたい場合は、プライベート認証局の機能を備えた製品も候補になります。