証明書ベースのネットワーク認証

証明書ベースの WiFi、LAN、または VPN 認証を実現するために、ワンクリック構成を可能にするネットワークアクセスコントローラ（NAC）として当社の RADIUS-as-a-Service の使用を推奨します。ただし、SCEPman の証明書は標準の 802.1x 証明書ベース認証をサポートするすべての NAC で一般的に動作します。

この記事では、最も一般的な NAC のいくつかの注目すべき特徴について説明します。

RADIUS-as-a-Service

以下を参照してください。 RADIUS-as-a-Service ドキュメント で SCEPman 証明書を RADIUS-as-a-Service で使用する方法を確認してください。

Cisco ISE

これはもはや不要です（Cisco

• ISE リリース 3.2 パッチ 8 以降、

• ISE リリース 3.3 パッチ 5 以降、

• ISE リリース 3.4 パッチ 2 以降）。

Cisco ISE は通常 OCSP リクエストに対して HTTP/1.1 をサポートせず HTTP/1.0 のみをサポートするため、SCEPman の前に追加のアプリケーションプロキシが必要になります。詳細は当社の ISE 向けトラブルシューティング記事 を参照してください。

Cisco ISE 3.x の少なくとも一部のバージョンでは、RFC 上は CA からの応答に必須でない場合でも、OCSP レスポンダ用の拡張キー用途（Extended Key Usage）を含む拡張キー用途拡張を OCSP 応答として受け入れるために必要とします。SCEPman のバージョン 1.7 までは CA 証明書にデフォルトで拡張キー用途を追加していませんでした。バージョン 1.8 では設定項目を通じてこの拡張を追加できるようになっています。 設定項目。SCEPman 1.9 では、設定項目のデフォルトで既に拡張キー用途が追加されます。すでに拡張キー用途拡張のない CA 証明書を持っていて Cisco ISE 3.x に問題がある場合は、拡張キー用途拡張を含む新しい SCEPman ルート CA 証明書を作成する必要があるかもしれません。

Aruba ClearPass

Microsoft Intune ClearPass 拡張

Aruba の Microsoft Intune ClearPass 拡張 を ClearPass Policy Manager 内で使用する場合、デバイス ID を特定の形式で SCEP 証明書テンプレート に追加する必要があります。SCEPman と互換性を確保するために、以下の SAN 属性が次の 順序:

• （URI） 値： DeviceId:{{DeviceId}}

• （URI） 値： AAD_Device_ID:{{AAD_Device_ID}}

• （URI） 値： IntuneDeviceId://{{DeviceId}}

最初の2つのエントリは ClearPass で使用され、3 番目のエントリは SCEPman で使用されます。

OCSP HTTP 1.0 の問題

これは もはや不要です （ClearPass 6.9.6 以降）。

Cisco ISE と同様に、Aruba ClearPass は OCSP リクエストに HTTP/1.0 を使用するため、SCEPman と連携させるには追加のアプリケーションプロキシを追加する等の 追加の構成手順 が必要です。

Microsoft Network Policy Server (NPS)

NPS は証明書を AD（AAD ではなく）のデバイスまたはユーザーエンティティにマッピングします。AAD と AD 間のデバイス同期が標準では存在しないため、Intune を介して配布されたデバイス証明書を SCEPman や他の PKI と組み合わせて NPS で使用することは通常不可能です。ユーザー証明書は AAD と AD 間で同期されたユーザーには機能する可能性があります。証明書には NPS が同じ UPN を持つ AD ユーザーオブジェクトにマップするために使用するユーザーの UPN が含まれている必要があります。

その他

一般に、NAC に SCEPman ルート CA 証明書を信頼された CA として追加する必要があります。

場合によっては、SCEPman の OCSP URL を手動で追加する必要があります。OCSP URL は任意のクライアント証明書の Authority Information Access（AIA）拡張に記載されています。