Certificate-based Wi-Fi and VPN used to mean an enterprise CA, an NDES server, the Intune Certificate Connector and a reverse proxy, and any one of them could take the whole chain down. Microsoft Cloud PKI replaces that stack with a root and issuing CA hosted by Intune and a cloud SCEP service that answers your devices directly. In this post I'll walk through creating the CAs, the three profiles every platform needs, wiring the certificate into a Wi-Fi profile, and what to check when a certificate doesn't arrive.
How it works#
Cloud PKI gives you a two-tier hierarchy: a root CA as the trust anchor and an issuing CA that signs end-entity certificates. Intune hosts the CRL distribution point and AIA endpoint for each CA, and provides a SCEP registration authority per issuing CA. When a device checks in, it receives the trusted certificate profiles and the SCEP profile, generates a key pair locally, and sends a certificate signing request plus an encrypted challenge to the cloud SCEP service. The validation service checks that the request comes from an enrolled device and matches the profile, asks the issuing CA to sign it, and the certificate is delivered back to the device. The private key never leaves the device, and there's no connector, server or proxy to maintain. If you already run Active Directory Certificate Services, the bring your own CA option anchors an Intune issuing CA to your existing root instead.
Prerequisites#
- Licensing: a subscription in addition to Intune Plan 1 or Plan 2, available in the Microsoft Intune Suite or as a standalone Cloud PKI add-on. Check Tenant administration › Intune add-ons. Cloud PKI is available in GCC High but not in DoD.
- Platforms: Windows, macOS, iOS/iPadOS and Android devices enrolled in Intune and supporting the SCEP certificate profile.
- Roles: the Intune Administrator role can create CAs; custom roles can be granted the Cloud PKI permissions to read CAs, create certificate authorities and revoke issued leaf certificates.
- Capacity: up to three CAs per tenant, counting root, issuing and BYOCA issuing CAs. Licensed CAs use keys in Azure Managed HSM; CAs created during a trial use software-backed keys and stay that way after you buy a licence, so don't build your production root during a trial.
- Relying parties: your RADIUS or VPN servers must trust the root and issuing CA certificates and be able to reach the CRL and AIA URLs.
Step-by-step#
Step 1: Create the root CA#
Go to Tenant administration › Cloud PKI › Create. Give it a name, then under Configuration settings choose CA type: Root CA, a Validity period of 5, 10, 15, 20 or 25 years, and the Extended Key Usages you intend to issue. Choose carefully: the issuing CA can only offer EKUs that exist on its root, the Any Purpose EKU isn't allowed, and none of these properties can be edited later. Fill in the Subject attributes (common name is required; country must be two characters) and pick the Key size and algorithm: RSA 2048 with SHA-256, 3072 with SHA-384 or 4096 with SHA-512. This becomes the upper bound for what SCEP profiles can request.
Step 2: Create the issuing CA#
Create a second CA with CA type: Issuing CA, Root CA source: Intune, and select your root. The validity period (2, 4, 6, 8 or 10 years) can't exceed the root's, and the EKU list is limited to the root's EKUs. Once created, open the CA's Properties: you'll find the CRL distribution point URI, the AIA URI and, for issuing CAs only, the SCEP URI. Select Download on both CAs to get their public certificates; the file names follow the common names you entered.
Note: the CRL is valid for seven days and republished every 3.5 days, and it's refreshed every time you revoke a certificate. Relying parties that enforce revocation need network access to that URL.
Step 3: Deploy the trusted certificate profiles#
For each platform you target, create two Trusted certificate profiles under Devices › Manage devices › Configuration: one with the root CA certificate and one with the issuing CA certificate. Assign both to the same groups that will receive the SCEP profile. A SCEP profile that references a trusted certificate profile the device never received will sit in a pending or error state.
Step 4: Create the SCEP certificate profile#
Copy the SCEP URI from the issuing CA's properties and create a SCEP certificate profile per platform. The settings that matter:
| Setting | Value for Cloud PKI |
|---|---|
| Root Certificate | The trusted certificate profile of the root CA that anchors your issuing CA |
| SCEP Server URLs | Paste the SCEP URI unchanged and keep the {{CloudPKIFQDN}} placeholder; Intune swaps it for a *.manage.microsoft.com host at delivery. Don't mix NDES URLs into the same profile. |
| Subject name format / SAN | Use variables that exist on every targeted user or device object; a missing attribute (for example an email address) means no certificate and an error in the report |
| Extended key usage | Client Authentication for Wi-Fi and VPN; it must be present on the issuing CA |
| Key size and hash | At or below what the issuing CA was created with; 1024-bit and SHA-1 aren't supported |
Step 5: Use the certificate in Wi-Fi and VPN profiles#
In a Windows Wi-Fi profile, set Wi-Fi type: Enterprise, EAP type: EAP-TLS, add your RADIUS server names under Certificate server names, select the trusted root profile under Root certificates for server validation, and set Authentication method: SCEP certificate, choosing the SCEP profile from step 4. VPN profiles follow the same pattern: EAP-TLS with the SCEP profile as the client certificate. Assign the Wi-Fi or VPN profile to the same groups, and import the root and issuing CA certificates on the RADIUS or VPN server so it can build the chain. A user certificate profile should be assigned to users, a device certificate profile to devices, and the trusted certificate profiles must reach whichever object type the SCEP profile targets.
Verify#
In the admin center#
Open the issuing CA under Tenant administration › Cloud PKI: its dashboard counts active, expired and revoked certificates, and View all certificates lists each one. Report data appears within 24 hours of issuance. For a profile-level view, go to Devices › Manage devices › Configuration, select the SCEP profile and open Certificates. Devices › Monitor › Certificates shows issued certificates across profiles.
On a Windows device#
Open certlm.msc for device certificates (or certmgr.msc for user certificates) and check Personal › Certificates for a certificate issued by your issuing CA, with the root under Trusted Root Certification Authorities and the issuing CA under Intermediate Certification Authorities. From PowerShell:
Get-ChildItem Cert:\LocalMachine\My |
Where-Object Issuer -like '*Contoso Issuing CA*' |
Select-Object Subject, NotAfter, Thumbprint, HasPrivateKey
Get-ChildItem Cert:\LocalMachine\Root, Cert:\LocalMachine\CA |
Where-Object Subject -like '*Contoso*' | Select-Object Subject, NotAfterHasPrivateKey should be True. For user certificates, swap LocalMachine for CurrentUser. Then connect to the Wi-Fi network and confirm on the RADIUS server that EAP-TLS authentication used the expected certificate.
Tips & gotchas#
- Revocation: in the issuing CA's certificate list, select a certificate's subject name and choose Revoke. If the device still has an active SCEP assignment, it requests a new certificate at its next check-in, so remove the assignment first when you want the device to stay without one.
- EKU mismatch is the most common SCEP profile error with Cloud PKI: an EKU selected in the profile but absent from the issuing CA results in an error and no certificate. The only fix for a missing EKU is a new CA, which is why the root's EKU list deserves thought up front.
- Empty subject variables show up as errors in the SCEP profile report; check the attribute on the user or device in Microsoft Entra ID.
- Assignments: the trusted certificate profiles and the SCEP profile should land on the same devices or users; mismatched targeting leaves the SCEP profile pending.
- Windows diagnostics: SCEP enrollment errors are logged in Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin; look for events around the time of the sync.
- Network: devices need to reach the Intune endpoints in the
*.manage.microsoft.comnamespace for SCEP, and RADIUS servers need the CRL and AIA URLs if they check revocation. - Audit: create, revoke and search actions on CAs are recorded in the Intune audit log, which helps when a certificate disappears unexpectedly.