Hi all!

I has been a while since I posted another article, and as I have been working on a few SCEP/NDES related cases recently, it inspired me to write a quick overview of the communication between Jamf Pro, the managed Apple devices and a SCEP or NDES server.

For this post I’ll mainly focus on the communication and avoid going to deep into the matter of configuring the SCEP/NDES server itself or Jamf Pro as this is highly depending on the specific SCEP setup. I mainly want to highlight a more general overview of how the communication happens between all parties.

As you may know there are 2 main (authentication) techniques to request a certificate from a SCEP (NDES) server:

  • By using a Static Challenge
  • By using a Dynamic Challenge

And apart from that, Jamf Pro offers 2 strategies in view of how the certificates are going to be requested, each with both static as dynamic challenge option:

  • Direct SCEP, where it is the device which is requesting the certificate from the SCEP/NDES server
  • Jamf as SCEP proxy, where it is actually Jamf Pro which does the certificate request on behalf of the devices

However, in view of communication there tends to be some confusion from time to time. Hence my inspiration for this blog post. So let’s have a closer look.

Let’s start with the most basic but also less frequent scenario: Direct Scep with a Static Challenge.

First of all, why less frequent, well chances are slim that your security team or SCEP admin will like this strategy very much as using a Static Challenge is maybe not the best choice in view of best practise for this kind of purpose. Nevertheless the option is available so let’s have a look at the communication flow.

When you create a configuration profile in Jamf Pro to use a Static Challenge, without putting Jamf Pro as a Proxy in between, your profile payload would basically look similar to this:

The most important field in view of our topic here would be the Static Challenge which you put in the profile. This challenge would be provided by the SCEP admin and is hard coded in the profile. What happens next is that, when you push this profile to your devices, the profile includes all information to allow the device to request a certificate directly from the SCEP/NDES server.

The profile is installed on the device, the device contacts the SCEP server and provides the static challenge it received in the profile to request a certificate.

This means that your devices need to be able to contact the SCEP/NDES server, which could be problematic if this SCEP server is behind a Firewall. If the devices are already on the internal network, or if the SCEP server URL is publicly available, this would not be a problem, but if not, you may find yourself in a situation where your devices need the certificate to connect to the internal network first (802.1x or VPN) before even being able to reach the SCEP server.

In this case the certificate request would obviously fail:

The order at which things happen in the above scenario is as follows:

  • Jamf Pro pushes the configuration profile containing the Static Challenge to the devices.
  • The device generates a CSR and sends it to the SCEP server. The private key stays on the device.
  • The SCEP server responds with a device certificate.

The above scenario with direct SCEP requests with Static Challenges makes sense I guess, however, things get a little more complicated when we use a Dynamic Challenge with configuration profiles in Jamf Pro. As far as I know MDM does not allow devices to be configured to request a dynamic challenge, so this is why it is actually Jamf Pro which does that on behalf of the devices, regardless of whether Jamf Pro is acting as a SCEP Proxy or not!

This is one of the main sources of confusion I see regularly popping up when troubleshooting SCEP issues, so lets clarify this.

Whenever you use a Dynamic Challenge in a configuration profile the order at which things happen is as follows:

  • Jamf Pro server makes standard authenticated HTTPS GET request to Dynamic Microsoft CA URL with data contained in SCEP Payload. 
  • The SCEP/ NDES server responds with challengePassword. Just like if you would manually navigate to the SCEP admin URL of your SCEP server:
  • Jamf Pro builds a unique profile with challenge password obtained from the SCEP/NDES server (as per example above: 7F58B07908B558BB)
  • Jamf Pro delivers profile to the device via MDM.
Note: Depending the settings of the SCEP/NDES server there is a limit of simultaneous challenge passwords which can remain pending. MS NDES defaults to 5, which remain valid for 60 minutes (can be changed). This means that if the maximum of pending challenges is reached, without the certs being issues (unique challenge used), additional challenge requests will be blocked until the oldest challenge expires, one of the pending challenges is used to issue a cert or in case of MS NDES, IIS is restarted.

This is an important thing to remember in view of the device communication (see below)
  • Once the profile is installed on the device (containing the unique challenge) it generates CSR and sends it to the SCEP server. The private key stays on the device.
  • The SCEP server responds with a device certificate.

In a flowchart this would look like this:

However, in contrast to our scenario with static challenges, we now have 2 elements in the flow which need to be able to reach out to the SCEP/NDES server:

  • Jamf Pro to get a Dynamic Challenge (unlike our scenario with a Static Challenge – hard coded in the profile, Jamf Pro needs to get this challenge first in order to be able to generate a unique profile for each device)
  • The devices to request their certificate

If either Jamf Pro or the devices can not reach the SCEP/NDES server, the certificate request will fail or the profile will remain pending (and loop):

The fact that Jamf Pro needs to be able to talk to the SCEP/NDES server is specifically important in case your Jamf Pro server is hosted in JamfCloud (or any other cloud service) while your SCEP/NDES server is hosted internally behind your Firewall !

This is regularly a point of confusion as sometimes I see (failing) configurations where either the SCEP URL or the SCEP admin URL is not reachable from either the devices or JamfCloud respectively.

In general the base FQDN would be the same for both, but important is that Jamf Pro (JamfCloud) needs to be able to contact the SCEP Admin URL to get the challenges!

Now, as discussed in the above scenarios of Direct SCEP, Jamf Pro and/or the devices need to be able to contact the SCEP/NDES server. As a summary so far we have:

Static Challenge: Only the devices need to be able to contact the SCEP server

Dynamic Challenge: Both Jamf Pro and the devices need to be able to contact the SCEP server

But what if you know the devices will not be able to contact the SCEP server as it is hosted internally, behind a Firewall, and the devices need a certificate from SCEP to join the internal network (802.1x or VPN) ?

Chicking or egg situation right? (Sidenote: the egg was first, because dinosaurs already legged eggs and chickens evolved from dinosaurs… )

That brings us to Jamf as SCEP Proxy!

In the PKI settings of Jamf Pro we can configure Jamf Pro to act as a proxy for SCEP, and provide the details like SCEP URL and Challenge type. Here again you can opt for either Static or Dynamic challenge. See flowcharts below for the flow or actions.

The purpose of this feature is to eliminate the requirement for devices to be able to contact the SCEP/NDES server, which changes the order of actions to provide a certificate to your devices as follows:

  • In the configuration profile you select Use the External Certificate Authority settings to enable Jamf Pro as SCEP proxy for this configuration profile

As you can see you don’t need to provide any SCEP URL or challenge type anymore, as these have been defined already in the Jamf Pro PKI settings. Only the Certificate Subject and other specific settings like SAN, redistribution and retry logic need to be configured.

  • When you push the profile to your devices, Jamf Pro will first deliver the profile to the device, in order to instruct the device to create a Certificate Signing Request. As it is Jamf Pro which will request the certificate on behalf of the device (compared to Direct SCEP without Jamf Pro as Proxy, where it is the device requesting the certificate), Jamf Pro needs a CSR to do so.
  • The devices generates a CSR and sends it to Jamf Pro. The private key stays on the device.
  • If the challenge type has been set to Static (PKI settings in Jamf Pro), Jamf Pro proceeds with submitting the CSR to the SCEP/NDES server, gets the cert and delivers it to the device via MDM.
  • If the challenge type has been set to Dynamic (PKI settings in Jamf Pro), Jamf Pro will first get a Dynamic Challenge before submitting the CSR to the SCEP server

Static Challenge with Jamf Pro as proxy:

Here we need to make sure Jamf Pro can reach the SCEP/NDES server to request the certificate:

Dynamic Challenge with Jamf Pro as proxy:

Taking all the above into consideration we can summarise the requirements for the communication with the SCEP/NDES server as follows:

DIRECT SCEP (Jamf not acting as Proxy):

  • STATIC CHALLENGE: all devices, regardless of their location need to be able to contact the SCEP/NDES server
  • DYNAMIC CHALLENGE: all devices AND Jamf Pro need to be able to contact the SCEP/NDES server

JAMF PRO ACTING AS SCEP PROXY (configured in the PKI settings of Jamf Pro and enabled in the configuration profile):

ONLY Jamf Pro needs to be able to contact the SCEP/NDES server

If both your SCEP as your Jamf Pro server are hosted on-premise I’ll leave the discussion on the network design to you and your network admin, but if you are using JamfCloud, have a look at the required IP addresses you need to allow access from to your SCEP server: https://www.jamf.com/jamf-nation/articles/409/permitting-inbound-outbound-traffic-with-jamf-cloud

Oh, and maybe stating the obvious, but the SCEP URL’s you put in any of the above configurations where JamfCloud needs access to your SCEP server, need to be a publicly reachable and resolvable FQDN. For on-premise an FQDN resolvable from your Jamf Pro server, subject to your DNS settings.

That’s it! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG