If you are using Intune and haven’t yet set up a mechanism to deliver certificates to your MDM-managed devices, you should probably do so – at some point you’ll need to, and there’s no time like the present.

If you are already using Active Directory Certificate Services (instructions for setting it up here), the Intune documentation will walk you through the process of integrating that into Intune.  (It also talks about supported third-party PKI certificate authorities, if you are using one.)  Another doc page talking about troubleshooting has a good diagram for what needs to happen:

Here’s my interpretation of that:

1. Intune sends a SCEP certificate device configuration profile to the device.  This isn’t the cert itself, but rather an instruction to the device saying “here what you need to do, and here’s the URL of the service that will help you do it.”
2. The client device talks to the NDES server (where NDES is the service that implements the SCEP protocol), which also runs the Intune NDES connector, to process the certificate request.  Because the client devices could be on the internet, the NDES endpoint needs to be published to the internet.  (The Azure AD Application Proxy makes this incredibly easy, highly recommended.)
3. NDES and the Intune connector chat.  (I prefer to ignore this step as part of a black box, but if it doesn’t work properly you would have to spend time troubleshooting this.)
4. The NDES server sends the “create a certificate” request to the certification authority (Active Directory Certificate Services).
5. ADCS creates the certificate and sends it back to the NDES server.  The NDES server sends it on to the client device.
6. NDES and the Intune Connector let Intune know the result (success, failure) so you can see this in the Intune portal.

A few suggestions based on my experiences setting this up:

• Read through other blogs that walk through the setup.  A good click-by-click example can be found here.
• Don’t miss this statement, unless you’d like to waste a day troubleshooting:  “You can’t use NDES that’s installed on the server that hosts the Enterprise CA.”  
• Use Azure AD Application Proxy to publish the NDES endpoint on the internet.
• The Certificate Services profile that you create is pretty much a “general-purpose” template, since it is configured to “supply in the request” most of the important details.  (And yes, you’ll really need to edit the registry to specify this template name.  Note that the name you put in the registry will never have spaces in it – templates have a display name and a different “name” that needs to be put in the registry.  And you can put the same name in each of the three registry values – maybe at some point you might want them to be different, but so far I haven’t run into that.)
• Don’t miss any of the features and options listed – they are really required.
• Don’t put the NDES connector on a domain controller, as it complicates the IIS_IUSR setup.
• Double-check the HTTP parameters registry values – each time I’ve done that, I’ve needed to do it more than once.
• Make sure you target the root certificate policy and the certificate template to the same groups (user or device, as appropriate).  If you don’t, the certificate enrollment can fail early in the process (typically at step #1 above).
• If you get to a point during your troubleshooting where you need the Service Trace Viewer tool to read the log files, you can get that through the Windows 10 SDK.  (Why that isn’t more obvious is a mystery.)

So what can you do with these certificates?  Typical scenarios include network authentication (e.g. 802.1x) with device or user certs; authenticating with VPN servers using device or user certs; signing e-mail based on user certs; and authenticating to ConfigMgr for client installation and enrollment using a device cert. 

Let’s shift the conversation a little then to Windows Autopilot.  I’m sure you know that Autopilot supports both Hybrid Azure AD Join and Azure AD Join scenarios.  And when you introduce certificates into these scenarios you can see different behaviors from each scenario:

• With Azure AD join, the device gets a name assigned, it joins Azure AD, it enrolls in Intune, and then certificates are enrolled.  Perfect.
• With Hybrid Azure AD join, the device first enrolls in Intune at which point it will typically receive SCEP certificate enrollment policy, and can typically enroll the certificate before the device has even joined AD, which is what establishes the device’s name as well.  That could mean that the name in the certificate that was created could be the original random name (e.g. DESKOP-IE5GH3) instead of the Autopilot-assigned name (e.g. AD-skE7FeA3m1AB).

So let’s look at that Hybrid Azure AD Join scenario in a little more detail.  What really matters here are the values that you specify for the “Subject name format” and “Subject alternative name” list.  (See this doc for more details on those.)  You might be tempted to specify a template like this:

That would work great with an Azure AD-joined device, but results in a certificate with the wrong name for an AD-joined (a.k.a. a Hybrid Azure AD-joined) device.  Making a simple change to specify this instead:

works perfectly, causing the certificate to be issues with the right name.  Why does that work?  If you go back to the six steps listed above, in step #2 the device sends the certificate request to NDES to process.  But when the device sees the {{FullyQualifiedDomainName}} field, it can’t process the request because that property is only valid for AD-joined devices, and the computer isn’t yet joined (still waiting for the ODJ blob to be received, and for the required reboot to happen after that).  The request doesn’t fail, it’s just held by the client until after the ODJ-triggered reboot.  After the reboot, the {{FullyQualifiedDomainName}} can be resolved (e.g. to “AD-skE7FeA3m1AB.contosocm.com”) and the request is then sent to the NDES server.

I’m not 100% sure this is working as designed or just a convenient accident, but it does serve our purposes here pretty well, making sure the certificate is issued with the right name. 

So why does it matter that the certificate has the right name?  Some service will check.  For example, a Wi-fi switch might look up the device in AD given the name in the cert to see if it exists.  Another example:  the ConfigMgr client installation process (ccmsetup.msi/exe) will attempt to find a cert that matches the computer name (and that has a SAN attribute, hence the DNS SAN value above) to use to authenticate with the ConfigMgr server.  If it doesn’t find a cert that matches the computer name, it will give up.  (It could use an Azure AD user or device token as well, but there are some scenarios, e.g. white glove, where neither of these are available.)  See the ConfigMgr docs for more on that.

One gotcha though:  If you are also deploying devices that do Azure AD Join, that {{FullyQualifiedDomainName}} value can never be resolved, so a certificate will never be issued.  That means you may need to use different certificate templates for Azure AD Join devices than for Hybrid Azure AD Join (AD join).  The same would apply if you used an Azure AD-only attribute on an AD-joined device (although some of those will be resolvable after the Hybrid Azure AD device registration process has completed).