Resolved - Known Issue with SCEP profiles for Android Enterprise fully managed devices in Intune

[Intune_Support_Team]

Update: This fix for this issue has now been rolled out. 

We’ve seen an issue in the “Common name” value of SCEP certificate profiles for Android Enterprise fully managed devices in Intune.

These profiles can potentially fail to deploy because of how the Common Name value is interpreted in the Intune backend. Even if your certificates are deploying to devices, they may be using a different value for Common Name than SCEP profiles you’ve deployed for other platforms. 

We’ll update this post when the fix for this issue is rolled out so you can make changes to impacted profiles. After that fix is in, you will have to take action to ensure that your SCEP profiles work as expected.

For existing SCEP profiles, we recommend that you delete the existing profile and create a new one with the same configuration after the fix has been rolled out.  This will ensure that the certificates you issued are issuing certificate subject names consistent with our SCEP profiles you may have for other platforms.  Once you create and deploy the updated SCEP profile, all devices targeted by the policy will receive a new certificate with the correct Common Name and the old certificate will be removed.

If you do not take action to delete an impacted profile, the profile will get the correct Common Name value when the SCEP certificate is next renewed.

More information about SCEP certificate profiles is available in the Create and assign SCEP certificate profiles in Intune doc. 

11/25/19: Updated with status of fix

[Jeroen Dijkman]

Good to see this issue is acknowledged. We actually have it and were working with MS support for months to figure it out. In the end because of 3 lines out of the Intune Device logs send to us by support we figured it out. Intune was actually taking the Display Name and using that as Common Name in the certificate request.

This can fail early in the process if the Display Name has special characters in it. Or it succeeds and provides the certificate with a Common Name value that is wrong. (In our case the Display Name) Then when using the certificate for connecting to for example Wifi it will fail the authentication.

Workaround for us was to use the exact same value for the Display Name and Common Name. But this is only feasible for some testing.

@Intune_Support_Team What would have been helpful in finding this issue must quicker is to have access to the Intune Device logs. As a customer I noticed straight away that the common name value used in the certificate request was wrong. But this error message only showed up in the Device logs.

[Adrian Bishop]

Is there any update or time frame on when the fix will be deployed

[Jeroen Dijkman]

@Adrian Bishop  Support has told me that this issue will be fixed in the December update of Intune. 

[Intune_Support_Team]

Hi @Adrian Bishop, @Jeroen Dijkman, thanks for your comments!

We've checked with the team, and the fix has been rolled out. If the issue still persists, please message us with additional details for us to review!

[a_naqui]

Ive deleted my existing SCEP profile and created a new one.  However, the new profile has a status of FAILED to devcies.

Is anyone else experiencing this issue?  The original SCEP profile was deploying user certficates to devices without issue.

[Jeroen Dijkman]

@Intune_Support_Team  I tested the fix and can confirm that for us it is working now. The certificate request is using the correct attribute for the common name.

[Jeroen Dijkman]

@a_naqui  I tested on 2 different devices. I noticed on one device it took about 15 to 20 minutes for the certificate request to be processed. In the meantime the Intune console can give an error message on the device configuration page of the device.

[a_naqui]

@Jeroen Dijkman  - I managed to get it working.  The issue was due to the NDES SSL cert having to be reapplied.  We upgraded our CA to server 2019 and this stopped working.

Certs are now successfully deploying once again.