Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Intune - Enrollment Options for End-Entity Certificates
Published Jun 29 2021 01:40 PM 22.7K Views
Microsoft

Working as a PKI engineer, I am frequently asked about "the best" method to enroll certificates to mobile devices via Intune. What exactly is the best method from a PKI engineer's perspective? The most secure one, of course. The following article tries to explain the different methods in terms of security.

 

Overview

Intune supports three different methods to provision certificates to devices or users, that can be easily confused: Simple Certificate Enrollment Protocol (SCEP), Public Key Cryptography Standards (PKCS), and imported PKCS#12 certificates.

 

While SCEP and PKCS provision each device with a unique certificate, with Imported PKCS#12 certificates you can deploy the same certificate (and private key) that you’ve exported from a source, like Certification Authority database, to multiple recipients. This shared certificate might be useful in scenarios when you need to decrypt data on different devices using exactly the same key pair, e.g. with S/MIME e-mail encryption.

 

The following article tries to explain the differences – mainly, but not only - from the security perspective. As understanding a technology’s security impact without understanding the technology itself is impossible, we start each section with a brief overview of the certificate enrollment process.

 

Foreword: Tiered Administration & your PKI

Microsoft’s AD Tier model has enhanced to the “Enterprise Privileged Access Model ”. What remains the same is the fact that a PKI which is fully trustworthy for Active Directory, must be assigned to Tier 0 and secured and treated accordingly. This is not only true for computers hosting Certification Authorities, but also for computers acting as Registration Authorities (like NDES) or computers which have enroll permissions for user certificates allowing for custom subjects (like Microsoft Intune Certificate Connector”).

 

SCEP (Simple Certificate Enrollment Protocol)

The headline already says that this is about a specific protocol: Simple Certificate Enrollment Protocol. Network Device Enrollment Server (NDES) - a Windows Server Role Service - implements this protocol, thereby providing certificate enrollment services for devices (and users). To interconnect Intune with the on-prem NDES, you need to download and install the following piece of software: Microsoft Intune Connector (aka “Microsoft Intune Certificate Connector” aka “NDES Certificate Connector” or simply “NDESConnectorSetup.exe”). Please be aware that installing Intune NDES Connector significantly changes the default behavior of NDES.

 

Certificate Enrollment Process

Prerequisite: To use a SCEP certificate profile, devices must trust your Root Certification Authority (CA). Create a Intune Trusted Certificate profile in Intune to provision the Trusted Root CA certificate to users and devices.

 

The following steps provide an overview of certificate enrollment using SCEP in Intune:

 

DagmarHeidecker_0-1624994515349.png

Source: Troubleshoot use of Simple Certificate Enrollment Protocol (SCEP) certificate profiles to provision ...

 

  1. Deploy a SCEP certificate profile. Intune generates a challenge string, which includes the specific user (subject), certificate purpose, and certificate type.
  2. Device to NDES server communication. The device uses the URI for NDES from the profile to contact the NDES server so it can present a challenge. We recommend publishing the NDES service through a reverse proxy, such as the Azure AD application proxy, Web Access Proxy, or a third-party proxy.
  3. NDES to policy module communication. NDES forwards the challenge to the Intune Certificate Connector policy module on the server, which validates the request.
  4. NDES to Certification Authority. NDES passes valid requests to issue a certificate to the Certification Authority (CA).
  5. Certificate delivery to NDES.
  6. Certificate delivery to the device.

 

Various Aspects of Security

  • The key pair is created by the device (or its TPM) and the private key never leaves the device (or the TPM).
  • Security of the enrollment process depends on the security of the server hosting the Connector and the NDES Role Service.
    • Intune Connector is installed on the same server that hosts NDES. This server should be properly hardened, with a minimum number of local Admins.
    • Verification of certificate subject is performed through Intune together with a NDES Policy Module installed in C:\Program Files\Microsoft Intune\NDESPolicyModule.
    • NDES works as a Registration Authority, meaning that it uses its NDES Enrollment Agent certificate to countersign each certificate request after verification, before forwarding it to the CA. Consequently, the NDES Enrollment Agent certificate is extremely sensitive and should be enrolled and stored in an HSM: An adversary getting hold of the NDES Enrollment Agent certificate (and private key) could counter-sign a certificate request of his choice with arbitrary subjects, thereby enrolling valid user authentication certificates (think of the CEO or the Enterprise Administrator). Keep in mind that members of the Local Admins group have access to keys stored in the Local Computer certificate store!
    • NDES can run either in the context of Network Service or of a domain service account. Group Managed Service accounts (gMSA) are not supported with the Intune Connector installed. Hardening the NDES service account is essential, not only for your certificate enrollment process, but also for your Active Directory security (weak service accounts make your AD vulnerable to “Kerberoasting” attacks).
  • NDES requires Enterprise Admin group membership for installation.
  • The Intune Connector/NDES server must be accessible from the Internet and protected by a reverse proxy, like WAP or Azure Application Proxy with Azure Conditional Access. Find more details at: Support for NDES on the Internet.
  • Although this is not a feature of SCEP, the Intune NDES Connector provides a feature to revoke certificates at the Certification Authority.
  • Non-security related side note: When several profiles (e.g. SCEP and VPN or Wi-Fi) are applied to iOS devices at the same time, a separate certificate is enrolled for each profile. 

 

PKCS (Public Key Cryptography Standard)

The term “PKCS” may be confusing here, because Wikipedia explains PKCS as follows: “PKCS are a group of public-key cryptography standards devised and published by RSA Security LLC, starting in the early 1990s. The company published the standards to promote the use of the cryptography techniques to which they had patents, such as the RSA algorithm, the Schnorr signature algorithm and several others. Though not industry standards (because the company retained control over them), some of the standards in recent years have begun to move into the "standards-track" processes of relevant standards organizations such as the IETF and the PKIX working-group[1].”

However, in this context “PKCS” simply means that two different PKCS standards are used to request a certificate (PKCS#10) and/or push the certificate including the private key (PKCS#12) to the device.

 

Some key facts about PKCS#12:

    • PKCS#12 is the successor to Microsoft's "PFX", however, the terms "PKCS #12 file" and "PFX file" are sometimes used interchangeably. Find more details at Wikipedia explaining PKCS#12 .
    • PKCS#12 defines an archive file format for storing many crypto objects within a single file (e.g. private key + certificate + CA certificates).
    • PKCS#12 is protected by a password because it contains sensitive data (the private key). This password is named “PFX password” further on.

     

a) PKCS

In this scenario you install the same peace of software as for SCEP enrollment ("Microsoft Intune Certificate Connector” aka “NDES Certificate Connector” or simply NDESConnectorSetup.exe”), you just select different configuration options. More details are provided here: Configure and use PKCS certificates with Intune.

 

Certificate Enrollment Process

A detailed description of the enrollment process is provided in the article Troubleshoot use of PKCS certificate profiles to provision certificates with Microsoft Intune.

 

Prerequisite: To use a SCEP certificate profile, devices must trust your Root Certification Authority (CA). Create a Intune Trusted Certificate profile in Intune to provision the Trusted Root CA certificate to users and devices.

 

The following steps provide an overview of using PKCS for certificate enrollment in Intune:

DagmarHeidecker_0-1624995879432.png

 

  1. In Intune, an administrator creates a PKCS certificate profile, and then targets the profile to users or devices.
  2. The Intune service requests that the on-premises Intune Certificate Connector creates a new certificate for the user.
  3. The Intune Certificate Connector creates a key pair and a Base64 encoded PKCS#10 certificate request.
  4. The certificate request is sent to an Active Directory Certification Authority.
  5. The CA verifies the certificate request.
  6. If positive, the CA issues the certificate, and returns it to the Intune Connector.
  7. The Connector re-unites the certificate with the private key by creating a PKCS#12 envelope and encrypts it with a randomly generated password (PFX Password).
  8. The PFX Password is then encrypted with the Intune KeyRecoveryAgent certificate before it is uploaded to Intune together with the PKCS#12 certificate.
  9. Intune decrypts the PKCS#12 certificate and re-encrypts it for the device using the Device Management certificate. Intune then sends the PKCS#12 to the device.
  10. The device decrypts the PKCS#12 and imports it.

 

Various Aspects of Security

  • Security of the enrollment process depends on the security of the server hosting the Connector (this is even more true in case the Local System account is used to connect to the CA). This server should be properly hardened, with a minimum number of local Admins.
    • The Connector submits certificate requests in the context of the computer account hosting the Connector.
    • This computer account can request certificates with a subject of its choice (including the CEO’s or Enterprise Admin’s username).
    • Intune derives the subject from the authentication token, there is no additional verification of the subject.
  • The server hosting the Intune Connector does not need to be published to the Internet.
  • The certificate private key is generated on the server where the Connector is installed and not on the user’s device. It is required that the certificate template allows the private key to be exported, so that the certificate connector can export the PFX certificate and send it to the device. However, please note that the certificates are installed on the device itself with the private key marked as not exportable.

 

Scalability

In contrast to the SCEP Connector, with PKCS Connector the issuing CA as well as the certificate template are configured in the Intune profile. This means that one PKCS Connector can be used to enroll different certificate templates or even enroll certificates from different CAs.

 

b) Imported PKCS

Microsoft Intune supports use of imported public key pair (PKCS) certificates, commonly used for S/MIME encryption with email profiles. S/MIME decryption is challenging because an email is encrypted with a public key:

  • You must have the private key of the certificate that encrypted the email on the device where you're reading the email so it can be decrypted.
  • Before a certificate on a device expires, you should import a new certificate so devices can continue to decrypt new email. Renewal of these certificates isn't supported.
  • Encryption certificates are renewed regularly, which means that you might want to keep past certificate on your devices, to ensure that older email can continue to be decrypted.

Because the same certificate needs to be used across devices, it's not possible to use SCEP or PKCS certificate profiles for this purpose as those certificate delivery mechanisms deliver unique certificates per device. Here is the main drawback of S/MIME: It is impossible to securely and at the same time efficiently synchronize keys across devices and that’s why Microsoft recommends using Azure Information Protection instead (which was designed with having today’s security and usability challenges in mind).

 

However, if you still want to go for this scenario you need to install the “PFX Certificate Connector for Microsoft Intune” or simply “PfxCertificateConnectorBootstrapper.msi”. The article Use imported PFX certificates in Microsoft Intune provides details about the configuration.

 

Certificate Deployment Process

This method neither covers creation of key pairs nor enrollment of certificates. It simply assumes that key pairs and certificates already exist. The focus of this Intune Connector is to offer a temporary solution while migrating from S/MIME to a more up to date solution like Office 365 Message Encryption. S/MIME was originally standardized in 1995 when users didn’t have multiple mobile devices and key compromise was something you didn’t have to worry about.

 

The following steps provide an overview of the PKCS#12 certificate deployment process in Intune:

DagmarHeidecker_0-1624997121431.png

 

  1. The PFX Certificate Connector holds a PFX Certificate Connector certificate and uses the private key to encrypt the PFX password.
  2. The encrypted PFX password is uploaded to Intune.
  3. The user’s S/MIME certificate (in PKCS#12 format) is protected with the PFX password and uploaded to Intune, too.
  4. In Intune, an administrator creates a PKCS#12 certificate profile, and then targets the profile to users or devices.
  5. The user’s device requests the PKCS#12 certificate.
  6. Intune sends the encrypted PFX password, the PKCS#12 certificate and the device’s public key to the PFX Certificate Connector.
  7. The PFX Certificate Connector decrypts the PFX password.
  8. The PFX Certificate Connector re-encrypts the PFX password with the device’s key.
  9. The re-encrypted PFX password and the PKCS#12 certificate are sent to Intune.
  10. The re-encrypted PFX password and the PKCS#12 certificate are forwarded to the user’s device, which then decrypts the PFX password, decrypts the PKCS#12 certificate and imports it into the device.

 

Various Aspects of Security

  • Security of the deployment process is dependent on the security of the server hosting the Connector. This server should be properly hardened, with a minimum number of local Admins.
    • The PFX Connector certificate’s private key should be protected using an HSM.
  • As already mentioned, S/MIME was originally standardized in 1995 when users didn’t have multiple mobile devices and key compromise was something you didn’t have to worry about. Today, we see distributing and using the same private key across various devices with a different level of security as a contradiction in itself.
  • The PFX Connector only covers the distribution of certificates and private keys to the user’s devices. It does not cover:
    • Creation of key pairs, requesting and enrolling certificates
    • Secure on-prem storage of private keys
    • Certificate revocation in case a device is lost or stolen
    • Renewal of expiring certificates

 

I hope you enjoyed this article and it helps to bring some light into the various options of enrolling certificates via Intune.

 

 

 

 

 

 

 

6 Comments
Version history
Last update:
‎Jun 29 2021 01:39 PM
Updated by: