Transferring S/MIME certificates to Microsoft Intune

In a modern networked world, the confidential transmission of messages in the corporate environment is essential for business success. Despite their Age it is still impossible to imagine modern corporate communications without e-mail. However, its use has changed significantly over the decades.

Nowadays, it is common to be able to read and write business e-mails on mobile devices such as smartphones and tablets. Such end devices are usually connected by means of Mobile Device Management (MDM) managed by systems such as Microsoft Intune.

For the encryption of e-mail messages, companies usually use the Secure / Multipurpose Internet Message Extensions (S/MIME) standard and provide their users with the corresponding certificates. How do these certificates get to the end devices of the users in a scalable way?

Basics

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

The process described below makes excessive use of the basic concepts of public key infrastructure (PKI). To understand it, the reader should thus be familiar with the Basics of Public Key Infrastructures (PKI) have internalized.

The main aspects is briefly summarized below:

PKI is based on the concept of asymmetric cryptography. Here, pairs of keys (called public and private keys) that always belong to each other are used. The basic idea is that one key can decrypt what the other has encrypted.

How S/MIME works

When the S/MIME certificate is issued, the certification authority has attached it (and therefore the user's public key) to their user object in the Active Directory. This attribute is transferred to the global address list (GAL) of Microsoft Exchange (and/or Office 365).
The sender (Bob) now requests the S/MIME certificate (the public key) of the recipient (Alice) in the global address list.
Using the recipient's public key, the sender encrypts the message and then sends it to the recipient.
The recipient of the message is now able to decrypt the message using his private key.

If S/MIME certificates are used to encrypt e-mails, the same private key must be available on every end device (in contrast to pure signature certificates).

Many certificates and keys in play

A large number of certificates and key pairs are used in the following process, so the following overview should provide some clarity:

Certificate/key	Description
S/MIME certificate (of the user)	Allows the user to decrypt encrypted emails. This certificate is to be brought to his managed end device via Intune.
Certification Authority Exchange Certificate	Used for transport encryption when archiving the private key of the S/MIME certificate.
Key Recovery Agent (KRA) certificate	Used for archiving the private key of the S/MIME certificate in the certification authority database. When archiving, the public key is used; when restoring, the private key is used.
Key pair (or certificate) for Intune certificate import (customer key)	Is used to encrypt the passwords of the S/MIME certificates in PKCS#12 format before uploading them to Intune and to decrypt them for use on managed end devices. This ensures that Intune has no knowledge of the passwords and therefore no access to the private keys of the users' S/MIME certificates.
Device key (device key)	A key pair that enables the managed end device to receive and decrypt encrypted data. The public key is transferred to Intune when the device is registered in Intune.

How the certificate reaches the mobile device

In the following, the process is started with a "PKCS imported certificate profile" is described. This method is intended to ensure that Intune and therefore its operators cannot gain knowledge of the user's private keys.

Intune currently appears to be the only mobile device management system that offers corresponding protection against itself. Other MDMs such as VMware Workspace One are aware of all passwords of the PKCS#12 files, depending on the distribution type.

Application for the S/MIME certificate and archiving of the private key

The path of the Private key archiving is the "classic" way, as Microsoft once intended. In modern corporate environments, it is not guaranteed that every user has a regular desktop computer with Active Directory membership. Thus, there may be scenarios in which the private keys for S/MIME certificates are generated centrally. However, the path for provisioning in Intune is basically the same.

The user requests an S/MIME certificate from a Windows computer. Usually this is done via Autoenrollment. Is the Private key archiving is activated, the private key is also transferred to the certification authority in the course of the certificate request (the certificate for certification authority exchange of the certification authority is used for transport encryption).
After issuing the S/MIME certificate, the certification authority now encrypts the user's received private key with one or more Key Recovery Agent certificates, more precisely with their public keys.

Transferring the private keys to Intune

The S/MIME certificate and the corresponding private key are queried via a targeted query against the certification authority database.
The user's encrypted private key is decrypted with the private key of the associated key recovery agent certificate and exported to a PKCS#12 file (also known as PFX or P12). The PKCS#12 file contains the user's S/MIME certificate and the corresponding private key and is protected with a password.
The PKCS#12 file is now created with the Intune PFXImport PowerShell module is uploaded to Intune. The password of the PKCS#12 file is encrypted with the public key for the Intune certificate import (customer key) before it is sent to Intune. This ensures that Intune cannot obtain knowledge of the password and therefore the user's private key.

Import of the S/MIME certificate to the end device

When registering the end device in Intune, the managed end device transmits its public key to Intune.
Intune contacts the Intune Certificate Connector at the customer. The user's PKCS#12 file, the corresponding encrypted password and the public key of the end device are transferred from Intune to the Intune Certificate Connector.
The Intune Certificate Connector decrypts the password of the PKCS#12 file with the existing private key for the Intune certificate import (customer key) and now encrypts it with the public key of the end device received from Intune.
The result is now transferred back to Intune.
Intune now transfers the PKCS#12 file and the password encrypted with the public device key to the managed end device.
The managed end device can now decrypt the received data with its private device key and import the PKCS#12 file. The user's managed end device is now in possession of their S/MIME certificate and the corresponding private key.

Notes

Communication between the Intune Certificate Connector and Intune is always triggered by the Intune Certificate Connector, but this can be contacted logically by Intune in this way.
The same applies to communication between the managed end device and Intune.
For Android or Windows end devices and iOS end devices that do not use Apple's own Mail app, only the password is converted. On iOS with the native Mail app, the entire PFX file is decrypted. This is possible due to the security architecture used by Applewhich does not allow third-party access to the Apple keychain.
The Intune Certificate Connector cannot verify whether the managed end device is known or whether the public device key presented to it belongs to the corresponding end device, let alone to the owner of the S/MIME certificate.

Although Intune therefore has no direct knowledge of users' keys, this circumstance could theoretically be exploited by Intune operators for a man-in-the-middle attack by inserting any key into the communication chain for which they have the private key.

Concrete implementation

On GitHub I published a script for reading, transcoding and transferring S/MIME certificates to Intune.