Jamf Pro: migrate the Tomcat TLS certificate without disrupting MDM

Article created October 10, 2026 · Source reviewed October 10, 2026 · Official source: Jamf Pro 11.32 · Topic: Jamf, TLS, PKI, and MDM continuity

Jamf has announced that Jamf Pro will eventually stop issuing the Tomcat TLS server certificate from its built-in certificate authority. Self-hosted instances still using this mechanism should move to a publicly trusted third-party CA—or, where necessary, a properly distributed internal PKI—to avoid a potential loss of MDM communication with Apple devices.

1. What Jamf has announced

The official Jamf Pro 11.32 Deprecations and Removals section says that issuing the Tomcat TLS certificate from the built-in JSS CA will be discontinued. Jamf also says the release version for this change has not been determined. Inventing a deadline would therefore be wrong, but waiting for one before discovering dependencies would also create unnecessary risk.

The change concerns the server certificate presented by Jamf Pro. Jamf says the built-in CA will retain its existing ability to issue server certificates manually for other servers, so the notice does not announce the complete removal of that authority.

2. Why the Tomcat certificate affects Apple MDM

The TLS certificate protects the identity and encryption of the Jamf Pro service used by browsers, integrations, and devices. An expired certificate, incomplete chain, missing DNS name, or untrusted authority can interrupt core operations including enrollment, inventory, commands, profiles, and console access.

This certificate is distinct from the Apple Push certificate, Apple Business Manager tokens, SCEP certificates, and identities deployed to devices. Each has a different purpose and lifecycle. The TLS migration should preserve all of them rather than trigger unrelated renewals.

3. What does this change for a Belgian or French organization?

A small business using Jamf Cloud should mainly confirm who owns certificate responsibility with its provider. An organization running Jamf Pro on its own infrastructure must identify the CA, DNS owner, key vault, renewal process, and teams able to intervene outside normal working hours.

For a mid-sized company, large enterprise, or public institution operating in Belgium, France, or elsewhere in Europe, responsibility is often split between Apple, network, security, PKI, and hosting teams. The required evidence goes beyond a browser padlock: it should cover the presented chain, pilot devices, API integrations, proxies or load balancers, and expiry monitoring.

4. Underside analysis: treat TLS as a zero-touch dependency

Our view is that the Jamf Pro certificate belongs on the critical Apple deployment path. Apple Business Manager and Automated Device Enrollment may assign a Mac, iPhone, or iPad correctly; if the MDM service can no longer be reached with a valid TLS identity, the zero-touch journey still stops.

The migration should therefore be connected to existing controls for TLS, ATS, and certificates across Apple services and the Apple Business Manager deployment foundation. The useful measure is not “certificate installed,” but “MDM chain tested before and after cutover.”

5. Recommended migration plan

• Confirm whether the instance is self-hosted and whether Tomcat uses a certificate issued by the built-in Jamf Pro CA.
• Inventory the FQDN, SANs, intermediate chain, expiry, algorithms, key location, and any upstream TLS termination.
• Choose a publicly trusted CA; reserve an internal PKI for controlled cases where trust reaches every relevant client and integration.
• Test the certificate and chain on staging or during a controlled window, with a backup and rollback procedure.
• Validate the console, APIs, Automated Device Enrollment, inventory, and an MDM command on representative Macs, iPhones, and iPads.
• Monitor expiry, TLS errors, and availability, then document ownership, renewal, and escalation.

Official source: Jamf Pro 11.32 — Deprecations and Removals, accessed and reviewed October 10, 2026.