失効

SCEPman を使用した OCSP 経由での Microsoft Intune または Jamf Pro における自動証明書失効。

SCEPman は証明書の管理および失効を行ういくつかの方法を提供します。利用可能なオプションは次の点に依存します

  • 証明書が MDM ソリューションを介して自動的に登録されたか、あるいは次を介して生成されたかどうか Certificate Master UI / Enrollment REST API,

  • (自動)登録に使用される MDM システム、および

  • SCEPman の設定。

以下のセクションでは、さまざまな管理オプションと失効メカニズムの概要と、それらがどのような状況で利用可能になるかを示します。

自動失効

circle-info

次の場合にのみ利用可能 Microsoft Intune および/または Jamf Pro が証明書登録の MDM ソリューションとして使用されている場合。代替として、Microsoft Entra ID(Azure AD)とデバイスおよび/またはユーザーオブジェクトを同期できる任意のサードパーティ MDM(つまり Static AAD Validation を使用可能)が利用可能です。

circle-check

背景

自動失効は 常に有効であり 各証明書をユーザーやデバイス識別などのディレクトリオブジェクトに紐付けることで、便利な証明書ライフサイクル管理を可能にします。このオブジェクトバインディング機構を通じて、SCEPman は紐付けられたオブジェクトの特定のライフサイクル特性に基づいて失効状態を推定できます。オブジェクトのライフサイクル状態から証明書の失効状態への対応付けは、長年のセキュリティおよびエンドポイント管理の経験に基づくベストプラクティスに合わせて実装されています。

ディレクトリオブジェクト(ユーザーまたはデバイス)と証明書のバインディングは、Subject Name または Subject Alternative Name のプロパティに適切な変数を SCEP プロファイルに導入することで確立されます。MDM 管理クライアントからの証明書署名要求(CSR)を受信すると、SCEPman はバインドされたオブジェクトを識別し、この情報を証明書のシリアル番号にエンコードしてクライアントに返します。証明書検証時に SCEPman の OCSP レスポンダーに送信されるのはこのシリアル番号であり、SCEPman はシリアル番号からオブジェクト情報をデコードし、適切なディレクトリを検索して最終的に失効状態の判断を行います。

失効の挙動

circle-check
circle-exclamation
バインドされたオブジェクト
ディレクトリから削除
ディレクトリで無効化
オプション

Intune デバイス {{DeviceId}}

利用不可

Entra (Azure AD) デバイス {{AAD_Device_ID}}

削除: 永久的な失効

無効化: 可逆的な失効

Entra (Azure AD) ユーザー {{UserPrincipalName}}

削除: 永久的な失効

無効化: 可逆的な失効

Jamf コンピュータ CN=$JSSID,OU=computers

削除: 永久的な失効

利用不可

利用不可

Jamf デバイス CN=$JSSID,OU=devices

削除: 永久的な失効

利用不可

利用不可

コンピュータ上の Jamf ユーザー CN=$JSSID,OU=users-on-computers

  • (コンピュータ)を削除: 永久的な失効

  • (ユーザー)を削除: 永久的な失効

利用不可

利用不可

デバイス上の Jamf ユーザー CN=$JSSID,OU=users-on-devices

  • (デバイス)を削除: 永久的な失効

  • (ユーザー)を削除: 永久的な失効

利用不可

利用不可

*: ワイプ時に「Wipe device, but keep enrollment state and associated user account」が 無効にできますであることを確認してください。失効は即時に反映されるのは AppConfig:IntuneValidation:RevokeCertificatesOnWipe が true に設定されている場合のみです(デフォルト)。

手動による失効

circle-exclamation
circle-info

この機能にはバージョンが必要です 2.3 以上。

circle-check

背景

手動失効は、SCEPman によって発行されたすべての証明書で利用可能です — 証明書が MDM によって自動登録されたか、Certificate Master により手動で発行されたか、Enrollment REST API を通じて配布されたかに関係ありません。自動失効が利用できない場合や、自動失効の経路だけでは特定の要件を満たせない場合に、手動失効は有用です。

手動失効を容易にするために、SCEPman は発行する証明書の特定のメタデータを保存する必要があります。これは Certificate Master UI および Enrollment REST API 経由で発行された証明書ではデフォルトで行われますが、他の証明書タイプでは行われない場合があります。したがって、要件に応じて 関連する設定 を確認するようにしてください。

Certificate Master とその検索およびフィルタリングオプションを活用して、手動失効がどのように扱われるかを読み進めて学んでください。

Certificate Master(証明書マスター)

SCEPman Certificate Master により、SCEPman PKI が発行した証明書を検索、検査、管理することができます:

証明書を管理chevron-right

自動失効と手動失効の比較

SCEPman は、OCSP リクエストが到着した際に証明書が有効かどうかを判断するために、さまざまな失効情報のソースを使用します。さらに、SCEPman の失効ロジックは または(OR)方式に従っており、これはいずれかの失効ソースが証明書を無効と判断した場合、それが失効として報告されることを意味します。自動失効が手動失効より優先される、といった優先順位はありません。

Certificate Master のテーブルには手動失効のステータスのみが表示され、他のソースは表示されないことに注意してください。したがって、たとえば対応するデバイスが Intune で削除された(自動失効)ために実際には失効と見なされている場合でも、テーブル上では証明書が有効と表示されることがあります。

さらなる参考資料

  • 上記のいくつかのシナリオで(自動)失効をテストし、証明書の有効性をトラブルシューティングする方法に関する情報は、次で見つけることができます こちら.

  • Azure および M365 のデバイスディレクトリに関する一般情報は次で見つけることができます こちら.

最終更新

役に立ちましたか?