Windows
SCEPman を使用して Intune の SCEP 経由で Windows デバイスに証明書を展開します。
以下の記事では、Windows デバイス向けにデバイス証明書および/またはユーザー証明書を展開する方法について説明します。SCEPman のルート証明書の展開は必須です。その後、デバイス証明書のみ、ユーザー証明書のみ、あるいは両方の証明書タイプを展開するかを選択できます。
ルート証明書
SCEP 証明書を展開するための前提は、SCEPman のルート証明書を信頼することです。したがって、CA ルート証明書をダウンロードして、次として展開する必要があります。 信頼済み証明書 Microsoft Intune 経由のプロファイル：
Trusted 証明書と SCEP プロファイルの割り当てに同じグループを使用する必要があることに注意してください。そうしないと Intune の展開が失敗する可能性があります。
デバイス証明書
サブジェクト名フォーマット： CN={{DeviceName}} または CN={{DeviceId}} または CN={{AAD_Device_ID}}
推奨： 使用する {{DeviceName}}を CN RDN に使用して、デバイス上または証明書を検索するときに証明書名が分かりやすくなるようにします。
オプション： が構成されている場合 CN={{DeviceId}} または CN={{AAD_Device_ID}}、SCEPman はサブジェクト名の CN フィールドを使用してデバイスを識別し、証明書のシリアル番号生成のシードとして使用します。Microsoft Entra ID (Azure AD) と Intune は 2 つの異なる ID を提供します：
{{DeviceId}}：この ID は Intune によって生成および使用されます。 （SCEPman 2.0 以上と AppConfig:IntuneValidation:DeviceDirectory が Intune または AADAndIntune){{AAD_Device_ID}}：この ID は Microsoft Entra ID (Azure AD) によって生成および使用されます。
もし CN={{DeviceId}} でも CN={{AAD_Device_ID}} でも CN フィールドに使用されない場合（例： CN={{DeviceName}}）、SCEPman はサブジェクト代替名 (SAN) に提供された Intune デバイス ID ((URI) 値： IntuneDeviceId://{{DeviceId}}) を基にデバイスを識別します。
重要： CN フィールドの選択は の自動失効動作 に影響します（Intune 管理下のデバイスに発行された証明書）。
必要に応じて他の RDN を追加できます（例： CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}）。サポートされている変数は Microsoft のドキュメント.
に記載されています （URI）値： IntuneDeviceId://{{DeviceId}}
サブジェクト代替名： URI フィールドは NAC ソリューションが Intune デバイス ID を基にデバイスを識別するために Microsoft によって推奨されています。値は次のようにするべきです：
この URI フィールドは必須です もし CN={{DeviceId}} でも CN={{AAD_Device_ID}} が サブジェクト名フォーマット フィールドで使用されていない場合。
必要に応じて DNS のような他の SAN 値を追加できます。
証明書の有効期間： 1 年
証明書が失効するまでの残り期間。デフォルトは 1 年に設定されています。
SCEPman は設定 AppConfig:ValidityPeriodDaysに設定された最大値に有効期間を制限しますが、それ以外は要求で構成された有効期間を使用します。
キー格納プロバイダー (KSP)： Trusted Platform Module (TPM) KSP に登録し、そうでなければ失敗させる
この設定はエンドユーザー証明書の秘密鍵の格納場所を決定します。TPM による格納はソフトウェア格納よりも安全です。TPM は鍵の盗難を防ぐための追加のセキュリティ層を提供します。
注意：一部の古い TPM ファームウェアには バグがあり 、TPM バックの秘密鍵で作成された一部の署名を無効にすることがあります。そのような場合、Wi-Fi や VPN 接続で一般的な EAP 認証に証明書を使用できなくなります。さらに、これが Autopilot のオンボーディングプロセスを破壊する可能性があります。
影響を受ける TPM ファームウェアのバージョンには次のものが含まれます：
STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100, 73.20.17568.6684
Intel: 11.8.50.3399, 2.0.0.2060
Infineon: 7.63.3353.0
IFX: Version 3.19 / Specification 1.2
IFX version 7.63.3353.0 specification 2.0
このファームウェアを搭載した TPM を使用する場合は、ファームウェアを新しいバージョンに更新するか、キー格納プロバイダーとして「Software KSP」を選択してください。
更新： 問題を引き起こしている RSA-PSS 署名アルゴリズムをレジストリから削除することで TPM バグを回避できます。詳細については次を参照してください： Richard Hicks の記事 および Microsoft Q&A
キー使用法： デジタル署名 および 鍵暗号化
両方の暗号処理を有効にしてください。
SCEPman は自動的にキー使用法を デジタル署名 および 鍵暗号化 に設定し、ここでの設定を上書きします。ただし設定 AppConfig:UseRequestedKeyUsages が true.
SCEPman は SHA-2 アルゴリズムをサポートします。 ルート証明書：
前のステップのプロファイル（ルート証明書プロファイル） 次から Intune プロファイルを選択してください：#Root Certificate 。 もし中間 CA
を使用している場合は、中間 CA の Trusted 証明書プロファイルを選択する必要があり、ルート CA のものではないことに注意してください！ 拡張キー使用：
クライアント認証, 1.3.6.1.5.5.7.3.2 次を選択してください： クライアント認証 (1.3.6.1.5.5.7.3.2) の下の事前定義済み値
。その他のフィールドは自動的に入力されます。 20
更新閾値（％）： この値は、デバイスが証明書を更新できるタイミング（既存証明書の残存寿命に基づく）を定義します。次の「証明書の有効期間」にある注意事項を読み、デバイスが長期間にわたって証明書を更新できるように適切な値を選択してください。20% の値を設定すると、有効期間が 1 年の証明書を持つデバイスは有効期限の 73 日前に更新を開始できます。 SCEP サーバー URL：SCEPman ポータルを開き、
Intune MDM の URL をコピーします
例
例
ユーザー証明書
次の #Device certificates の指示に従い、次の違いに注意してください：
サブジェクト名フォーマット： CN={{UserName}},E={{EmailAddress}}
必要に応じて RDN を定義できます。サポートされている変数は Microsoft のドキュメントに記載されています。ベースライン設定としてユーザー名（例：janedoe）とメールアドレス（例：[email protected]）を含めることを推奨します。
に記載されています （UPN）値： {{UserPrincipalName}}
サブジェクト代替名としてユーザー プリンシパル名を追加する必要があります。 『{{UserPrincipalName}}』をユーザー プリンシパル名 (UPN) タイプのサブジェクト代替名として追加してください。 これにより SCEPman が AAD 内のユーザーオブジェクトに証明書をリンクできるようになります。'Subject name format' の設定は自由に選択できます。
必要に応じて、メールアドレスなどの他の SAN 値を追加できます。
顧客のフィードバックによると、一部の VPN クライアント（例：Virtual WAN 用の Azure VPN Client）は証明書が TPM に格納されているとユーザー証明書を検出できない場合があるようです。代わりにソフトウェア KSP に登録してみてください。
例
ユーザー デジタル署名証明書
SCEPman を取引上の デジタル署名 （例：Microsoft Outlook での S/MIME 署名）に使用することができます。メッセージ署名に証明書を使用する予定がある場合は、Intune プロファイル構成に対応する拡張キー使用を追加する必要があります。
次の目的には SCEPman を使用しないでください ：メール暗号化（すなわち Microsoft Outlook での S/MIME メール暗号化（別途キー管理技術がない場合））。 SCEP プロトコルの性質上、秘密鍵素材をバックアップまたはアーカイブするメカニズムが含まれていません。 もしメール暗号化に SCEP を使用すると、後でメッセージを復号するための鍵を失う可能性があります。 次の構成変数を設定しないと、SCEPman によって要求された鍵使用法や拡張有効期間が SCEPman によって尊重されません：
AppConfig:UseRequestedKeyUsages（最大値は 1825 - 5 年が可能）trueAppConfig:ValidityPeriodDays（最大値は 1825 - 5 年が可能）365電子署名に使用されるユーザー証明書を展開するには、次の指示に従ってください：
デジタル署名 のための 次の #User certificates の指示に従い、次の相違点と注意事項に留意してください：
サブジェクト代替名
（必須）ユーザー プリンシパル名 (UPN)：
{{UserPrincipalName}}（必須）メールアドレス：
{{EmailAddress}}
デジタル署名証明書を展開する場合、UPN とメールアドレスを追加する必要があります。
拡張キー使用： セキュアメール (1.3.6.1.5.5.7.3.4)
クライアント認証, 1.3.6.1.5.5.7.3.2 セキュアメール (1.3.6.1.5.5.7.3.4) クライアント認証 (1.3.6.1.5.5.7.3.2) の下の事前定義済み値
更新閾値（％）： 50
S/MIME 署名証明書を発行する場合、証明書が有効期限の少なくとも 6 か月前に更新されることを確実にするような値に更新閾値（％）を設定することを推奨します。これは、有効期限切れの証明書で署名されたメールが Outlook で無効な署名として表示され、ユーザーを混乱させるためです。古い証明書の有効期限よりかなり前に新しい証明書を用意しておくことで、この挙動が古いメールに限定され、ユーザーがそれを参照する可能性が低くなります。例えば、署名証明書の有効期間が 1 年の場合、更新閾値は少なくとも 50% に設定するべきです。
例
プロファイルの同期が正常に完了した後、以下の Intended Purposes に対するユーザー証明書が表示されるはずです： セキュアメール
証明書は例えば Outlook でのデジタル署名用途に利用可能になります。以下は使用例の一例です：
Microsoft Outlook で S/MIME 署名を有効にする
最新の Outlook クライアントでは S/MIME 機能が利用できない場合があります。詳細情報は こちら.
S/MIME 署名証明書をクライアントマシンに展開したら、署名付きメールを送信する前に Outlook をこれらの証明書を使用するように構成する必要があります。手動で行うことも、当社の次のスクリプトを使用することもできます： Outlook を構成する PowerShell スクリプト.
Outlook on the Web で S/MIME 署名を有効にする
ローカルの Windows マシンの証明書を使用して Outlook on the Web で S/MIME によるメール署名ができます。次のコマンドでこれを有効にする必要があります：
詳細については https://learn.microsoft.com/en-us/powershell/module/exchange/set-smimeconfig を参照してください。
最終更新
役に立ちましたか？