Recently, I was asked to create a configuration profile with an encrypted payload. This is a payload where the settings installed by the profile are not readable when you look at the .mobileconfig file. Instead, the payload with the settings is encrypted and are only readable once the payload contents are decrypted using the private key of a certificate which is also installed on the Mac in question.
In researching how to do this, I found that Apple’s documentation on encrypted payloads is very sparse and largely consists of the following (from https://developer.apple.com/documentation/devicemanagement/using_configuration_profiles):
Example commands for CMS encryption of the property list are not provided in Apple’s documentation, but it is possible to use /usr/libexec/mdmclient to encrypt profile payloads:
https://mosen.github.io/profiledocs/troubleshooting/mdmclient.html#encrypt
To see how this works, let’s go through the process of setting up a certificate which can be used for encrypting a profile followed by using that certificate to encrypt the profile. For more, please see below the jump.
Before we begin creating the certificate, I want to note that the certificate used in this example is going to be a self-signed root certificate. Using a self-signed root certificate is fine for prototyping and testing, but you should use a certificate issued by a trusted certificate authority if you’re using this method in production.
Creating the certificate
1. Run the following commands to generate a private key:
openssl genrsa -des3 -passout pass:x -out encryptprofiles.pass.key 2048
openssl rsa -passin pass:x -in encryptprofiles.pass.key -out encryptprofiles.key
Once the encryptprofiles.key file is generated, the encryptprofiles.pass.key file may be removed as it is no longer needed.
2. Run the following command to generate a certificate signing request (CSR):
openssl req -new -key encryptprofiles.key -out encryptprofiles.csr
You will be asked a number of questions. The one which ultimately matters in this case is the Common Name question, as that is the one which is the name assigned to the certificate. In this case, I am setting encryptprofiles.company.com as the Common Name for the certificate.
Note: The challenge password can be left blank.
3. Once the CSR has been generated, run the following command to create a public key using the private key and CSR:
openssl x509 -req -sha256 -days 365 -in encryptprofiles.csr -signkey encryptprofiles.key -out encryptprofiles.crt
4. Combine both the private key and public key into one text file named bothprivateandpublickeys.txt by running the following command:
cat encryptprofiles.key encryptprofiles.crt > bothprivateandpublickeys.txt
5. Run the following command to generate a .p12 file which uses the contents of the bothprivateandpublickeys.txt file to generate a .p12 archive file which contains both the private and public key:
openssl pkcs12 -export -in bothprivateandpublickeys.txt -out bothprivateandpublickeys.p12
You will be asked to set and verify an export password. You will need this password later, so make a note of it.
In this case, the following password is being used: password123
Creating a certificate profile
My next step was to create a configuration profile using ProfileCreator which included both the bothprivateandpublickeys.p12 file and the export password needed to unlock the .p12 file. This profile will import the .p12 file and use it to deploy the encryptprofiles.company.com certificate as a trusted root certificate.
Once built, the profile looks like this:
The final step is to install the profile, so that we can use it to encrypt another configuration profile’s payload. The profile installation can be performed via MDM, using the profiles command line tool or by double-clicking on the profile to install it.
In this case, I’m signing the certificate with my Developer ID Application signing certificate and then double-clicking to install it.
Encrypting a profile
Once the certificate profile is installed on a particular Mac, it should appear in the System keychain as a trusted root.
Once the certificate is showing up in Keychain Access as trusted, it can be used to encrypt profiles. To do this, run a command similar to the one shown below:
/usr/libexec/mdmclient encrypt "certificate_common_name_goes_here" /path/to/profile_to_encrypt_goes_here.mobileconfig
In my case, I’m running the following command to encrypt a configuration profile named Company WiFi.mobileconfig:
/usr/libexec/mdmclient encrypt "encryptprofiles.company.com" "/Users/username/Desktop/Company WiFi.mobileconfig"
A new profile should appear named Company WiFi.encrypted.mobileconfig.
The original Company WiFi.mobileconfig profile looks like this, with the profile’s settings listed under PayloadContent:
The new Company WiFi.encrypted.mobileconfig profile looks like this, with the profile’s settings encrypted and listed under EncryptedPayloadContent:
Installing an encrypted profile
Assuming the certificate profile is installed on a particular Mac, the encrypted profile can now be installed. The profile installation can be performed using the profiles command line tool or by double-clicking on the profile to install it.
If the certificate used to decrypt the profile is present and everything is working properly, the encrypted profile should install without a problem.
If there is a problem with decrypting the profile, the process will error because the Mac won’t be able to read the profile’s encrypted payload.
Notes on this process
- It is absolutely necessary for the certificate used to encrypt the profile to be deployed to the Mac receiving the encrypted profile and necessary for that certificate to include the private key.
- It is also necessary for the export password used to protect the .p12 file be provided, either in the profile itself or manually provided when the certificate profile is installed.
- The reason is that the private key is used to decrypt the profile’s encrypted content and the export password is used to make that possible.
- The certificate must be deployed to the Mac receiving the encrypted profile before the encrypted profile is. If not, the encrypted profile won’t be readable by the Mac and the profile won’t install.
- You likely won’t be able to deploy the encrypted profile using an MDM server.
- The reason is that when the profile was uploaded to the MDM server, the MDM server may try to read the profile and fail because it doesn’t have access the certificate used to decrypt the encrypted profile’s contents. This causes the upload process to halt and display an error. Instead, you will need to install the encrypted profile using the profiles command line tool.