The easy way to deploy device certificates with Intune

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?

There is a solution called SCEPman | Intune SCEP-as-a-Service build by Glück & Kanja Consulting AG available in the Azure Marketplace. All it needs is an active Azure Subscription.

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. (UPDATE: with SCEPman 1.3 user certificates are supported in a limited fashion) 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 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.

! Please read carefully – Warning about user certificates
SCEPman is intended to use for authentication and transport encryption certificates. That said, you can deploy user and device certificates used for network authentication, WiFi, VPN, RADIUS and similar services. Do not use SCEPman for email-encyrption or digital signatures (without a separate technology for key management). The nature of the SCEP protocol does not include a mechanism to backup or archive private key material. If you would use SCEP for email-encryption or digital signatures you may loose the keys to decrypt or verify at a later time.

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:

1. In Intune you create and assign a new SCEP certificate profile and target it to a user or device group.
2. The device (Windows, iOS, Android, macOS) checks in and requests a certificate from SCEPman (the Azure Web App)
3. SCEPman requests validation of the request from Intune by comparing a unique challenge (this prevents tampering)
4. Intune validates the CSR and sends back a response
5. If the challenge is verified successfully, SCEPman will request certificate signing from the Azure Key Vault
6. SCEPman will receive the signed certificate
7. 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:

1. The device sends an OCSP request for the certificate to SCEPman
2. SCEPman checks if the device exists in Azure AD and is enabled
3. 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”
4. For existing and enabled AAD devices SCEPman will verify the certificate with the Azure Key Vault
5. The result is send back to SCEPman
6. On successful verification it will send an OCSP response as “valid”, otherwise as “not valid”

How to deploy SCEPman now?

16.06.2021 Attention(!) there might be an issue with the App registration due to an introduced change to some tenants. In case your SCEPman instance does not deliver certificates since a few days. Have a look at this support article:

https://glueckkanja.zendesk.com/hc/en-us/articles/4402360224530-SCEPman-does-not-issue-certificates

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.

1. Login to your Azure Portal with an Admin Account
2. Navigate to Azure Active Directory
3. Choose App registrations
4. Click New registration
5. Set display name to SCEPman
6. Set supported account types to Accounts in this organizational directory only
7. 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

1. Select the Certificates & secrets blade
2. Add a new client secret with New client secret
3. Define a Description and set expiration to Never 24 months (configuring never is not possible anymore, so create immediately a recurring calendar entry to refresh the secret after ~1,5 year)
4. 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:

1. Select the API permissions blade
2. Click Add a permission to grant required permissions
3. Select Intune
4. Choose Application permissions as the permission type
5. Click scep_challenge_provider and confirm with Add permission

1. Click Add a permission once again
2. Now select Microsoft Graph
3. Choose Application permissions as the permission type
4. Expand Directory and check Directory.Read.All and confirm with Add permission

And really important as some tenants have already issues and on January 2022 you will need to have the additional API permission Application.Read.All for Azure Active Directory Graph. Please read carefully, not Microsoft Graph the API needed API permission is for the old graph API called Azure Active Directory Graph. This is how it must look like in the end:

1. Click Add a permission once again
2. Now select Azure Active Directory Graph
3. Choose Application permissions as the permission type
4. Expand Directory and check Application.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 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:

https://raw.githubusercontent.com/glueckkanja/gk-scepman/master/dist/Artifacts.zip

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:

https://scepman-xxx.azurewebsites.net/certsrv/mscep/mscep.dll

Now we create a SCEP certificate profile in Intune to finally deploy the device certificates:

You should have two configuration profiles now:

Assign them to the same AAD user or device group to make sure the user or device overlaps and both profiles are targeted to the device. Don’t 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!

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:

If you want to deploy Android Enterprise Work Profile and SCEP profiles for certificate usage with Wi-Fi, you should use the SAN attributes UPN in the SCEP profile otherwise Android will not find successfully the certificate for Wi-Fi usage. It is important to use the domain part of your logon user of the Company Portal:

Tip: To check if the certificate is successful deployed and available in the Android Enterprise Work profile you have to download the “My Certificates” app from the Google Play store within the work profile, otherwise you will not see the certificate.

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.

An alternative method is to export the device certificate and use certutil to display a small certutil UI for the OSCP check:

certutil -url <path-to-exported-device-certificate>

Troubleshooting

Following a few steps for troubleshooting I used during evaluation. I really recommend to have a look at the official SCEPman Docs as well, as everything about SCEPman is documented there (design, architecture and so on) and also a good troubleshooting section. See SCEPman Docs

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

• Additional way of logging, configure the App Services Logs and check the Log Stream of the App Service. This might be a good way to troubleshoot 500 errors:

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:

AppConfig:BaseUrl
https://scepman-XXXXX.azurewebsites.net

Delete the certificate from the device and hit the MDM sync. You should see now a proper URL for the OCSP entry:

My SCEP configuration profile shows pending and is not applied?

The SCEP configuration profile depends on the Trusted Root certificate profile. Assign both profiles to the same AAD user or device group to make sure the user or device overlaps and both profiles are targeted to the device. Don’t 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!

My SCEP profile settings are not recognized in the deployed certificates?

This is because some settings are mandatory set by SCEPman, the yellow rectangle is automatically set by SCEPman (for better visibility I recommend to set the settings in the yellow rectangle to the SCEPman mandatory settings like shown below). Hereby is the Key usage set to “Digital signature” and “Key encipherment”. The validity period is set to fixed 6 month currently. The red rectangle are settings which are free to modify. Long term all settings will be supported for configuration. There is a dependency on the {{AAD_Device_ID}} in the subject name, which is used as a seed for the certificate serial number generation. Therefore the subject name must include {{AAD_Device_ID}} for device certificates and for user certificates “common name including email”. Keep an eye on the subject name format in regards to the allowed characters, have a look here Create and assign SCEP certificate profiles in Intune for more details.

SCEPman editions

SCEPman is available in two different editions. If you consider a large scale enterprise deployment with professional support and maybe load balanced service you should consider to use the paid SCEPman Enterprise Edition.

If you are a geek or technical pro and you are going to self support the installation there is the free SCEPman Community Edition (CE). The free SCEPman CE is not backed by professional support services. The only technical difference is that SCEPman CE does not support redundancy through Azure Traffic Manager (no support for Azure WebApp custom domains).

Final thoughts

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.

If you want to learn more of the SCEP request and renewal process see here:

Deep dive of SCEP certificate request/renewal on Intune-managed Windows clients