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

証明書ベースの WiFi、LAN、または VPN 認証を実現するために、Network Access Controller (NAC) として当社の RADIUS-as-a-Service を使用することを推奨します。これは、ワンクリックでの構成が可能だからです。ただし、SCEPman の証明書は、標準の 802.1x 証明書ベース認証をサポートするすべての NAC で一般的に動作します。

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

## RADIUS-as-a-Service

以下をご参照ください。 [RADIUS-as-a-Service documentation](https://docs.radiusaas.com/configuration/get-started/scenario-based-guides/scepman-pki) SCEPman の証明書を RADIUS-as-a-Service でどのように使用するかをご覧ください。

## Cisco ISE

{% hint style="info" %}
これは Cisco ではもはや必要ありません。&#x20;

* ISE Release 3.2 Patch 8 以降、
* ISE Release 3.3 Patch 5 以降、
* ISE Release 3.4 Patch 2 以降
  {% endhint %}

Cisco ISE は、OCSP 要求に対して HTTP 1.1 をサポートせず、HTTP 1.0 のみをサポートすることが一般的です。そのため、SCEPman の前に追加の Application Proxy が必要になります。詳細は、当社の [ISE のトラブルシューティング記事](https://docs.scepman.com/ja/sono/troubleshooting/cisco-ise-host-header-limitation) を参照してください。

少なくとも Cisco ISE 3.x の一部のバージョンでは、RFC 上は CA からの応答であれば不要であっても、OCSP 応答を受け入れるために、OCSP Responder Extended Key Usage を含む Extended Key Usage 拡張が必要です。1.7 までの SCEPman では、CA 証明書に Extended Key Usage が既定で追加されていませんでした。バージョン 1.8 では、 [構成設定](https://docs.scepman.com/ja/scepman-no/application-settings/dependencies-azure-services/azure-keyvault#appconfig-keyvaultconfig-rootcertificateconfig-addextendedkeyusage)を介してこの拡張を追加できます。SCEPman 1.9 では、構成設定の既定値によってすでに Extended Key Usage が追加されます。すでに Extended Key Usage 拡張のない CA 証明書をお持ちで、Cisco ISE 3.x で問題がある場合は、Extended Key Usage 拡張付きの新しい SCEPman Root CA 証明書を作成する必要があるかもしれません。

## Aruba ClearPass

### Microsoft Intune ClearPass Extension

Aruba の [Microsoft Intune ClearPass Extension](https://arubanetworking.hpe.com/techdocs/NAC/clearpass/integrations/unified-endpoint-management/intune/) を ClearPass Policy Manager 内で使用している場合、デバイス ID を [SCEP certificate template](https://docs.scepman.com/ja/zheng-ming-shu-guan-li/microsoft-intune/windows-10#device-certificates) に特定の形式で追加する必要があります。SCEPman との互換性を確保するため、以下の SAN 属性が次の **順序**:

* `(URI)` 値: `DeviceId:{{DeviceId}}`
* `(URI)` 値: `AAD_Device_ID:{{AAD_Device_ID}}`
* `(URI)` 値: `IntuneDeviceId://{{DeviceId}}`&#x20;

{% hint style="info" %}
最初の 2 つのエントリは ClearPass で使用され、3 つ目のエントリは SCEPman で使用されます。
{% endhint %}

### OCSP HTTP 1.0 Issue

{% hint style="info" %}
これは **もはや必要ありません** ClearPass 6.9.6 以降では。
{% endhint %}

Cisco ISE と同様に、Aruba ClearPass は OCSP 要求に HTTP 1.0 を使用するため、SCEPman と連携するには [Application Proxy を追加する追加の構成手順](https://docs.scepman.com/ja/sono/troubleshooting/cisco-ise-host-header-limitation) が必要です。

## Microsoft Network Policy Server (NPS)

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

## その他

一般に、SCEPman Root CA 証明書を NAC で信頼済み CA として追加する必要があります。

場合によっては、SCEPman の OCSP URL を手動で追加する必要があります。OCSP URL は、任意のクライアント証明書の Authority Information Access (AIA) 拡張で確認できます。
