Managing Certificates with Jamf

Managing Certiﬁcates

with Jamf

Certiﬁcates play a vital role in securing, authenticating and

maintaining the stability of your Apple ﬂeet. When used correctly,

they will increase visibility while cutting down security risks.

The basics of certiﬁcate-based

communications

Certiﬁcates can appear confusing or overwhelming.

This is often because they have been misused or

misunderstood, and rolling out a successful

cert-based project can be confusing and

overwhelming without help.

Also, certiﬁcates are often misused in a customer

environment. For instance, security tells you that

there's a dozen or so certs that need to be installed

on your Mac ﬂeet. So you use Composer, back them

up, and put them into your provisioning workﬂow.

But what are those certiﬁcates for?

We don't know. But they're installed in the keychain

now. Are they trusted? Is the chain complete?

Maybe. Maybe not.

Let's demystify certiﬁcate creation and deployment!

What are Certiﬁcates?

Acertiﬁcate is just atext ﬁle. That's it. There's aton more behind the scenes as far as the signing,

cryptography, and private key infrastructure (PKI) that you can delve into, but that's the basic ﬁle.

How do you make acertiﬁcate?

To make acert, we need acertiﬁcate request, or CSR. Then, we reach out to acertiﬁcate server

that talks to the Certiﬁcate Authority (CA) and it will add its part to the conversation. Sometimes

we add the root cert as well. Then, we have adigitally signed certiﬁcate.

If you open acertiﬁcate in atext editor, you will see only unreadable hex code, because the

certiﬁcate is encrypted. On aMac, you can still inspect the contents of acertiﬁcate using Spotlight

by hitting the space bar, or by opening it in keychain access to see what's inside.

What data does acertiﬁcate contain?

Identiﬁcation data. Acert is essentially an id card. Acertiﬁcate is asigned and trusted source of

identiﬁcation, sort of like adriver's license or passport. Like apassport, the validity of trust for the

document is based on the issuing authority.

If Ihad aforklift license issued in Canada, that doesn't mean I'm authorized to operate aforklift in

Germany. Similarly, aSam's Club card doesn't allow me to shop at Costco.

Something like apassport only works as avalid ID everywhere because the issuing bodies have

all agreed to trust each other. If Peru says you're acitizen, Canada accepts that because it is

atrusted document.

If, for instance, someone produced agalactic passport and it claimed this person had the rank of

Jedi Master, no one would believe the contents of that document because it didn't come from

atrusted source.

Let's take alook at acertiﬁcate next to apassport and see exactly how much they have in common.

Certiﬁcates aren't totally incomprehensible!

NAME, OR SUBJECT

ISSUING BODY

(PERU OR AMAZON)

UNIQUE SERIALIZATION

VALIDITY DATE

Why use certiﬁcates in computing?

For security's sake. The use of trusted certiﬁcates allows for encrypted communication, which can prevent

information from being intercepted while in transit.

When you visit a website using https and you get a green checkmark or lock icon in the address bar, you're

communicating with that server using a certiﬁcate. The shared connection with that site is secure.

Certiﬁcates as Credentials

Certs can be used as an alternative to user credentials. When a client presents a certiﬁcate, the server inspects the

cert and decides if it's going to trust that client based on the contents and the certiﬁcate authority that made that cert.

Where can we use this form of secure identiﬁcation?

With 802.1x WiFi, typically referred to as cert-based WiFi. This is much better than atraditional

WPA password, because the certs used cannot be shared.

Typically your network authenticator will be using Extensible Authentication Protocol (EAP) or

Radius (another authentication protocol), depending on the encryption choices.

Jamf has the advantage of validating the client that is connecting to the network. The client

device can present user information inside the certiﬁcate that proves exactly who is using

agiven device on your network.

This is very useful for your friends in InfoSec.

Using certiﬁcates to connect to VPNs

Another common use for certiﬁcates is connecting to aVirtual Private Network (VPN). Similar to

WiFi, the username and password might not be enough to establish trust. We want to be able to

validate the device is also trusted. Access is denied if the user credentials are disabled, or if the

certiﬁcate has been revoked.

Authenticating wired networks with certiﬁcates

You can ensure your company data is secure with certiﬁcates.

802.1x authentication is not limited to Wi-Fi. Though less common, it can also be used on awired

network. It's another way of preventing just anyone from gaining access to anetwork connection

and gaining access to private data.

Using certiﬁcates with encrypted email

When certiﬁcates are signed and trusted, an email message cannot be read without the correct

certiﬁcates installed. This technology also ensures that the message hasn't been modiﬁed in

transit after it was signed and sent.

Managing certiﬁcates with Jamf Pro

Deploying Certiﬁcates

Deploying certiﬁcates with an Apple MDM is straightforward: the MDM vendor, such as

Jamf, maintains the certiﬁcate life cycle. For security, they have various opportunities to

revoke the users' access if they:

• Fall out of compliance

• Leave the company

How certiﬁcates play a role with Apple and MDM

• Push notiﬁcations (APNS)

Apple's entire push notiﬁcation system relies on a chain of trusted

certiﬁcates for communication. None of it would work without certs.

• Supervision identities

In the case of Apple Conﬁgurator, Jamf creates a certiﬁcate-

based supervision identity that can be shared between multiple

provisioning Macs used to supervise and enroll iOS devices. This

same supervision identity can be added to Jamf Pro for the devices

that it supervises.

• Developer signing

As a developer, you get involved in dozens of types of certiﬁcates

from app signing development distribution and even Apple Pay certs.

You're probably using some of these certiﬁcates already in Jamf.

How and where does Jamf Pro use certiﬁcates?

The short answer: almost everywhere. Certiﬁcates play a role in:

• Enrollment proﬁles

• Device management with the Jamf binary

Built-in certiﬁcate

authority

Jamf Pro has its own Certiﬁcate

Authority (CA) built in. This

self-signed CA produces a root

cert that must be trusted on the

device before it can trust the

MDM proﬁle.

The trustJSS Command

• Apache Tomcat SSL: For an externally facing server you'll need to

install apublicly-trusted certiﬁcate.

• The built-in certiﬁcate authority is where you would conﬁgure Jamf

to talk to an external CA server. SKAT proxy and ADCS Connector

Settings are also conﬁgured here.

• Health Care Listener: Uses certiﬁcates to secure communication

inside the hospital network.

• Single Sign-On

• LDAP-S over SSL

• The enrollment process

• Signing QuickAdd package: requires an app distribution certiﬁcate from Apple. Thissame cert is used by

Composer to sign your other packages.

• Conﬁguration Proﬁles: Conﬁg proﬁles created in Jamf Pro are signed automatically. This keeps them secure when

deployed. If you download aconﬁg directly from the console, it's already signed. That's why you can't view the raw

xml data with atext editor. If you need to edit aconﬁg proﬁle created with Jamf, you'll need to unsign it ﬁrst.

• App Provisioning Proﬁle: Aprovisioning proﬁle is adierent sort of proﬁle that also uses acert. When working with

custom iOS apps, your developer might need you to deploy the app with aprovisioning proﬁle. It's less common

today, but Jamf does support it.

• Developer Certiﬁcate: you would get that cert at developer.apple.com, among other certs you might need. The more

common method these days is to let Xcode create and embed the distribution certiﬁcates and provisioning proﬁles

for you automatically. Once that's done, you'll have yourself an in-house app: acustom iOS app that can be deployed

using Jamf to register test devices. If you need to deploy your custom app to hundreds of iOS devices or more, that

will require an Enterprise developer signing certiﬁcate.

• Apple deployment portals: strictly speaking, these next few are actually tokens, aprivate key. Device enrollment

and volume purchasing both get their certs from Apple using the token provided. (The more modern place to

ﬁnd that information is in Apple School Manager or Apple Business Manager.)

• GSX (Global Service Exchange)

• Cloud Distribution Point (JCDS)

• Jamf Push Proxy: if you send notiﬁcations to your devices through self-service, you'll need apush proxy certiﬁcate.

They are automatically generated, so this one's easy to get set up.

• Patch Management and Customer Experience Metrics: while invisible to the Jamf admin, they do communicate

using certiﬁcates and are sent securely to our servers.

So, yes. Jamf uses certiﬁcates nearly everywhere in our portfolio. But none of them are the certs that are being

generated to install onto your devices.

PRO TIP!

Jamf Cloud takes care

of all of this web app

work automatically. You need not

ever worry about your TomCat

settings again.

Creating Certiﬁcates with Jamf

It's all about the context

When talking about user certiﬁcates and device certiﬁcates, it's important to know the

context we're using. You'll hear talk of user certs and device certs or machine certs. For

the most part, auser cert contains the user information in the subject, and amachine

cert contains information in the subject about the device speciﬁcally.

What's important to know is if you choose to deploy the cert at the device level, you're

installing that certiﬁcate into the system keychain and it's available to all current and

new users of that device.

If you deploy it into the user level, it's installed directly in that user's keychain and won't

be available to any other user on the system.

Jamf Simple Certiﬁcate Enrollment Protocol Proxy (SCEP) Proxy and

ADCS Connector

If you're going to be deploying VPN certs or rolling out 802.1x Wi-Fi, you'll need to use

one of these to do it. They are related but dierent product oerings. They both exist

as alternatives to binding your Mac to Active Directory to obtain the certiﬁcate, the

beneﬁt being that both solutions can work to produce certiﬁcates for Mac, iOS and

tvOS devices.

Delivered via conﬁg proﬁle

To create certiﬁcates with

Jamf, you do that in payload

conﬁg proﬁle. Jamf can also

combine certs and Wi-Fi

payloads for simplicity.

Works with Mac or iOS

This method for creating

certs works for Mac OS,

iOS and even tvOS. You

can also include multiple

certiﬁcates in a single

payload if needed.

ADCSC or SCEP Proxy? Which do you choose?

The correct choice between the two depends on so many details there is no single

right answer. Don't think of it as SCEP vs. ADCS. You may even use a combination

of both. We at Jamf are eager and willing to have those conversations with you to

decide the best path of success for your cert-based projects. Please reach out.

Deploying Certiﬁcates

There are a few ways to deploy certiﬁcates:

• Manually, by going to a web portal and entering the info. This is the more

cumbersome way.

• Through third-party applications like Nomad or Jamf Connect. These tools can take

already-provided information from the user and then make the certiﬁcate request on

their behalf. Some challenges: this still requires the user to enter some data, and the

requirement that the request must be made from within the network or via VPN can

cause problems. Additionally, these apps are only available on MacOS.

• Direct certiﬁcate request: Jamf Pro can create the request and the device

can communicate directly with the server. This means it can all be automated.

Communication is between the device and certiﬁcate server, which means the

device must be on same network as certiﬁcate server.

If you have devices outside the network and they try to contact the certiﬁcate server

for that certiﬁcate, it's very unlikely that the security team will allow this to go through.

Direct certiﬁcate request

INTERNAL NETWORK

Jamf Certiﬁcate Proxy

This is where Jamf Pro can help without compromising security, and is the most

common method for requesting certs.

In this method, Jamf Pro acts as a proxy between the device and the certiﬁcate server

using SCEP or ACS Connector. This provides the beneﬁts of the previous methods

with an added beneﬁt that the communication ﬂow changes. The device only needs to

be able to contact the Jamf Pro server. That means the device can be on any network

and still get the required certs.

Here's what the communication is like:

Proxy using Jamf Pro

INTERNAL NETWORK

REQUEST FOR

CERTIFICATE

On the right we can see the keychain access application that is already

showing one certiﬁcate: the device enrollment certiﬁcate.

You can see the contents of the request: full name and email address for

the content variables. The admin will then go to the scope tab, add the

device, and save.

From this point Jamf Pro will now be communicating with the Jamf

server. It will request the certiﬁcate from the certiﬁcate server, it will

deliver the certiﬁcate, and Jamf will deploy it to the device.

The certiﬁcate can now be used as an authentication method

for Wi-Fi or VPN.

To make it a trusted certiﬁcate, you'll need to deploy the root

certiﬁcate of the server to provide a trust chain.

So you have the certiﬁcate. How do you use it?

An end user can manually select the certiﬁcate and use it as an

authentication to the corporate wireless network.

When the user attempts to connect to an 802.1x enterprise network,

they change the mode to EAP/TLS and then select a certiﬁcate from

the keychain.

Similarly, with VPN the end-user will see similar options, providing that

kind of VPN support certiﬁcates as a method of authentication. You would

need to work within the respective teams within your organization for this.

This can all be

automated by including

the network and

VPN settings payload within the

conﬁguration proﬁle that contains

the certiﬁcate payload.

And here's how it looks to the Apple admin using ADCS connector (which is similar

to the look using SKEP), which has already been conﬁgured. This particular device

has already been enrolled. And the process is happening on a guest network with no

connection to the server with no Active Directory binding:

How to start the process of certiﬁcate creation

in your organization

You will need:

• Asupported version of the OS on the device

• Asupported CA such as Microsoft certiﬁcate authority, digicert,

Entrust Certiﬁcate Solutions or Venaﬁ

• Support from other teams in your organization

- Networking

- Security

- Certiﬁcate team

Reach out to aJamf representative to learn how to help you succeed

in deploying certiﬁcates within your organization. We can communicate

with other teams in your organization to provide context in what

is required from each department in order to have asuccessful

deployment.

Have questions? Please reach out to us at info@jamf.com and we'd be

more than happy to schedule some time with you to sit down and talk

it through.

Resources:

From Jamf:

JNUC Cert talk: jamf.it/jnuc-cert

Jamf as SCEP Proxy: jamf.it/scep

Jamf ADCS Connector: jamf.it/adcsc

Cert Deployment 101 webinar: jamf.it/cert-101

From Apple:

MDM Cert Guide: jamf.it/mdm-cert

Requirements for trusted certs: jamf.it/apple-cert-trust

Limits on trusted certs: jamf.it/apple-cert-limits