Build an Enterprise PKI for Intune: Complete Implementation Lab

The Intune PKI deep dive explains what every component does and why. This post is the other half: you build it. By the end, a real Windows device will have requested a certificate through NDES, stored its private key in the TPM, and used that certificate to connect to Wi-Fi and VPN.

Every stage ends with a checkpoint (a command you can run and the result you should see) and a short if it fails table. Don't move to the next stage until the checkpoint passes. PKI problems compound: a template mistake in Stage 3 shows up as a confusing device error in Stage 7, and finding it from there takes far longer than catching it where it happened.

Lab Environment

You also need an Intune administrator account, a group containing the test device (this lab uses GRP-SEC-WIN-PKILab-PIL, following the naming standards), and a way to publish NDES externally: Microsoft Entra application proxy is the simplest.

Stage 1: Prepare the Windows Servers

What you build: two domain-joined member servers with static IP addresses and working DNS.

Join CEL-CA01 and CEL-NDES01 to the domain, set static IPs, and patch both fully before installing any roles. Then create the NDES service account on the domain controller:

New-ADUser -Name "svc-ndes" -SamAccountName "svc-ndes" `
  -AccountPassword (Read-Host -AsSecureString "Password") `
  -Enabled $true -PasswordNeverExpires $true

Stage 2: Install the Enterprise CA

What you build: a working certification authority, with revocation information published over HTTP.

On CEL-CA01, signed in as an Enterprise Admin:

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
 
Install-AdcsCertificationAuthority -CAType EnterpriseRootCa `
  -CACommonName "Contoso Lab Root CA" `
  -KeyLength 4096 -HashAlgorithmName SHA256 `
  -ValidityPeriod Years -ValidityPeriodUnits 10 -Force

By default the CA only publishes its CRL and certificate to LDAP, which Entra joined devices and many RADIUS services can't read. Add an HTTP location that relying parties can reach (here, pki.contoso.com, served by IIS from the CA's CertEnroll folder):

Add-CACrlDistributionPoint -Uri "http://pki.contoso.com/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl" `
  -AddToCertificateCdp -Force
Add-CAAuthorityInformationAccess -Uri "http://pki.contoso.com/CertEnroll/<ServerDNSName>_<CAName><CertificateName>.crt" `
  -AddToCertificateAia -Force
 
Restart-Service certsvc
certutil -crl

The angle-bracket tokens are literal CA variables, typed exactly as shown; the CA replaces them when it writes each certificate.

Stage 3: Create the Certificate Templates

What you build: a SCEP template for device certificates, plus a web server certificate for NDES itself.

Open certtmpl.msc, right-click the User template and choose Duplicate Template. Configure the copy:

Then publish it on the CA:

Add-CATemplate -Name "IntuneSCEPDevice" -Force

NDES also needs an HTTPS certificate for its own website. Duplicate the Web Server template as NDES Web Server, grant CEL-NDES01's computer account Read and Enroll, publish it, and request a certificate for ndes.contoso.local from CEL-NDES01.

Stage 4: Install and Configure NDES

What you build: a SCEP endpoint that requests certificates from your CA using your template.

On the domain controller, register the service principal name NDES needs for Kerberos, and add the service account to the IIS group on the NDES server:

setspn -s HTTP/ndes.contoso.local contoso\svc-ndes

# On CEL-NDES01
Add-LocalGroupMember -Group "IIS_IUSRS" -Member "contoso\svc-ndes"
 
Install-WindowsFeature ADCS-Device-Enrollment, Web-Filtering, Web-Asp-Net45, `
  NET-WCF-HTTP-Activation45, Web-Metabase, Web-WMI -IncludeManagementTools
 
Install-AdcsNetworkDeviceEnrollmentService `
  -ServiceAccountName "contoso\svc-ndes" `
  -ServiceAccountPassword (Read-Host -AsSecureString "svc-ndes password") `
  -CAConfig "CEL-CA01.contoso.local\Contoso Lab Root CA" -Force

Point NDES at your template. All three registry values must use the template name:

$key = "HKLM:\SOFTWARE\Microsoft\Cryptography\MSCEP"
"SignatureTemplate", "EncryptionTemplate", "GeneralPurposeTemplate" |
  ForEach-Object { Set-ItemProperty -Path $key -Name $_ -Value "IntuneSCEPDevice" }

Intune SCEP requests are long URLs, so raise the request size limits in HTTP.sys and IIS:

$http = "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters"
New-ItemProperty -Path $http -Name MaxFieldLength -Value 65534 -PropertyType DWord -Force
New-ItemProperty -Path $http -Name MaxRequestBytes -Value 65534 -PropertyType DWord -Force
 
& "$env:windir\System32\inetsrv\appcmd.exe" set config `
  -section:system.webServer/security/requestFiltering `
  /requestLimits.maxUrl:65534 /requestLimits.maxQueryString:65534

Bind the NDES web server certificate to HTTPS (port 443) on the Default Web Site in IIS Manager, then restart the server so the HTTP.sys changes take effect. Finally, publish https://ndes.contoso.local through Entra application proxy so devices outside the office can reach it.

Stage 5: Install the Intune Certificate Connector

What you build: the bridge that lets Intune validate every SCEP request before NDES forwards it to the CA.

In the Intune admin center, go to Tenant administration > Connectors and tokens > Certificate connectors > Add, download the installer and run it on CEL-NDES01. In the configuration wizard:

• Select the SCEP feature, and Certificate revocation as well, so retired devices get their certificates revoked.
• Run the connector as SYSTEM, which is fine for a SCEP-only connector.
• Sign in with an Intune administrator account when prompted.

For revocation to work, give the connector's identity (for SYSTEM, the CEL-NDES01 computer account) Issue and Manage Certificates on the CA, under the CA's Properties > Security.

Stage 6: Create the Intune Profiles

What you build: trust in your CA on the device, and a SCEP profile that tells the device exactly what to request.

Export the CA certificate on CEL-CA01:

certutil -ca.cert C:\Lab\ContosoLabRootCA.cer

Trusted certificate profile: Devices > Configuration > Create > Windows 10 and later > Templates > Trusted certificate. Upload ContosoLabRootCA.cer, destination store Computer certificate store - Root, and assign it to GRP-SEC-WIN-PKILab-PIL.

SCEP certificate profile: Devices > Configuration > Create > Windows 10 and later > Templates > SCEP certificate, named WIN-PRD-SCEP-Device:

Assign it to the same group as the trusted certificate profile. This is the single most common reason a SCEP profile fails, and the deep dive explains why.

Stage 7: Enroll the Windows Device

What you build: a real certificate request from a real device.

On CEL-LT-0142, force a sync instead of waiting for the next check-in: Settings > Accounts > Access work or school > your account > Info > Sync. Within a few minutes, the trusted certificate profile applies first, then the SCEP profile.

Stage 8: Verify the Device Certificate

What you build: proof that the certificate is correct, protected, and verifiable by anything that receives it.

Run these on the device, in an elevated PowerShell session:

# 1. The certificate is there, issued by your CA, with Client Authentication
$cert = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.Issuer -like "*Contoso Lab Root CA*" }
$cert | Format-List Subject, NotAfter, EnhancedKeyUsageList
 
# 2. The private key lives in the TPM
certutil -store My $cert.Thumbprint | Select-String "Provider"
 
# 3. The full chain and revocation check pass, fetched over the network
Export-Certificate -Cert $cert -FilePath C:\Temp\device.cer | Out-Null
certutil -verify -urlfetch C:\Temp\device.cer

Stage 9: Use the Certificate for Wi-Fi and VPN

What you build: the reason the whole lab exists, a network connection authenticated by the certificate with no password involved. For how 802.1X, RADIUS and VPN authentication work underneath, see certificate-based authentication end-to-end.

Wi-Fi (EAP-TLS)

On the RADIUS side, configure a network policy that accepts EAP-TLS (in Microsoft NPS: Microsoft: Smart Card or other certificate), and make sure the RADIUS server trusts Contoso Lab Root CA and can reach its HTTP CRL.

In Intune, create a Wi-Fi profile (Devices > Configuration > Create > Windows 10 and later > Templates > Wi-Fi, type Enterprise):

• EAP type: EAP-TLS
• Certificate server names: the name on your RADIUS server's certificate
• Root certificates for server validation: your trusted certificate profile
• Client authentication certificate: WIN-PRD-SCEP-Device

VPN

Create a VPN profile for your gateway (Templates > VPN), set the authentication method to Certificates, and select the same SCEP profile. The VPN gateway must trust Contoso Lab Root CA and reach its CRL, exactly like the RADIUS server.

From Lab to Production

The lab works, but it cuts corners that production must not:

If running all of this yourself looks like more than your team wants to own, compare it against the hosted alternative first: Microsoft Cloud PKI vs AD CS covers exactly that decision.

Summary

You built every link of the chain: a CA with revocation published over HTTP, a template that accepts Intune's subject, NDES mapped to that template, a connector that lets Intune vouch for each request, profiles that tell the device what to ask for, and a TPM-backed device certificate that Wi-Fi and VPN accept without a password.

The checkpoints are worth keeping after the lab. They are the same checks, in the same order, that you will use the first time a production device fails to get its certificate. Start at the top of the chain and work down until one fails. For where this certificate fits in a complete device build, see building a secure Windows endpoint from scratch.