Common Problems
Last updated
Last updated
If the error is '503 Cannot download ZIP', then the web app cannot download the ZIP with the application binaries from the URL configured in the app setting WEBSITE_RUN_FROM_PACKAGE (see Application Configuration).
The URL https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip that we had recommended for GitHub deployments in earlier versions of this documentation redirects to another URL. Microsoft changed the behavior of some of their Web Apps and now some versions do not support redirects together with WEBSITE_RUN_FROM_PACKAGE. Hence, you need to change the URL to https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip.
Check if the Azure resource is up and running.
In the App Service resource of SCEPman or Certificate Master, you can check which Stack and version is configured for that App Service under Settings -> Configuration -> General settings -> Stack settings. While the Stack is .NET, the .NET version might not match what you expect for your version of SCEPman, e.g. .NET 8 for SCEPman 2.8.
This is because some common .NET versions are automatically available on all Windows App Services, independently of which .NET version you select in the settings. We only lift SCEPman to a new .NET version when this version is included in this set of automatically installed .NET versions. We do this because our update mechanism via WEBSITE_RUN_FROM_PACKAGE does not give us any control over the .NET version setting. Hence, it actually does not matter what is configured as .NET version.
As a side note, Linux App Services do not include any automatically installed .NET stacks. If you wanted to run SCEPman on a Linux App Service, you would have to configure the correct .NET version. However, the next SCEPman update could break your installation if it used a newer .NET version. This is why we do not support SCEPman on Linux App Services.
We are shutting down the deprecated SCEPman artifacts repository https://github.com/glueckkanja/gk-scepman after over three years of moving artifacts to the new location https://github.com/scepman/install. On Wednesday, 2024-11-27, we temporarily disabled the old location to make users aware of the permanent shutdown on Monday, 2024-12-16.
If you are affected, check your WEBSITE_RUN_FROM_PACKAGE setting and update the value to the new package location. This will also update your SCEPman version from 1.8 to the latest version, granting many improvements with full backwards compatibility.
If you are unsure whether you are using the latest repository, visit your SCEPman's splash page. If it is still configured at the old repository, it is displaying a warning (and has done that for the last three years already) that looks like this:
The SCEP profile will result in an error if the certificate deployment was not successful. Errors can have several reasons:
This could happen when a wrong trusted root certificate was selected in the SCEP certificate profile. This is also shown in the event log:
Open the Windows Events application
Click Applications and Services Logs
Next, click Microsoft
Then, click Windows
Scroll down and search for DeviceManagement-Enterprise-Diagnostics-Provider and click it.
In the window which will appear, click Admin
Scroll through the list and search for event ID 32
It contains a short error report
SCEP: Certificate enrollment failed. Result (The hash value is not correct.).
If you are using an Intermediate CA, note that you have to select the Intermediate CA certificate and not the Root CA certificate in the SCEP configuration profile! Note that this is specific to the Windows platform and for example Android requires selecting the Root CA certificate in the SCEP configuration profile.
This is just a problem before version 1.2
If the device certificate has a localhost URL for the OCSP entry in the certificate like this:
The App Service is missing an important application setting with the name AppConfig:BaseUrl set to the azurewebsite URL. To fix this, add the variable and save the App Service config:
Delete this certificate from the device and do the MDM sync. If you did it you will see a proper URL for the OCSP entry:
The SCEP configuration profile depends on the Trusted Root certificate profile. Assign both profiles to the same Azure Active Directory user or device group to make sure the user or device overlaps and both profiles are targeted to the device. Do not mix user and device groups. If you see pending as status for the configurations profiles in Intune for a long time, the assignment is probably wrong.
You can check both from the SCEPman side and the client side. Depending on the problem, which you often do not know beforehand, the root cause is shown on only of the two sides.
Check whether there is any [ERROR] entry in the SCEPman logs. Possibly also search for the search term [WARN, but this may yield some false positives.
Oliver Kieselbach and Christoph Hannebauer wrote a blog article about analysis of certificate request or renewal problems that helps you to track down enrollment problems on the client side.
Currently, some Windows 10 devices do not have the correct time during the OOBE experience. This is not easy to see, since the screen shows no clock. This causes a problem with newly issued certificates, as they are not yet valid. Windows then discards these "invalid" certificates and shows an error. Certificates are issued 10 minutes in the past by default to address smaller clock issues, but we have recently seen Windows 10 devices that are up to 9 hours behind time.
You may proceed with the enrollment and once this is finished, the device will get a certificate successfully, as the clock is correct then. You may also use the new option AppConfig:ValidityClockSkewMinutes to date back certificates for more than 10 minutes. Use 1440 minutes to date back the certificates for a whole day. This will be the default for new SCEPman installations to address this issue.
This is because SCEPman dates back certificate by one day to counter issues with devices whose clock is late, see Windows 10 devices cannot enroll with AutoPilot.
First, you need to check the validity of the device certificate. Therefore, open a command prompt as administrator and type the following command:
Look at the certificate with the device ID issued by the SCEPman-Device-Root-CA-V1 and verify if the certificate is valid (see last line).
To verify that the OCSP responder is working, you can look at the OCSP url cache with the following command:
To check the validity of a certificate on a macOS machine using OCSP, please follow these steps:
Export the SCEPman Root CA certificate from Keychain Access (System Keychains > System Roots) as *.cer file and place it in a folder (alternatively, you can download it from your SCEPman instance's website).
Export the client authentication certificate you want to verify from Keychain Access (System Keychains > System > My Certificates) as *.cer file into the same folder.
Extract the OCSP responder URL from the client authentication certificate's Authority Information Access (AIA) property:
Open a Terminal session and cd to the folder that contains the exported certifcates.
Execute the following command:
Towards the end of the response, the revocation status is displayed:\
As an alternate you can export the device certificate and use certutil on a Windows machine to display a small certutil UI for the OSCP check:
If you want to revoke a user certificate, you have two options:
Deleting the user from Microsoft Entra ID (Azure AD) or
Block sign-in for the user
Microsoft Entra ID (Azure AD): Delete or disable the device (Microsoft Entra ID (Azure AD) Portal: "Devices" - "All devices").
Both directories: Execute actions for Microsoft Entra ID (Azure AD) and Intune as described.
For more details on device directories, please read the article Device Directories.
The following example revokes a device certificate via Microsoft Entra ID (Azure AD):
Navigate to Devices - All devices in your Microsoft Entra ID (Azure AD)
Choose a device
Click Disable
Next, type in the following command again:
As you can see in the last line, the Certificate is REVOKED
When you enable the device in Microsoft Entra ID (Azure AD) again and you type in the command from above again, the certificate should be marked as valid.
It can take up to 5 minutes before the prompt 'Marked as valid' appears.
Symptoms: Cisco ISE shows an OCSP unreachable error. Aruba ClearPass also has this problem. The server, seemingly SCEPman, answers with an TCP reset packet to the OCSP request.
Cause: Both Cisco ISE as well as Aruba ClearPass do not support HTTP 1.1 when looking up OCSP and do not send a host header in their OCSP request. Therefore, they cannot connect to a general SCEPman instance running on Azure App Services. The error message may look like this:
Solution: Please see here.
On Android (dedicated) systems, Intune or Android accidentally puts the Intune Device ID into the certificate instead of the AAD Device ID in random cases, although you configure the variable in the SCEP configuration profile. SCEPman then cannot find a device with this ID in AAD and therefore considers the certificate revoked.
This happens only when you use the Microsoft Entra ID (Azure AD) shared mode for enrollment method for corporate-owned dedicated devices instead of the default mode. If you use the default mode for Token types Corporate-owned dedicated device, you will not be affected by the problem. Intune will still put the Intune Device ID into the certificate instead of the AAD Device ID, but they will be the same for the default mode, so it does not matter. To change the enrollment mode, go to the Android enrollment settings of Microsoft Endpoint Manager admin center and choose Corporate-owned dedicated device (default) instead of Corporate-owned dedicated device with Azure AD shared mode. Please refer to the Microsoft documentation for the implications of this selection.
We are currently working with Microsoft to solve this issue in all configurations. Please contact our support if you are also affected.
If your SCEPman homepage shows a red tag "Not Connected" for Storage Account connectivity, possibly the Managed Identity of the SCEPman App Service (and possibly that of SCEPman Certificate Master) is missing permissions on the Storage Account. In this case, SCEPman cannot check whether a certificate is manually revoked and therefore cannot respond to OCSP requests. This usually happens if you move the Storage Account to another subscription or resource group. It may also occur after upgrading a Community Edition version to Enterprise Edition -- in this case, the permission problem existed before, but the Community Edition did not check for it.
To fix this, you need to grant the Managed Identity of the SCEPman App Service and that of SCEPman Certificate Master the role "Storage Table Data Contributor" on the Storage Account. The role assignments can be done manually in the Azure Portal under "Access Control (IAM)" in the Storage Account. Alternatively, just execute the SCEPman Installation CMDlet from the SCEPman PowerShell module once again.
Check your SCEPman Environment Variables to see what is configured for AppConfig:UseRequestedKeyUsages. If it is not set, it defaults to "false".
New installations will automatically set this to "true", however older SCEPman installations have this set as false. SCEPman updates don't change any behavior except for fixes or changes that have under no circumstances a disadvantage. When this is set to false, the requests EKUs and Key Usages are ignored.
If you want to revoke a device certificate, you have multiple options depending on :
Intune: Delete the device or trigger a remote action (several managements states like "WipePending" automatically revoke certificates as stated under ).
