Enhancements to certificate security for mobile device management (MDM) enrollment

Due to enhanced security requirements in iOS 10.3, Jamf Pro version 9.98 ensures that communication between client iOS devices and the Jamf Pro server cannot occur without an established trust relationship. Establishing a trust relationship is based on the installation and verification of certificates on your client devices and the Jamf Pro server.

In addition to the changes around iOS device enrollment, starting in Jamf Pro version 9.98, the "SSL certificate verification" setting on the Security page for macOS computers will be enabled by default.

Jamf recommends installing a trusted Secure Sockets Layer (SSL) certificate from a 3rd-party vendor on the Jamf Pro server. Vetted, trusted, 3rd-party certificates allow stricter security features to be enabled "out of the box" because Apple devices have pre-installed, trusted System Root certificates from most 3rd-party vendors. If an established trust relationship between client devices and the Jamf Pro server already exists, manually establishing a trust relationship becomes unnecessary.

If you are currently using a trusted SSL certificate, or are using Jamf Cloud, Apple's new enhanced security requirements will not impact you.

Establishing identity and trust with certificates
There are, generally, three types of SSL certificates:

• Self-signed
• Signed by an untrusted issuer
• Signed by a trusted issuer

To help explain each type, we can use the analogy of a person being introduced in three different ways:

Self-signed
A person walks into a room and introduces himself as "Bob Johnson.” You don't know Bob and you have no way to verify his name.

Signed by an untrusted issuer
A person walks into a room with another person. The first person introduces the other as "Bob Johnson.” You don't know the first person or Bob, but someone is vouching for Bob's identity. If you choose to trust the person vouching for Bob, you can reasonably trust Bob.

Signed by a trusted issuer
A person walks into a room and presents their government-issued identification. The name stated on the government-issued identification is "Bob Johnson.” Since you have a reasonable expectation that Bob's government-issued identification is legitimate and valid, you can infer that the person introduced as "Bob Johnson" is actually Bob Johnson.

These "introductions" map to SSL certificate types as follows:

Self-signed:
The certificate created by the Jamf Pro installer based on the hostname of the server on which it is installed. It is not signed by any certificate authority and exists primarily for checking to determine if the installation was successful or not, and to allow for encrypted communication from the point of installation. There is no way of independently verifying the name or "identity" of this server.

Signed by an untrusted issuer:
A certificate that is signed by the built-in certificate authority of the Jamf Pro server or by some other certificate authority. If trust can be established to this certificate authority, mobile device management (MDM) enrollment will succeed. This is similar to the way someone who you do not know might vouch for someone else's identity when that person is introduced to you.

Signed by a trusted issuer:
A certificate signed by a trusted certificate authority acts as a validation of identity in much the same way that a form of government-issued identification would.

For additional information, see:

• https://support.apple.com/en-us/HT204132
• https://support.apple.com/en-us/HT202858

Certificate-based authentication
Certificates are installed on both the Jamf Pro server and on client devices to establish trust and communication.

Upon enrollment, all client devices receive a unique certificate used to verify the client for all subsequent communication to the Jamf Pro server. This function is enabled by default for both iOS and macOS, and it cannot be disabled for iOS. If certificate-based authentication is disabled for macOS, computers can be enrolled into the Jamf Pro server, but will not be MDM-enrolled and will not be able to leverage MDM features for macOS. For more information, see:

• http://docs.jamf.com/9.98/casper-suite/administrator-guide/Remote_Commands_for_Computers.html

Below are some guidelines to follow regarding the enhancements to certificate security.

iOS
iOS devices have always required trust from the certificate authority that signed the SSL certificate presented by the Jamf Pro server during enrollment. However, starting in iOS 10.3, certificate security requirements for MDM enrollment have tightened.

If you are not using a trusted SSL certificate, iOS devices can be enrolled via Apple's Device Enrollment Program or can be supervised and enrolled using Apple Configurator 2 (after having created a Supervision Identity for your organization.) Using these methods, trust to a previously untrusted certificate authority can be established automatically. No additional configuration steps are required to install a valid MDM profile on a device.

If you are not using a trusted SSL certificate and are attempting to enroll iOS devices running iOS 10.3 or later using the Jamf Pro server via user-initiated enrollment, devices will fail to install an MDM profile because they will not trust the certificate authority that signed the SSL certificate presented during the enrollment process.

In previous iOS versions, the installation of the certificate authority (CA) certificate profile obtained from the Jamf Pro server during user-initiated enrollment would establish trust to any certificate authority. Additional steps are now required to establish trust after installing the CA certificate profile and before installing the MDM profile.

To establish trust: exit the browser during user-initiated enrollment after installing the CA certificate profile, then go to Settings > About > Certificate Trust Settings and toggle the option to "Enable Full Trust for Root Certificates" for the certificate authority listed. Once trust is established, go back to the browser and continue with the installation of the MDM profile to complete the enrollment process.

macOS
There are now three options under "SSL Certificate Verification" for macOS computers on the Security page in the Computer Management section of the Jamf Pro server:

• Never
• Always except during enrollment
• Always

The option for "Always except during enrollment" was added in Jamf Pro version 9.98 for admins preferring to use an SSL certificate signed by an untrusted issuer. This is now the default option selected on a newly-installed Jamf Pro server. Jamf recommends installing a trusted SSL certificate from a 3rd-party vendor on the Jamf Pro server.

If you are upgrading from a previous Jamf Pro version, "SSL Certificate Verification" will be set based on whether or not "Enable SSL certificate verification" was previously configured. If so, the setting in Jamf Pro version 9.98 will be automatically set to "Always". If not, the setting will be automatically set to "Always except during enrollment", unless you made changes to the Security page, in that case, it will be set to "Never”.

If "Never" is selected, you will be presented with a notification warning in your Jamf Pro server asking you to "Enable SSL Certificate Verification”.

If you are using an SSL certificate signed by an untrusted issuer and you change the setting to “Always", computers will fail to enroll because trust must be established prior to enrollment.

For more details:

• https://docs.jamf.com/technical-articles/index.html?contextId=447
• https://docs.jamf.com/technical-articles/index.html?contextId=455

To ensure that macOS computers will trust the Jamf Pro server SSL certificate prior to changing the "SSL Certificate Verification" setting to “Always", you can add the extension attribute for "JSS Certificate Validation" via its template, allow inventory collection to occur and wait for computers to return a "Success" status. For more information, see:

• http://docs.jamf.com/9.98/casper-suite/administrator-guide/Computer_Extension_Attributes.html