Revocation

SCEPman offers several ways to manage and revoke a certificate. The available options depend on

• whether the certificate was automatically enrolled via an MDM solution or whether it was generated via the Certificate Master UI / Enrollment REST API,

• the MDM system that is used for (automatic) enrollment, and

• the configuration of SCEPman.

Below section provides an overview of the different management options and revocation mechanisms and under which circumstances they are available.

Automatic Revocation

Only available when Microsoft Intune and/or Jamf Pro are used as MDM solution(s) for certificate enrollment. Alternatively, it is available with any 3rd party MDM that is able to sync device and/or user objects with Microsoft Entra ID (Azure AD) (i.e. Static AAD Validation can be used).

Supported on OCSP.

Background

Automatic revocation is always active and enables convenient certificate lifecycle management by linking each certificate to a directory object such as a user or device identity. Through this object binding mechanism, SCEPman can infer the revocation status based on certain lifecycle characteristics of the object is has been linked to. The mapping from the object's lifecycle state to the certificate's revocation state is implemented to match best practices from years of security and endpoint management experience.

The binding between directory object (user or device) and certificate is established by introducing appropriate variables in the SCEP profile for the Subject Name or Subject Alternative Name properties. Upon receiving a Certificate Signing Request (CSR) from an MDM-managed client, SCEPman identifies the bound object and encodes this information into the serial number of the certificate before returning it to the client. It is the serial number that is transmitted to SCEPman's OCSP responder during certificate validation, allowing SCEPman to decode the object information, perform a search of the appropriate directory, and finally make a revocation status decision.

Revocation Behavior

In any of the below scenarios, revocation can be considered to be effective immediately, once the bound object's state has changed. Please note that local caching of OCSP responses on the client may suggest otherwise.

During testing, please consider that deleting/removing a device from the respective directory/MDM solution is an irreversible operation that will require you to re-enroll the device afterwards.

Bound Object	Delete from Directory	Disable in Directory	Optional
Intune Device {{DeviceId}}	Delete, Wipe*, Retire*: permanent revocation	Not available	Intune Device Compliance: reversible revocation Endpoint List: permanent revocation
Entra (Azure AD) Device {{AAD_Device_ID}}	Delete: permanent revocation	Disable: reversible revocation	Entra (Azure AD) Device Compliance: reversible revocation Endpoint List: permanent revocation
Entra (Azure AD) User {{UserPrincipalName}}	Delete: permanent revocation	Disable: reversible revocation	User Risk: reversible revocation Endpoint List: permanent revocation
Jamf Computer CN=$JSSID,OU=computers	Delete: permanent revocation	Not available	Not available
Jamf Device CN=$JSSID,OU=devices	Delete: permanent revocation	Not available	Not available
Jamf User on Computer CN=$JSSID,OU=users-on-computers	Delete (Computer): permanent revocation Delete (User): permanent revocation	Not available	Not available
Jamf User on Device CN=$JSSID,OU=users-on-devices	Delete (Device): permanent revocation Delete (User): permanent revocation	Not available	Not available

*: Ensure during wipe, that "Wipe device, but keep enrollment state and associated user account" is disabled. Revocation is only immediate if AppConfig:IntuneValidation:RevokeCertificatesOnWipe is set to true (default).

Manual Revocation

SCEPman Enterprise Edition only

This feature requires version 2.3 or above.

Supported on OCSP and CRL.

Background

Manual revocation is available for any certificate issued by SCEPman - regardless of whether it was automatically enrolled via MDM, manually issued via the Certificate Master, or deployed via the Enrollment REST API. Manual revocation is useful when automatic revocation is not available or when automatic revocation paths are not sufficient to meet specific requirements.

To facilitate manual revocation, SCEPman needs to store certain metadata of the certificates it issues. While this is the case by default for certificates issued via the Certificate Master UI and the Enrollment REST API, it is not the case for other certificate types. Therefore, please ensure to review the relevant settings depending on your requirements.

Keep reading to learn how manual revocation is handled leveraging Certificate Master and its search and filtering options.

Certificate Master

SCEPman Certificate Master lets you search, inspect, and manage the certificates that your SCEPman PKI has issued:

Manage Certificates

Automatic versus Manual Revocation

SCEPman uses different sources of revocation information to determine whether a certificate is valid when an OCSP request arrives. Furthermore, SCEPman's revocation logic follows an or-ed approach, which means if any revocation source deems the certificate to be invalid, it will be reported as revoked. There is no precedence from automatic over manual revocation or vice versa.

Please note, that the tables in Certificate Master only show the status of manual revocation and not other sources. Therefore, a certificate may be shown as valid in the table, although it is actually considered revoked, for example because the corresponding device was deleted in Intune (automatic revocation).

Further Reading

• Information on how to test (automatic) revocation and troubleshoot certificate validity in some of the above scenarios can be found here.
• General Information on Azure and M365 device directories can be found here.