信頼済み証明書
信頼済み証明書の種類
クライアント認証用の信頼済み CA
クライアント認証用の信頼済み CA は、エンドポイント デバイスにクライアント認証証明書を発行する CA と RADIUSaaS の間の信頼関係を確立します。
信頼済み RadSec 接続証明書
RadSec 自体は相互証明書認証（mTLS）で動作します。つまり、片方では、認証器は RADIUSaaS を信頼する必要があり もう片方では、RADIUSaaS が有効な RadSec 接続を確立できるように、どの認証器を信頼するかを知っていなければなりません。信頼済み RadSec 接続証明書は、RADIUSaaS が指定した認証器だけを信頼することを保証します。
事前インストールされた信頼済み RadSec 証明書
上記の ため、少なくとも 1 つの RadSec 信頼済み証明書が常に表示され、あなたの RADIUS プロキシ との信頼関係を確立します（実質的に RadSec クライアントとして動作します）。プロキシが正しく起動し、インスタンスへの接続を確立できるようにするため、これを削除することはできません。
追加
階層型 PKI インフラストラクチャ（たとえば Microsoft レガシ PKI）をお使いの場合は、 こちら.
新しい信頼済み証明書を追加するには、次の手順に従います：
をクリックします 追加
信頼済み証明書にインポートする場合は選択してください
SCEPman から（SCEPman インスタンスの URL を指定して）、または
その他の CA から（PEM または DER エンコードの証明書ファイルをアップロードして）
証明書ファイルをドラッグ＆ドロップでアップロードします（または青い領域をクリックしてファイルを選択できます）
証明書の検証オプションを選択してください：
OCSP 自動検出：RADIUSaaS は、ネットワーク認証に使用されるクライアント証明書の Authority Information Access（AIA）拡張から OCSP 応答者 URL を推測しようとします。OCSP 応答者 URL が見つからない場合、または OCSP 応答者が利用できない場合、RADIUSaaS は ソフトフェイル 構成を考慮します。
OCSP：信頼済み CA によって発行された任意の証明書に対して使用される OCSP 応答者 URL を手動で指定します。OCSP 応答者が利用できない場合、RADIUSaaS は ソフトフェイル 構成を考慮します。
CRL：選択すると、RADIUSaaS は CA によって発行された証明書の検証に OCSP の代わりに CRL を使用します。CRL のエンコード（DER または PEM）と CRL 配布ポイント.
なし： CA が OCSP も CRL もサポートしていない場合は、 なし を選択して検証をスキップします。
をクリックします 保存
削除
証明書を削除するには、対応する行を展開し、 削除 をクリックして選択を確定します。
OCSP ソフトフェイル
この設定は、信頼済み CA の OCSP 応答者に到達できない場合に RADIUSaaS がどのように動作するかを決定します。
この設定を 無効にすると 、認証要求は 拒否されます 。これは、CA の OCSP 応答者に到達できない場合です。
確認してください OCSP ソフトフェイルの影響 この設定の影響を理解していることを確認してください。
この設定は、 OCSP 自動検出 または OCSP が証明書検証に選択されている場合にのみ利用できることに注意してください。
既定では、 OCSP ソフトフェイルを有効にすることを推奨します 。OCSP 応答者に到達できない場合でも認証要求を受け入れられるようにして、サービスの可用性を高めるためです。この ソフトフェイル メカニズムでは、OCSP に到達できない場合、RADIUSaaS は受信した証明書が 信頼済み CA のいずれかによって署名されているかだけを確認し、任意の ルール.
階層型 PKI 階層
複数の発行 CA が構成された階層型 CA 環境では、ルート CA または任意の発行 CA から発行された証明書は、その証明書がルート CA から発行されたものか発行 CA から発行されたものかに関係なくアクセス権を取得します。つまり、ルートを信頼すると、任意の発行 CA から発行された証明書も自動的に信頼されます。 アクセスを発行 CA に基づいて制御する必要がある場合は、 それぞれのルール.
考慮事項
階層型 PKI のルート CA と発行 CA をアップロードする際は、次の点にご注意ください：
この ルート CA を最初にアップロードする必要があります。その後、このルート CA から派生した発行 CA をアップロードしてください。
ルート CA と発行 CA は別々のファイルでアップロードする必要があります。単一ファイルから証明書チェーンをアップロードすると、予期しない動作が発生する場合があります。
オプション設定
Intune ID
Microsoft Entra ID（Azure AD）参加時に、各 Windows 10 マシンが Intune から受け取る証明書を使用することができます。
この設定は任意です。Intune 証明書に詳しくない場合は、設定しないでください。
なぜ認証目的で Intune 証明書の使用を推奨しないのですか？
Intune 証明書は、Intune による管理以外の目的では Microsoft によりサポートされていません。
Intune 証明書の有効期限は 1 年です。
証明書を失効させる仕組み（OCSP など）がありません。
Intune 証明書の代わりに、のような PKI の証明書を使用することを推奨します SCEPman.
Intune ID を構成する
この設定は慎重に使用してください。次の ID のいずれか が 証明書拡張 1.2.840.113556.5.14 に存在しなければなりません。その他すべての証明書は 拒否されます.
Intune テナント ID を取得するには、次の手順に従います：
押して Windows + R と入力し certlm.msc
個人証明書に移動します。次のいずれかの発行者の証明書があるはずです
SC Online Issuing
MDM Device Authority
この証明書を開き、 詳細 に移動して拡張を検索します
1.2.840.113556.5.14
表示された HEX 値があなたの Intune テナント ID です。
例：
次の証明書のテナント ID は次のとおりです： bb4397cb6891c64db17f766487518a6a
XML
RADIUSaaS によって生成された XML プロファイルにより PMK キャッシュ.
今日では、ほとんどの MDM プラットフォームが、ネットワーク プロファイル（WiFi および LAN）を展開するためのウィザード ベースの方法を提供しています。これが不可能であるか、ウィザードが限られた構成オプションしか提供しない場合は、RADIUSaaS プラットフォーム上で生の XML プロファイルを直接生成できます。
次の WiFi XML プロファイルを生成するには：
メニューを展開し、 XML 希望するセキュリティ プロトコル（WPA2 または WPA3）を選択し、
あなたの
SSID を入力し、 そして
ダウンロード をクリックします.
次の 有線 XML プロファイルをクリック をクリックします.
最終更新
役に立ちましたか？