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

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 was issued, the certification authority appended it (and thus the user's public key) to the user's user object in Active Directory. This attribute is transferred to the Microsoft Exchange global address list (GAL).
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 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.
Intune Certificate Connector certificate	Used to encrypt the passwords of the S/MIME certificates in PKCS#12 format before uploading them to Intune. This ensures that Intune has no knowledge of the passwords and accordingly no access to the private keys of the users' S/MIME certificates.
Device Key	A key pair that allows the managed terminal to obtain and decrypt encrypted data.

How the certificate gets to the smartphone

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

A targeted query against the certification authority database is used to retrieve the S/MIME certificate and the encrypted private key.
The user's encrypted private key is decrypted with the private key of the 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 associated private key and is password protected.
The PKCS#12 file is now uploaded to Intune using the Intune Certificate Connector.
The password of the PKCS#12 file is encrypted with the public key of the Intune Certificate Connector before it is sent to Intune. This ensures that Intune can never know the password (unlike, for example, VMware Workspace One, where all passwords are known to Mobile Device Management, depending on the distribution type).

Import of the S/MIME certificate to the end device

Intune now transfers the PKCS#12 file to the managed end device assigned to the user. Since neither Intune nor the end device knows the password for the file, this must now be requested.
The end device thus contacts the Intune Certificate Connector. It sends its own public key and the encrypted password of the PKCS#12 file.
The Intune Certificate Connector decrypts the password with its private key and immediately encrypts it with the public key of the managed endpoint before sending the result to the endpoint.
The managed end device can now decrypt the password with its private key and ultimately import the PKCS#12 file locally.
The user's managed end device is now in possession of the S/MIME certificate and the associated private key.

Concrete implementation

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