In this guide, we will explore multiple options for deployment of Certificates using Intune. Certificates are digital credentials that help establish trust, secure communication, and ensure the identity of users, devices, or servers.
With Intune, you can deploy either a User or Device Certificate to managed users/devices. These certificates can be used for Client Authentication for getting secure access to organization’s Wi-Fi or VPN etc. Other usage scenarios for certificates are Email encryption, Email signing, code signing etc.
Using Certificates for authentication purpose for granting access to services is also known as Certificate based authentication (CBA).
For authentication purpose, a certificate issued to a user or device requires at least Client Authentication usage. Therefore, if you are creating a certificate template which will be used to issue certificates to end users/devices, ensure Application Policies include Client Authentication.
Note
There are three ways to deploy certificates using Intune. In the following sections of this post, we will explore these deployment methods in more detail.
- SCEP (Simple Certificate Enrollment Protocol)
- PKCS (Public Key Cryptography Standards)
- Imported PKCS (PFX Certificate Deployment)
Contents
SCEP (Simple Certificate Enrollment Protocol)
SCEP, originally developed by CISCO and documented on the Internet Engineering Task Force (IETF) website, is a protocol that enables Intune managed devices to request and enroll certificates.
Unlike PKCS, SCEP allows userless devices (e.g., Kiosk type of devices) to enroll for certificates from an on-premises Certificate Authority (CA).
SCEP uses NDES (Network device enrollment service), part of ADCS (Active directory certificate services). It acts as a connecting point between a device requesting for certificate and on-premises Certificate Authority. NDES works with Intune Certificate Connector, it’s a software which needs to be installed on the NDES server.
When you Install Intune Certificate Connector software on the NDES server, It installs a component called NDES Policy module, which is used to validate the enrollment requests forwarded by NDES and notify the validation result back to NDES. If the validation is successful, NDES will digitally sign the enrollment request using Exchange Enrollment Agent (Offline request) certificate and forward the request to CA for issuing a certificate.
Below are the different components required for SCEP Implementation:
| NDES | Certificate Authority | Intune Certificate Connector | Entra Application Proxy | SCEP Certificate Intune Deployment | Trusted Root Certificate |
Mobile devices must be able to connect to the NDES server via the SCEP URL to request a certificate. Since the NDES server typically resides on-premises and mobile devices operate over the internet, direct communication is not possible. Several solutions exist to bridge this gap, such as deploying a Web Application Proxy (WAP) or placing the NDES server in the DMZ. However, the simplest and most recommended approach is to use the Entra Application Proxy.
Entra Application Proxy enables access to on-premises NDES server by publishing SCEP URL and making it accessible from the internet securely. For Entra App proxy setup, an Entra private network connector needs to be downloaded from Entra admin center and installed on a server which has access to the SCEP URL. The most common scenario is to Install it on the NDES server.
Below steps provide the overview of the SCEP communication process between a device requesting a certificate and Certificate Authority (CA) via NDES.
SCEP Certificate Deployment Process
- SCEP Certificate Profile Deployment: SCEP certificate profile is deployed to the MDM device. The profile includes the SCEP URL, trusted root certificate, and other certificate-related attributes. Intune generates a dynamic SCEP challenge password, which is assigned to the device. This challenge includes a password, certificate attributes (e.g., subject name, subject alternate name), and the challenge expiration time.
- Device Validation and Certificate Signing Request (CSR) Creation: The device validates the trusted root certificate included in the SCEP profile to ensure it can trust the NDES server. Once validated, the device generates a CSR and sends it along with the challenge password to the SCEP URL provided in the profile.
- Entra Application Proxy: The device uses the SCEP URL (published via Entra Application Proxy) to communicate with the NDES server. The request is routed to the internal NDES server URL, (HTTP GET request to mscep.dll component of NDES server). This request includes the CSR and challenge password.
- NDES and Intune Certificate Connector: IIS component of the NDES server forwards the CSR and encrypted challenge password to the NDES Policy Module (part of the Intune Certificate Connector). The policy module validates the challenge password and the CSR, then notifies the Certificate Registration Point (CRP) component of the NDES server to update if the validation is passed or failed.
- NDES to CA communication: If validation is passed, the NDES server digitally signs the enrollment request using the Exchange Enrollment Agent (Offline Request) certificate and forwards it to the Certificate Authority (CA). The CA processes the request, issues the certificate, and sends it back to the NDES server.
- Certificate Delivery: The NDES server delivers the issued certificate to the device.
PKCS (Public Key Cryptography Standards)
The PKCS method of deployment is less complex compared to SCEP because it involves fewer components for setup. It can be used for the same purposes as SCEP, such as Wi-Fi or VPN. Unlike SCEP, PKCS does not require an NDES server or an Entra Application Proxy; only Intune Certificate Connector and a Certificate Authority (CA) are required.
The primary difference between PKCS and SCEP lies in where the Certificate’s private key is generated. With PKCS, the private key is created on the same server where Intune Certificate Connector is installed. In contrast, with SCEP, the private key is generated on the MDM device. As a result, when configuring the certificate template for PKCS, you must enable Allow private key to be exported option. For SCEP, this step is not required.
Below are the different components required for PKCS Implementation:
| Certificate Authority | Intune Certificate Connector | PKCS Certificate Intune deployment | Trusted root certificate |
PKCS Certificate Deployment Process
- PKCS Profile Creation: IT administrator creates a PKCS certificate profile on Intune admin center and deploys it to the device.
- Device Certificate Request: Device connects with Intune Service to request for certificate based on the certificate attributes in the PKCS certificate profile.
- Intune to Certificate Connector: Intune forwards the certificate request (including the defined attributes) to the Intune Certificate Connector.
- Certificate Connector to CA: Connector communicates with the designated Certificate Authority (CA) to request the issuance of a certificate according to the specified attributes.
- CA to Certificate Connector: The CA processes the request and issues the certificate. It then sends the issued certificate to the Connector.
- Certificate Connector to Intune: Connector sends the issued certificate to Intune.
- Intune to Device: Intune delivers the issued certificate to the requesting device.
Imported PKCS Certificates
Imported PKCS certificates are commonly used for S/MIME encryption and S/MIME signing with email profiles. An email is encrypted using the public key certificate., corresponding private key, which is deployed on users devices, is used to decrypt and read the contents of the email.
Imported PKCS certificates cannot be renewed, therefore a new certificate with the same intended purpose needs to be imported in Intune and deployed to the MDM device. You can keep the old expired certificates imported on the device to ensure that there are no issues reading old emails which were encrypted using the expired certificate.
PKCS Imported Certificate Deployment Process
- PFX Certificate Import: IT administrator imports a PFX certificate (with its associated password) into the Intune service.
- PKCS Imported Certificate Deployment: IT administrator creates PKCS Imported Certificate deployment on Intune admin center.
- Device Requesting for Certificate: Once Step 2 is completed successfully, Device will request the Imported PKCS certificate from Intune.
- Intune to Certificate Connector: When a device requests the certificate, Intune sends the following information to the Intune Certificate Connector:
- Encrypted password
- PFX certificate.
- The public key of the requesting device.
- Certificate Connector to Intune:
- Connector decrypts the password using the On-premise private key.
- It then re-encrypts the password using the device’s public key.
- Finally, the Connector sends the certificate and the re-encrypted password back to Intune.
- Certificate Delivery: Intune delivers the certificate to the requesting device.
- Certificate Installation: The device uses its private key to decrypt the password and then installs the received certificate.
