In this guide I will have a look at an easy way to deploy device certificates to modern cloud managed clients. Even without an Microsoft on-premises PKI your devices will get device certificates. These certificates can be used for Wi-Fi authentication for example.
Normally if you want to deploy certificates to mobile devices you are looking at the Simple Certificate Enrollment Protocol (SCEP). To configure this you need to follow this guide Configure and use SCEP certificates with Intune which is fairly long and even takes about 30 min. to read. It involves various on-premises components like AD, CA, NDES Server, Microsoft Intune Certificate Connector and an Azure AD Application Proxy or WAP. A typical setup would look like this:
You might have most of the components in your infrastructure but often I see customers without all of these or they want to get rid of the technical PKI which is used for just a few workloads like 802.1x certificates and move on to a cloud infrastructure.
How do we achieve device certificate deployment the easy way?
A little background from the product description:
Microsoft Intune allows third-party certificate authorities (CA) to issue and validate certificates using the Simple Certificate Enrollment Protocol (SCEP). SCEPman is a fully unattended Certificate Authority using Azure Key Vault for Microsoft Intune based device certificate deployment. SCEPman is a .net core C# based Azure Web App providing the SCEP and Intune API. It uses an Azure Key Vault based Root CA and certificate signing. No other component is involved, neither a database nor any other stateful storage except the Azure Key Vault. That said, SCEPman will not need any backup procedures.
SCEPman is an Azure Web App with the following features:
- A SCEP interface that is compatible with the Intune SCEP open-source API in particular
- SCEPman signs machine authentication certificates with a CA key stored in Azure Key Vault
- SCEPman contains an OCSP responder to provide certificate validity in real-time. A certificate is valid if its corresponding AAD device exists and is enabled
A simple post request to SCEPman service creates the CA certificate.
However, if for whatever reason an alternative CA key material shall be used it is possible to replace this CA key and certificate with your own in Azure Key Vault. For example, if you want to use a Sub CA certificate signed by an existing internal Root CA.
SCEPman issues machine authentication certificates that are compatible with Intune’s internally used authentication certificates. They contain Intune’s extensions determining the tenant and the machine. Additionally, the tenant ID and machine ID is stored in the certificate subject to allow common Radius servers like Cisco ISE, FreeRADIUS, RADIUS-as-a-Service and others to use these certificates for authentication.
How does the exact workflow look like?
As we already know it is a cloud service and uses an Azure Web App. Let’s look at the detailed certificate request workflow:
- In Intune you create and assign a new SCEP certificate profile and target it to a user or device group.
- The device (Windows, iOS, Android, macOS) checks in and requests a certificate from SCEPman (the Azure Web App)
- SCEPman requests validation of the request from Intune by comparing a unique challenge (this prevents tampering)
- Intune validates the CSR and sends back a response
- If the challenge is verified successfully, SCEPman will request certificate signing from the Azure Key Vault
- SCEPman will receive the signed certificate
- SCEPman will issue the certificate to the device
A more detailed technical certificate workflow can be found here Add partner certification authority in Intune using SCEP
SCEPman will act as an OCSP responder and the detailed workflow looks like this:
- The device sends an OCSP request for the certificate to SCEPman
- SCEPman checks if the device exists in Azure AD and is enabled
- SCEPman receives the results and if the AAD device is not available or disabled the OCSP response for the certificate is send as “not valid”
- For existing and enabled AAD devices SCEPman will verify the certificate with the Azure Key Vault
- On successful verification it will send an OCSP response as “valid”, otherwise as “not valid”
How to deploy SCEPman now?
Step 1: Azure AD App registration
First, we need some preparations upfront to allow SCEPman to talk to the Azure AD. This is achieved by registering an App for SCEPman in Azure AD.
- Login to your Azure Portal with an Admin Account
- Navigate to Azure Active Directory
- Choose App registrations
- Click New registration
- Set display name to SCEPman
- Set supported account types to Accounts in this organizational directory only
- Click Register
Next we need to copy and save the created Application (client) ID for the newly registered app SCEPman somewhere (e.g. notepad):
Now we need to create a client secret
- Select the Certificates & secrets blade
- Add a new client secret with New client secret
- Define a Description and set expiration to Never
- Save the generated secret somewhere because you are not able to look it up again
The registered Azure AD app SCEPman now needs to have API permissions which we will grant now:
- Select the API permissions blade
- Click Add a permission to grant required permissions
- Select Intune
- Choose Application permissions as the permission type
- Click scep_challenge_provider and confirm with Add permission
- Click Add a permission once again
- Now select Microsoft Graph
- Choose Application permissions as the permission type
- Expand Directory and check Directory.Read.All and confirm with Add permission
Finally Click Grant admin consent for <your tenant name> and confirm the displayed dialog with Yes
The Azure AD app registration is finished now.
Step 2: SCEPman Deployment – Azure Marketplace
As already said SCEPman is an Azure Marketplace solution and can be easily deployed from there. Just search for SCEP and use the link for SCEPman:
Click on the Create button
Follow the Wizard and fill in the required fields for section Basics:
Fill in the Azure AD app registration details for SCEPman (copied earlier):
Wait for validation passed and click OK
Click on Create and wait for the deployment
Check if SCEPman is running by navigating to Azure AD > App services > scepman-<a-random-string> and click on Browse to see the SCEPman website:
If everything went well you should see the Vault, Intune and Graph as connected. As this is our first and single node in this deployment we can click on “click here to start” to create the Azure Key Vault RootCA certificate (this takes one or two minutes):
Remember this can also be changed to a custom RootCA certificate (not described in this guide). If there is no need, you can create the new RootCA certificate now (SCEPman-Device-Root-CA-V1). If you plan to use the certificates for Wi-Fi authentication, your RADIUS must trust the public root certificate. The public root certificate can be easily downloaded from the SCEPman website by clicking on Get CACert:
To ensure proper OCSP functionality, we need to specify an Application setting with the name AppConfig:BaseUrl set to the azurewebsite URL:
To get continuous updates for SCEPman you can point a configuration variable to the maintained GitHub repository of SCEPman. During every restart the Azure Web App will do a check and a copy deployment if necessary. To configure this, go to SCEPman in Azure AD > App services > scepman-<a-random-string> and click on Configuration:
Look for WEBSITE_RUN_FROM_PACKAGE and replace the URL with the SCEPman GitHub URL:
Step 3: Deploying device certificates via Intune Certificate profile
First, we need to trust the public root certificate from SCEPman. Therefore, we download the CA certificate (shown above) and deploy it via a trusted certificate profile in Microsoft Intune:
When finished we can deploy this to our devices.
Second, we need to create a SCEP certificate profile to deploy the device certificates. To fill the properties of the SCEP certificate profile we need the SCEP Server URL. The base SCEP Server URL can be found on the Overview of the App Service of SCEPman:
To complete the URL, append /certsrv/mscep/mscep.dll (compare SCEP certificate profile picture above). The final URL should look similar like this (xxx is a random string), copy this URL to a notepad for example:
Now we create a SCEP certificate profile in Intune to finally deploy the device certificates:
You should have two configuration profiles now:
Verify device certificate deployment on a mobile client
Once we configured Windows configuration profiles, we verify successful deployment on an Azure AD joined Windows 10 device. Of course, you can create iOS, macOS, and Android profiles as well. All platforms are supported by the SCEP Server – SCEPman. Let’s verify if a client received successfully the trusted root certificate and the device certificate:
As you can see the device certificate is issued to a GUID and this GUID is the device ID of the Azure AD device object. Same principle and properties like Microsoft is deploying the MS-Organization-Access certificate to the device:
Additionally to show the iOS compatibility I created and deployed two policies for iOS (trusted root and SCEP profile). Here is a screenshot of a successful deployment via SCEPman on an iOS device:
What about revocation of a device certificate?
First, we need to check the validity of the device certificate. Therefore, open a command prompt as Administrator and type the following command:
certutil -verifyStore MY
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, we can look at the OCSP url cache with the following command:
certutil -urlcache OCSP
Now if we want to revoke a device certificate, we have two options: deleting the device from Azure AD or just disabling it. I’m disabling it and verify again to see if the certificate will be revoked:
Now type again the following command:
certutil -verifyStore MY
If we enable the device in Azure AD again the device certificate should be marked as valid again. This can take up to 5 min.
My trusted root certificate is deployed but my device certificate via SCEP profile results in an error?
The SCEP profile will result in an error if the certificate deployment wasn’t successful. This can have several reasons:
- SCEP certificate profile is configured with an error. For example, a wrong trusted root certificate was selected in the SCEP certificate profile. This is also shown in the event log under Events > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin, EventID 32, SCEP: Certificate enroll failed. Result: (hash value is not correct.).
- SCEPman Azure Web App is not running. Check if the Azure resource is up and running.
- SCEPman has a configuration or internal problem. Check Azure Web App log files via Advanced Tools > Kudu > Debug Console > CMD > navigate to LogFiles > Application > click on the download icon on the latest .txt file and review it
My certificate does not have the correct OCSP URL entry?
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 the certificate from the device and hit the MDM sync. You should see now a proper URL for the OCSP entry:
I hope this will lower the burden to move components to the cloud as you are now able to get device certificates easily without complex on-premises PKI infrastructure. Go and start evaluating this great solution which completes the cloud story when using a cloud-only modern management approach.
Regarding licensing of SCEPman I do not have final information. But this should not block you from starting of evaluating this solution. As soon as I get more information on this, I will update the article accordingly.