Certificates and Device Management: A Guide for Mac Admins

On the Internet, nobody knows who you are–only who you say you are. Our digital interactions happen on servers and devices, with people we may never see in person. 

So how do we know that the websites and services we connect to online are legit? How do we know that the emails, texts, and other transmissions we receive are indeed what their senders sent? How does an organization know that the user or device trying to authenticate into an enterprise resource really is that user or device? 

In the digital world, certificates are widely used to establish these and other forms of trust. Here’s an overview of how they work and how they’re used in the enterprise. 

What Are Certificates? 

Certificates are digital entities that—like a driver's license or a passport—prove identity and so establish trust. More formally, they are files based on the X.509 standard that contain a variety of information, such as a user’s name, company, the public key, and details about the owner and name of the certificate authority (CA) issuing the certificate. (More on that last bit below.) More specifically, each certificate typically contains the following:

• Version: Specifies which version of the X.509 standard applies to the certificate. X.509 version 3, introduced in 1996, is the most commonly used version today.
• Serial Number: A unique identifier provided by the CA to distinguish it from other certificates. The serial number is typically used to revoke a certificate. 
• Algorithm information: The algorithm used by the CA to sign the certificate.
• Issuer: The CA that signed or issued the certificate.
• Validity period: The start/end dates and times of when a certificate can be trusted.
• Subject distinguished name: The name of the entity the certificate identifies.
• Subject public key information: The public key associated with the entity.

That last item is particularly important: Modern-day encryption relies on public key infrastructure (PKI), a framework that defines how keys are used to establish trust and to encrypt and decrypt transmitted data. There are two types of encryption: symmetric and asymmetric.

Symmetric encryption uses a single key to both encrypt and decrypt data, making it less secure and more susceptible to man-in-the-middle attacks.

Asymmetric encryption solves this problem with the use of cryptographically related key pairs–one public key and one private key. The public key is used to encrypt data and the private key is used to decrypt data. But while anyone can use the public key, the private key is kept, well, private; if it gets out, a bad actor can then use that identity to sign malicious content. 

Asymmetric encryption is used every day when we visit HTTPS websites. Our browsers obtain the public key of the SSL certificate installed on a website and use that same key to encrypt data sent back to the website; the private key is used to decrypt the data received.

Certificates can be created in several ways. Individual users can create them using graphical tools such as Keychain Access in macOS or with command-line tools such as openssl. In enterprise settings, certificates are created or signed either by a publicly-trusted certificate authority or a private internal certificate authority, depending on the kind of certificate that's needed. 

Regardless of where or how a certificate is created, it must be signed by a certificate authority. These are entities that validate the authenticity of a certificate and so provide trust. They are like the government that issues a passport: They verify the requester’s information and then issue an ID that can be used to travel. Most importantly, other entities can decide whether or not to trust that ID, depending on its CA. 

However, since anyone can be a CA, trust has to start somewhere. Devices must be able to decide who they should and shouldn't trust right out of the box. Operating systems contain a pre-selected list of trusted root certificates from public CAs—known as a Trust Store—which helps establish a chain of trust. That chain of certificates starts with the root CA but also includes intermediate certificates signed by it. The standard practice is to rely on certificates signed by these intermediates, rather than the root CA. Devices and the OS will trust certificates signed by intermediates because the intermediate is signed by the trusted root CA—that’s the chain of trust. 

In macOS, you can use Keychain Access to see the preinstalled root certificates from public CAs that Apple trusts. Apple’s full list of the root certificates its operating systems trust can be viewed here.

Enterprises will often issue self-signed certificates. Such certificates will typically not be trusted by devices, which reject them for security reasons. But you can manually instruct devices to trust the identity presented by the certificate. When using a Mac device management solution such as Kandji, you can add root CAs to the device’s Trust Store, so the device can automatically trust certificates signed by them.

What Certificates Are Used For?

No matter who issues them, certificates are used in innumerable ways. 

For example, Secure Socket Layer (SSL) certificates are used to authenticate website identities and to create an encrypted connection between web servers and browsers. SSL certificates are also used to secure online transactions and keep a customer’s information private. An SSL certificate can be examined by clicking the padlock icon in the URL field of a browser.

Code-signing certificates—such as those issued by Apple to registered developers—are used by those developers to sign their applications and identify themselves. This allows the user to verify that the software they are receiving has not been tampered with after it left the vendor. If the code had been changed or altered, the digital signature would be broken, and macOS or iOS would prevent the software from opening.

Enterprises use client-based certificates to authenticate users or devices before giving them access to internal or corporate resources; this is typically called certificate-based authentication (or CBA). User authentication can take place before accessing corporate email, internal networks, or cloud services; device authentication can be required before accessing Wi-Fi networks, VPNs, or other gateways. 

Both ensure that the users or devices accessing resources are indeed trusted by the enterprise. Because CBA workflows can replace the need for username and password to authenticate, they can also help streamline the user experience when accessing those resources.

Certificates and Device Management

In the specific context of device management, certificates are used to establish trust between device management solutions and Apple services such as Apple Business Manager, as well as between device management solutions and the devices they manage.

When managing devices with a device management solution, a trusted and encrypted line of communication must be established between Apple, the device being managed, and the MDM server, before that device can enroll into the MDM. This relationship of trust is established by obtaining an Apple-signed certificate for the Apple Push Notification service (APNs) for device management and an SSL certificate issued by a trusted CA for encryption.

Both of these certificates must be renewed regularly to maintain trust. More specifically, the APNs certificate must be renewed on a yearly basis to allow for the continuation of device management. If that certificate is revoked, or if it needs to be replaced, the device must be re-enrolled after a new APNs certificate is procured. (For best practices on managing APNs certificates, see our post on "How to Troubleshoot Apple Business Manager.")

Organizations can use their device management solutions to distribute client-based certificates via configuration profiles. MDM can also be used to add internal or private root certificates to the device’s Trust Store. These certificates can be signed and issued by the organization or by a public CA but only to be used by trusted devices (typically in zero-trust scenarios). Device management solutions can also be used to prevent users from adding untrusted certificates to an iOS device’s Trust Store.

Certificates are critical components in modern device management. They enhance security by supporting verification, expiration, and revocation, in addition to encrypted communications. And they're able to evolve to deal with the ever-changing tactics of adversaries and bad actors.

About Kandji

The Kandji team is constantly working on solutions to streamline your workflow and secure all of your Apple devices. With powerful and time-saving features such as zero-touch deployment, one-click compliance templates, and plenty more, Kandji has everything you need to bring your Apple fleet into the modern workplace.