Retour au blog

Jamf Pro : migrer le certificat TLS Tomcat sans couper le MDM

Article créé le 10 octobre 2026 · Source analysée le 10 octobre 2026 · Source officielle : Jamf Pro 11.32 · Thème : Jamf, TLS, PKI et continuité MDM

Jamf annonce que Jamf Pro n’émettra plus, à terme, le certificat serveur TLS de Tomcat depuis son autorité de certification intégrée. Les instances auto-hébergées qui utilisent encore ce mécanisme doivent passer à une autorité tierce publiquement approuvée — ou, si nécessaire, à une PKI interne correctement distribuée — afin d’éviter une perte potentielle de communication MDM avec les appareils Apple.

1. Ce que Jamf annonce précisément

La section officielle Deprecations and Removals de Jamf Pro 11.32 indique que la fonction d’émission du certificat TLS Tomcat par l’autorité intégrée du JSS sera abandonnée. Jamf précise qu’aucune version de retrait n’est encore déterminée. Il serait donc incorrect d’inventer une échéance, mais tout aussi risqué d’attendre qu’elle soit annoncée pour découvrir les dépendances.

Le changement concerne le certificat serveur présenté par Jamf Pro. Jamf indique que son autorité intégrée conservera sa capacité actuelle à émettre manuellement des certificats serveur pour d’autres serveurs : l’annonce ne signifie donc pas la disparition complète de cette autorité.

2. Pourquoi le certificat Tomcat touche le MDM Apple

Le certificat TLS protège l’identité et le chiffrement du service Jamf Pro auquel se connectent navigateurs, intégrations et appareils. Un certificat expiré, une chaîne incomplète, un nom DNS absent ou une autorité non approuvée peut interrompre des échanges au cœur de l’exploitation : enrôlement, inventaire, commandes, profils et accès à la console.

Ce certificat ne doit pas être confondu avec le certificat Push Apple, les jetons Apple Business Manager, les certificats SCEP ou les identités déployées aux terminaux. Ils ont des rôles et des calendriers distincts. La migration TLS doit préserver chacun de ces éléments sans les renouveler inutilement.

3. Qu’est-ce que cela change pour une entreprise belge ou française ?

Une PME qui utilise Jamf Cloud devra surtout confirmer avec son fournisseur qui porte la responsabilité du certificat. Une organisation qui exploite Jamf Pro sur sa propre infrastructure doit, elle, identifier l’autorité, le propriétaire du DNS, le coffre de clés, le processus de renouvellement et les équipes capables d’intervenir hors heures ouvrées.

Pour une ETI, une grande entreprise ou une administration en Belgique, en France ou ailleurs en Europe, la difficulté vient souvent des responsabilités partagées entre équipe Apple, réseau, sécurité, PKI et hébergement. La preuve attendue n’est pas seulement un cadenas dans le navigateur : elle doit couvrir la chaîne présentée, les appareils pilotes, les intégrations API, les proxys ou répartiteurs de charge et la supervision de l’expiration.

4. Lecture Underside : traiter TLS comme une dépendance du zero-touch

Notre lecture est que le certificat Jamf Pro appartient au chemin critique du déploiement Apple. Apple Business Manager et Automated Device Enrollment peuvent attribuer correctement un Mac, un iPhone ou un iPad ; si le service MDM n’est plus joignable avec une identité TLS valide, le parcours zero-touch reste bloqué.

Cette migration doit donc être reliée aux contrôles de TLS, ATS et certificats pour les services Apple et au socle Apple Business Manager du déploiement. Le bon indicateur n’est pas « certificat installé », mais « chaîne MDM testée avant et après le basculement ».

5. Plan de migration recommandé

Objectif : remplacer le mécanisme d’émission avant son retrait, sans toucher inutilement aux autres certificats Apple ni interrompre l’enrôlement et la gestion du parc.

Auditer votre chaîne TLS Jamf

Source officielle : Jamf Pro 11.32 — Deprecations and Removals, consultée et analysée le 10 octobre 2026.