プライベートCAとパブリックCA：選び方を間違えているかもしれません

余裕のないIT部門にとって、パブリックな認証局（CA）は万能のハンマーのように見え、暗号化の要件はすべて釘のように見えてきます。しかし、あらゆる用途にパブリックCAを使うことは、本番環境を静かに壊す最もよくある原因の1つです。

パブリックCAが想定する用途

パブリックCA（DigiCert、Sectigo、Let's Encryptなど）が主に想定しているのは1つのシナリオ、すなわち自社が管理していないデバイスとの間で信頼を確立する場面です。外部の利用者が自分の側で何も設定しなくても、自社のサイトやサービスを信頼できるようにする、という考え方です。

パブリックCAが適しているのは、次のような場合です：

• 自社とあらかじめ信頼関係のない外部の利用者、顧客、パートナー向けに、一般公開のサービスを運用している
• 外部のAPIやサービスが、独自のクライアント設定なしに自社のインフラストラクチャーへ接続する
• 証明書のエラーが、エンドユーザーにブラウザーの警告として表示される
• メールに署名しており、受信者が事前の設定なしに署名を検証する必要がある

パブリックCAが発行できる内容は、CA/Browser Forumが定めています。つまり自社では左右できないルールに従うことになりますが、上記のシナリオであれば、多くの組織にとって妥当な折り合いです。問題になりうるのは、同じ証明書を社内の認証に使う場合です。

プライベートCAが想定する用途

プライベートCAは、自社で運用する、あるいはベンダーが自社に代わって運用する認証局です。発行ポリシーは自社で定めます。発行した証明書は、既定ではどこからも信頼されません。グループポリシー、Intune、あるいは利用中のMDMプラットフォームを通じてプライベートCAのルート証明書をデバイスとユーザーに配布すると、管理下のエンドポイントはプライベートCAが発行した証明書を信頼するようになります。

自社のインフラストラクチャーだけが証明書を信頼すればよい用途には、プライベートCAが適しています：

• デバイス認証。そのマシンが管理下にあり、自社に属することを証明します
• ユーザー証明書による認証。パスワードレスログイン、スマートカード相当の認証、社内アプリケーションへのアクセスなどです
• Wi-Fi（802.1X）とVPN接続の保護
• バックエンドのマイクロサービス間での相互TLS（mTLS）の構成
• 社内ツールやスクリプトのコード署名

信頼チェーンと発行ポリシーを完全に自社で管理でき、外部のCAガバナンスに依存しません。

パブリックCAとプライベートCAの比較

つまずきやすい点

IT部門が犯す最もよくある間違いは、社内の認証にパブリックCAの証明書を使うことです。パブリックCAはもともと社内向けワークロードを想定していません。そして今まさに進んでいる2つの変化が、そのずれを無視できないものにしています。

1. パブリックTLS証明書からのクライアント認証EKUの廃止

パブリックに信頼されるTLS証明書は、クライアント認証EKUを含められなくなりました。CA/Browser ForumのBallot SC-081と主要なルートプログラムの更新を受けて、パブリックCAは2027年3月の最終期限に先駆けてclientAuthを段階的に廃止しています。社内のデバイス認証やユーザー認証をパブリック証明書に依存している場合、次回の更新時にその構成は動作しなくなります。

2. 急速に短くなる有効期間

パブリックCAは証明書の有効期間を継続的に短縮しています。SC-081v3のもとで、パブリック証明書の有効期間の上限は200日（2026年）となり、2027年3月には100日、2029年3月までに47日へと短くなります。公開Webサーバーであれば自動化ツールが90日ごとの更新を問題なく処理できますが、社内の数千台のノートPCやデバイスを6週間ごとに再登録するのは、管理上の悪夢です。

プライベートCAは、こうした制約の外にあります。失効の処理を自社環境の内部で直接行うため、人為的に短い有効期間や外部の検証チェックは必要ありません。自社のチームに合った有効期間とルールを自分たちで決められます。

どちらを使うかの判断基準

環境内の証明書ごとに、次を問いかけてください。この証明書を検証する必要があるデバイスやクライアントを、すべて自社で管理しているでしょうか。

• 管理している場合：プライベートCAを使います。ルートCA証明書を配布し、発行内容を自社で管理でき、外部のルール変更に左右されなくなります。
• 管理していない場合：パブリックCAが必要です。事前の設定なしに外部から接続する相手には、そのデバイスがすでに信頼しているCAが必要だからです。

多くのIT部門は、結局どちらも必要になります。外部公開のサービスにはパブリック証明書、デバイス、ユーザー、社内サービスにはプライベート証明書です。

SCEPmanの位置づけ

SCEPmanは、Microsoft IntuneおよびEntra IDと連携し、SCEPとESTを通じて他のMDMプラットフォームとも統合できる、クラウドネイティブなプライベートCAです。管理下のデバイスとユーザーについて、証明書の発行を自動で処理します。

Intune環境では、SCEPmanは証明書の有効性をデバイスのコンプライアンス状態に結び付けます。ワイプされたデバイスやコンプライアンスから外れたデバイスは証明書を失い、Wi-Fi、VPN、社内アプリケーションへのアクセスが自動的に遮断されます。

SCEPmanは、Certificate Masterを使って証明書を手動で発行することもできます。これにより、IT部門はWebポータル、アプリケーション、デバイス管理インターフェイスといった社内システム全体で、パブリックCAの証明書を置き換えられます。

着手の仕方

プライベートCAをまだお持ちでない場合や、レガシーなオンプレミスのActive Directory Certificate Services（ADCS）から移行したい場合は、そこがSCEPmanについてご相談いただくよい出発点になります。

SCEPmanをご自身でお試しください

30日間トライアルを開始して、自社でPKIを運用する負荷なしに、SCEPmanがデバイス、ユーザー、社内サービスのプライベートCA証明書を発行し管理する方法をご確認ください。

SCEPmanの30日間トライアルを開始

よくあるご質問