Windows
SCEPman を使用して、Intune の SCEP 経由で Windows デバイスに証明書を展開します。
次の記事では、Windows デバイス向けにデバイス証明書および/またはユーザー証明書を展開する方法について説明します。SCEPman ルート証明書の展開は必須です。その後、デバイス証明書のみ、ユーザー証明書のみ、または両方の証明書タイプを展開することを選択できます。
ルート証明書
SCEP 証明書を展開するための基礎は、SCEPman のルート証明書を信頼することです。そのため、CA ルート証明書をダウンロードして、 信頼された証明書 プロファイルとして Microsoft Intune 経由で展開する必要があります:


信頼された証明書と 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 によって生成され、使用されます。 (次が必要です AppConfig:IntuneValidation:DeviceDirectory を次のように設定する Intune または AADAndIntune){{AAD_Device_ID}}: この ID は Microsoft Entra ID (Azure AD) によって生成され、使用されます。
どちらも CN={{DeviceId}} も CN={{AAD_Device_ID}} も CN フィールドに使用されない場合 (例: CN={{DeviceName}})、SCEPman は Intune デバイス ID ((URI) 値: IntuneDeviceId://{{DeviceId}}) をサブジェクト代替名 (SAN) で提供されたものに基づいてデバイスを識別します。
これらの変数と固定テキストをテキストボックスに指定できます。たとえば、次の名前のデバイスの共通名 Device1 は次のように追加できます CN={{DeviceName}}YourDomain.com
重要: CN フィールドの選択は、 自動失効動作 に影響します。これは、Intune 管理下のデバイスに発行された証明書に対するものです。
必要に応じて他の RDN を追加できます (例: CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}} )。サポートされている変数は、 Microsoft のドキュメント.
サブジェクト代替名: (URI)値: IntuneDeviceId://{{DeviceId}}
URI フィールドは、 Microsoft により推奨されています 。これは NAC ソリューションが Intune デバイス ID に基づいてデバイスを識別するためです。値は次のとおりである必要があります:
この 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: バージョン 3.19 / 仕様 1.2
IFX バージョン 7.63.3353.0 仕様 2.0
このファームウェアで TPM を使用している場合は、ファームウェアを新しいバージョンに更新するか、キー ストレージ プロバイダーとして「Software KSP」を選択してください。
更新: 問題の原因となっている RSA-PSS 署名アルゴリズムをレジストリから削除することで、TPM バグを回避できます。詳細については、 Richard Hicks の記事 および Microsoft Q&A
キー使用法: デジタル署名 および キー暗号化
両方の暗号化アクションを有効にしてください。
SCEPman はキー使用法を自動的に デジタル署名 および キー暗号化 に設定し、設定 AppConfig:UseRequestedKeyUsages が true.
ルート証明書: 前の手順のプロファイル (ルート証明書プロファイル)
から Intune プロファイルを選択してください #Root Certificate。 中間 CA を使用している場合は、 中間 CAの信頼された証明書プロファイルを選択する必要があります。ルート 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
例
例

ユーザー証明書
次の手順に従ってください #Device certificates 。また、次の違いに注意してください:
サブジェクト名の形式: CN={{UserName}},E={{EmailAddress}}
必要に応じて RDN を定義できます。サポートされている変数は、 Microsoft のドキュメントに一覧表示されています。ベースライン設定として、ユーザー名 (例: janedoe) とメール アドレス (例: janedoe@contoso.com) を含めることを推奨します。
サブジェクト代替名: (UPN)値: {{UserPrincipalName}}
サブジェクト代替名としてユーザー プリンシパル名を追加する必要があります。 タイプが User principal name (UPN) の Subject Alternative Name として '{{UserPrincipalName}}' を追加します。 これにより、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 を使用すると、後でメッセージを復号するためのキーを失う可能性があります。
AppConfig:UseRequestedKeyUsagesに設定trueAppConfig:ValidityPeriodDaysに設定365(最大値 1825 - 5 年まで可能)
次に使用されるユーザー証明書を展開するには デジタル署名 、次の手順に従ってください #User certificates 。また、次の違いと注意事項に留意してください:
サブジェクト代替名
(必須) User principal name (UPN):
{{UserPrincipalName}}(必須) メール アドレス:
{{EmailAddress}}
デジタル署名証明書を展開する場合は、UPN とメール アドレスを追加する必要があります。
拡張キー使用法: Secure Email (1.3.6.1.5.5.7.3.4)
次を選択してください Secure Email (1.3.6.1.5.5.7.3.4) の下にある 定義済みの値。他のフィールドは自動的に入力されます。
更新しきい値 (%): 50
S/MIME 署名証明書を発行する場合、証明書が有効期限の少なくとも 6 か月前に更新されるように、更新しきい値 (%) を設定することを推奨します。これは、有効期限切れの証明書で署名されたメールが Outlook で無効な署名として表示され、ユーザーを混乱させるためです。古い証明書の有効期限が切れるかなり前に新しい証明書を用意しておくことで、この動作を示すのが古いメールだけとなり、ユーザーがそれを見る可能性は低くなります。たとえば、署名証明書の有効期間が 1 年である場合、更新しきい値は少なくとも 50 % に設定する必要があります。
例

プロファイルの同期が正常に完了すると、対象用途が Secure Email

であるユーザー証明書が表示されるはずです。この証明書は、たとえば Outlook でデジタル署名用途に使用できます。以下はその使用例です

Outlook で S/MIME 署名を有効にする
クライアント マシンに S/MIME 署名証明書を展開したら、署名付きメールを送信する前に、Outlook がこれらの証明書を使用するように構成する必要があります。
新しい Outlook
新しい Outlook 用の S/MIME は、 手動で.
クラシック Outlook
クラシック Outlook 用の S/MIME は、 手動で または当社の PowerShell スクリプト.
Outlook on the Web
Outlook on the Web 用の S/MIME は、 手動で または次のコマンドを使用して PowerShell で有効にできます:
追加の PowerShell コマンドは、 こちら.
最終更新
役に立ちましたか?