Extending Jamf Connect ZTNA with Apple’s Network Relay and Device Attestation
Intro
Over the last few years, there has been a significant shift when it comes to securing company resources. We have come a long way from traditional VPNs, that after initial authentication don’t provide any further evaluation of the access rights, to the so called “next-gen VPNs” that moved us to the realm of Zero Trust Network Access (ZTNA).
Jamf Connect ZTNA (formerly known as Jamf Private Access) allows the users to connect to their company resources in a secure way, providing ZTNA capabilities across multiple platforms. However there is still this need of a client being installed on the device, to establish the Wireguard tunnel with Jamf’s Security Cloud. When Apple introduced its concept of Network Relays, we immediately recognised this as an opportunity to deliver our state of the art ZTNA capabilities on Apple devices without the need for installation of any client application. Let me describe the building blocks that allowed us to create this unique solution.
Network Relay
Apple introduced Network Relay as an alternative to traditional VPNs in iOS 17, iPadOS 17, macOS 14 and tvOS 17. Network Relay is a new type of proxy that relies on the MASQUE protocol, that allows tunnelling of any TCP and UDP traffic. Network Relays are built into the network stack of the Apple operating systems which means that they require no further installation of additional apps on device.
A relay can be configured via a “Relay” MDM configuration payload, which is aligned with configuration of other device features. The Network Relay functionality plays nicely with two other technologies supported by Apple devices since version 16 of their OS’s — Managed Device Attestation (MDA) and Automated Certificate Management Environment (ACME).
ACME and MDA
Apple introduced MDA and ACME protocol support in iOS 16, iPadOS 16, and tvOS 16 to enhance device security in enterprise and educational environments. MDA leverages cryptographically signed attestations, backed by Apple’s Secure Enclave, to verify device authenticity and properties, ensuring devices are genuine and secure. The integration of the ACME protocol allows managed devices to obtain client certificates tied to hardware-bound keys, enabling strong proof of device identity across an organization’s infrastructure. ACME itself simplifies the flow of issuing the certificates by automating the whole process, reducing need of manual intervention, making it less error prone and more scaleable. Together, these features strengthen zero-trust architectures by providing verifiable device identities for secure resource access and management.
There are already visible touch points between the technology introduced by Apple and capabilities of Jamf Connect ZTNA solution. Jamf already provides a ZTNA solution with robust policy evaluation framework and access control. In addition to that, Jamf Pro MDM allows the customer to easily configure the device fleet with all the data that is necessary to:
- Go through the certificate issuing process.
- Establish a tunnel to Jamf Security Cloud endpoint via Network Relay.
Let’s dive deeper into the details of how these parts play together in Jamf ecosystem.
ACME, MDA and Network Relay in Jamf Security Cloud (JSC)
In the Jamf environment, we decided to tie these 3 technologies together in a way that allows only genuine Apple devices that are enrolled in JSC to obtain the certificate from ACME server. This certificate is then used to authenticate the device against our Network Relay server. However this alone doesn’t give the device access to company resources. First of all, only devices managed by Jamf Pro MDM can pass the just-in-time enrolment process upon first request through Network Relay server. Jamf Security Cloud policy engine then comes into play to verify that the domain that has been requested is actually allowed for this specific device.
To go into more detail, let’s break the whole process down into smaller pieces:
- As first step, a management profile containing both ACME and Network Relay payload needs to be pushed down to device — this allows us to make sure that the certificate obtained from ACME server will be then used to authenticate against the Jamf’s Network Relays server (through the `PayloadCertificateUUID` field in Network Relay config).
- Upon the management profile installation, the device will contact the Jamf ACME server, which will in turn verify that this device really belongs to an active JSC tenant. After this initial step the ACME server will ask the device for proof that it is really a genuine Apple device (challenging the device with the device-attest-01 challenge)
- To fulfil this challenge, the device will contact the Apple’s Managed Device Attestation server, which (in case this is a genuine Apple device) will respond with attestation payload signed by Apple’s CA. This payload is then provided to Jamf’s ACME server.
- In the last step, Jamf’s ACME server will issue a certificate, signed by Jamf’s CA. Along with all the information provided by the device during the attestation process, the device’s UDID and Serial number are also incorporated into the issued certificate. This certificate can be then used to authenticate the subsequent requests against the Jamf’s Network Relay server, which can then perform more granular access control based on the verified device identity and request context.
The following diagram captures all the components involved in this process from high-level.
ACME implementation and deployment
Building your own ACME server requires some heavy lifting. This is why we decided to go with a solution based on an open-source implementation of ACME server with support of device-attest-01 challenge — Smallstep’s step-ca server. It has active community of maintainers, and is written in Golang, which makes it easy for our developers to extend and maintain.
Our ACME server is deployed to AWS EKS that guarantees performance and scalability of the whole system. For signing of issued certificate we are using AWS KMS as it allows great control over our cryptographic keys. Its integration with AWS CloudTrail also allows auditability of who used the keys and for what purpose. To ensure high availability during deployments of new version of Jamf’s ACME server, the step-ca server is backed by PostreSQL DB running in AWS RDS.
Summary
With the addition of support of ACME and Network Relay to Jamf’s cloud hosted ZTNA platform, we have extended the possibilities for how Apple devices can securely reach company resources. The ACME server significantly simplifies the certificate creation flow. By using the technologies natively supported by Apple OS’s, ZTNA can be deployed without needing an agent or app to be installed on the end user device, reducing friction during the rollout of ZTNA and opening up new use cases to our customers. The security guarantees provided by the Apple Secure Enclave’s hardware-bound keys and Managed Device Attestation further elevate the robustness and security provided by the ZTNA platform, to deliver a market leading Zero Trust solution.
Credits
Special thanks to Ondřej Benkovský and Sven Relovský for their relentless work on ACME server tech design and review of this article.
Disclaimer: The functionality is currently in Public Beta and available for Jamf Connect customers to sign up through their Jamf Account. General Availability is expected in early April 2025.