Intune クラウドPKIの証明書でネットワーク認証もやってみた。

クラウドPKIでユーザ証明書が配れるのなら、ネットワーク認証にも使用できるのでは？

過去はオンプレ環境のプライベートCAから配ることが一般的だったネットワーク認証用クライアント証明書。

CAの管理、証明書の配布、更新についてはいつもIT管理者の悩みのタネでした。

現在の認証のトレンドはパスワードレスやSSO、パスキーなどが挙げられますが、ここに加えて証明書認証も再注目されている模様です。
そしてMicrosoftが現在提供しているクラウドサービスのMDMであるIntuneはクラウドPKIとして証明書配布機能を備えており、Intuneに管理されたデバイスに対しクラウドにあるCAからユーザ証明書を自動配布することが可能です。

・・・ん？ユーザ証明書が端末に配布できるということは、ネットワーク認証にもIntuneから配布した証明書がそのまま利用できるのではないだろうか？

ということで、実際にIntuneから配布された証明書を使ってオンプレ環境に構築したRADIUSサーバと組み合わせ、実際にEAP-TLS認証を行ってみました。

検証構成は以下の通りです。

なおIntuneのクラウドPKIを利用するためにはEntraのサブスクリプション、およびIntune SuiteもしくはIntune+アドオンが必要となるためサブスクリプションのレベルには注意が必要です。

(2026年中にMicrosoft 365 E5契約でも利用可能になるようです。参考：Microsoft 365にMicrosoft Intuneの高度なソリューションを追加)

実際に配ってEAP-TLSをやってみた

Intuneから証明書を配布する手順については下記のNET ONE BLOGで詳しく解説されています。

Microsoft Cloud PKI でらくらく証明書配布～そしてパスワードレス認証へ～

なおクラウドPKIは現時点でサーバ証明書を発行できないため、認証用のRADIUSサーバはプライベートCAから発行されたサーバ証明書を使用しました。

今回の環境では上記の図のような証明書のトラストチェーン構造となる関係で、Intuneから配布する証明書に「RADIUSサーバの証明書を検証するのに必要なトラストチェーンに含まれるCA証明書(RADIUSサーバ側のサーバ証明書を発行しているルートCAのCA証明書)」を加える必要があります。
今回はプライベートルートCAから直接発行しているため、プライベートCAのルート証明書を配布するための信頼済み証明書配布プロファイルを追加で作成しました。

端末がIntuneと同期すると、以下の4つの証明書が端末内に作成されます。

• Intune クラウドPKI　ルート証明書
• Intune クラウドPKI 発行用CAの中間CA証明書
• Intune クラウドPKIより発行されたユーザ証明書
• RADIUSサーバのサーバ証明書を署名したトラストチェーン内のCA証明書郡(今回はプライベートルートCAのルート証明書のみ)

今回はEAP-TLSテスト環境にCisco Catalyst9800-CL+Catalyst CW9166の無線LAN環境および認証サーバとしてCisco ISEを用いてネットワーク接続をテストしました。

ISE側にはあらかじめクラウドPKIで使用しているルート証明書、および証明書発行用CAの中間CA証明書をTrusted Certificate Storeへインポートしておきます（証明書ファイルはクラウドPKIの設定画面からダウンロードが可能です）。

ISEはデフォルトの証明書検証の動作として証明書の検証が成功すれば接続OKとなるため、クライアント/ISE双方で証明書の検証が成功すれば接続完了となります。

今回の構成では証明書の検証は問題なく完了し、無事にクラウドPKIから発行された証明書でEAP-TLSが行えることが確認できました。

EAP-TLS認証をテストする中で見えてきたメリットと注意点

クラウドPKIを利用することでクライアント側に対する証明書発行は非常に楽になりましたが、併せてEAP-TLS認証をテストする環境を構築する中で見えてきた注意点もあります。

メリット：デバイスにインターネット疎通性があれば社内ネットワークでなくても証明書の配布が可能

従来のオンプレミス環境で構築したPKI環境の場合、証明書を配布する際は適切なネットワークに端末が存在する必要がありました。しかしクラウドPKIはIntuneの機能として提供されているがゆえ、クラウドと疎通性があれば必ずしも社内ネットワークである必要はなく、モバイル環境やテレワーク利用時の社員の自宅ネットワークなど、Intuneへ疎通性がある環境であれば証明書の配布・更新・失効処理が可能です。
昨今はフルリモート勤務の場合や出社/テレワークを柔軟に組み合わせるハイブリッドワークなどを勤務形態の基本として採用している企業も多く、どこからの接続でもリアルタイムで証明書の変更に追従できるのは大きなメリットと言えます。

注意点：クラウドPKIを利用可能なサブスクリプションレベルに注意が必要

現在はクラウドPKIを利用可能なサブスクリプションレベルはIntune Suiteに限定(もしくはIntuneサブスクリプション+アドオン)されています。これはIntuneのサブスクリプションの中での最上位のレベルのため、ユーザ数が多いほど月額コストが増加します。この注意点は2026年中に利用可能になるMicrosoft365についても同様で、E5で利用可能と最上位のサブスクリプションレベルでの対応となるため、クラウドPKIの利用のみを目的として契約するにはコスト負担が大きい可能性があります。Intune SuiteライセンスやMicrosoft E5の他の機能を同時に利用する等、上位のサブスクリプションレベルで提供される機能を多数使用する場合にクラウドPKIのメリットも最大限に享受することが可能になります。

注意点：現時点の機能実装では管理外の機器(サーバ等)にクラウドPKI側から証明書を発行できない

クラウドPKIはIntuneに管理されたデバイス/Entraに管理されたユーザに対して証明書を発行する機能のため、EAP-TLS等の認証方式では必要となる「認証サーバ側のサーバ証明書」の発行が行えないというデメリットがあります。
そのためサーバ証明書は別途オンプレミス環境に立てたPKIインフラストラクチャから発行するか、外部のパブリックな発行機関から発行してもらう必要があります。
前者であればPKIインフラストラクチャを二重で管理しなければいけなくなるため管理コストは2倍必要となる点には注意が必要です。一方、多数あるクライアントへのクライアント証明書の配布コストは大きく低下する余地があるため、トータルの管理コストがどれくらいになるかについては環境次第で大きく変わってきます。
後者についてはサーバ証明書のみの発行となるので発行枚数は少なくなりますが、確実に発行コストはかかることになります。

注意点：(2026/3月時点では)OCSPに対応していない

クラウドPKI環境では証明書の失効確認を行うプロトコルがCRLに限定されており、OCSPには対応していません。(2026/3月時点)
CRLは執行した証明書をリスト化して認証サーバがそのリストをダウンロードするという方法です。CRLでは原理上「最新のCRL以降に新たに失効した証明書は次回のCRL更新までは認証サーバ側で失効されてないものとして扱われる」という弱点があり、OCSPと比較してリアルタイム性で劣ります。

クラウドの属性情報も併せて参照する

802.1X/EAP-TLS認証では証明書の検証だけを行って接続する、というケースはゼロではありませんが、多くのエンタープライズ環境では以下のような情報を利用した認可制御を行っているところも多いかと思います。

• 証明書に含まれる追加属性(OUやSANなどに含まれる情報)
• 証明書に紐づくユーザの追加属性情報(ディレクトリサーバ上のユーザに関する追加情報)

クラウドPKIではその性質上、ユーザアカウントおよびアカウントに紐づく追加属性情報はEntraに格納されており、情報を利用する場合はEntraのユーザ情報を確認することになります。
今回認証サーバとして利用したCisco ISEではEntra連携が行えるため、この機能を利用しEntraで所属しているユーザグループに応じた認可振り分け(特定グループに所属しているアカウントだけ無線LAN接続が可能)を実施しました。
なおCisco ISE側の仕様により、EntraのIDと証明書をマッチングさせる場合、証明書のCNはUserPrincipanNameである必要があります。この仕様に適合させるため、クラウドPKIのSCEP設定を以下のスクリーンショットのように変更し証明書の発行を行いました。

CNがUserPrincipalNameと一致するユーザ証明書を用いて、Entraと連携するCisco　ISEにてEAP-TLSを行ったところ、以下のようにEntra側のグループを参照して意図した挙動(特定のユーザグループのみ無線LAN接続を許可する)を実現することができました。

まとめ

クラウドPKIは現時点ではフルのCAではなく、クライアント向けの証明書しか発行することができない制限はあるものの、社内ネットワークに接続せずに自動的に多数のクラアイントに対して証明書を一括で生成配布することができる点は管理性においては非常に大きなメリットです。クライアント側に配る証明書(デバイス証明書、ユーザ証明書)の重要性は日々増しており、様々な認証で必要とされるケースが多くなっています。
従来であればこのような状況の場合、自前でプライベートPKI環境を立てて運用を行うことが一般的でしたが、PKI環境維持のための運用コストが負担になっていた企業も多いと思います。
今日ではID基盤もオンプレにあるActiveDirectoryからEntraを中心にしたクラウド基盤へ、EntraとActiveDirectoryとを組み合わせたハイブリッド型のID基盤となっている企業も徐々に増えてきており、EntraがあるのであればクラウドPKIは導入のハードルはぐっと下がります。発行した証明書はネットワーク認証であるEAP-TLSでも問題なく利用できるため、PKI基盤の運用と配布をどのようにするか考えている企業には選択肢の一つとして考えても良いと思います。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。