Home > Mac administration, macOS, Management Profiles, Mobile Device Management > Creating macOS configuration profiles with encrypted payloads

Creating macOS configuration profiles with encrypted payloads

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):

Screen Shot 2019 09 15 at 11 15 41 PM

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

Screen Shot 2019 09 15 at 1 55 35 PM

Screen Shot 2019 09 15 at 1 57 00 PM

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

Screen Shot 2019 09 15 at 1 58 58 PM

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

Screen Shot 2019 09 15 at 1 59 51 PM

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

Screen Shot 2019 09 15 at 2 00 19 PM

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

Screen Shot 2019 09 15 at 2 00 59 PM

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.

Screen Shot 2019 09 15 at 5 37 23 PM

Screen Shot 2019 09 15 at 5 37 29 PM

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.

Screen Shot 2019 09 15 at 4 40 41 PM

Screen Shot 2019 09 15 at 2 47 03 PM

Encrypting a profile

Once the certificate profile is installed on a particular Mac, it should appear in the System keychain as a trusted root.

Screen Shot 2019 09 15 at 2 47 25 PM

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:

Screen Shot 2019-09-15 at 2.08.11 PM

/usr/libexec/mdmclient encrypt "encryptprofiles.company.com" "/Users/username/Desktop/Company WiFi.mobileconfig"

A new profile should appear named Company WiFi.encrypted.mobileconfig.

Screen Shot 2019-09-15 at 2.07.50 PM

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.

Screen Shot 2019 09 15 at 5 12 20 PM

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.

Screen Shot 2019 09 15 at 5 58 40 PM

  • 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.

 

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: