L’essentiel en 2 minutes

Le problème

Depuis iOS 27, l’enrôlement BYOD Intune « account-driven » échoue si le serveur web de votre domaine n’a pas un TLS conforme aux nouvelles exigences d’Apple. L’utilisateur voit ce message dès qu’il ajoute son compte professionnel :

Les iPhone déjà enrôlés ne sont pas touchés : seuls les nouveaux enrôlements, ou ceux refaits sous iOS 27, sont bloqués. La cause n’est ni Intune ni le compte Apple, mais votre serveur web, celui qui publie https://<votre-domaine>/.well-known/com.apple.remotemanagement.

La correction en 5 étapes

1. Identifier le serveur. Prenez le domaine des adresses de vos utilisateurs (la partie après le @) : c’est le serveur qui répond sur https://domaine/.well-known/com.apple.remotemanagement, souvent le site vitrine ou un reverse proxy.
2. L’auditer depuis n’importe quel Linux, Git Bash ou WSL, avec audit_intune_ios.sh :
   Shell

   ./audit_intune_ios.sh votre-domaine.fr

3. Vérifier que le serveur web est à jour. L’Extended Master Secret ne s’active par aucune directive : il est fourni par la bibliothèque TLS. Le serveur doit donc être lié à OpenSSL 1.1.1 ou plus (1.1.0 au strict minimum), ce qui donne aussi TLS 1.3.

   Logiciel	Version minimale	Distributions qui l’ont d’origine
   OpenSSL	1.1.1	RHEL / Rocky / Alma 8+, Debian 10+, Ubuntu 20.04+
   Apache httpd	2.4.37	idem
   nginx	1.13	idem
   HAProxy	2.x	idem

   Bibliothèque réellement utilisée par le serveur

   ldd "$(find / -name mod_ssl.so 2>/dev/null | head -1)" | grep libssl   # Apache : libssl.so.1.1 ou .so.3
   nginx -V 2>&1 | grep -i openssl                                      # nginx
   haproxy -vv | grep -i "openssl"                                       # HAProxy

   Bloqué sur CentOS / RHEL 7 (OpenSSL 1.0.2) ? Migrez l’OS, placez un proxy TLS récent devant, ou recompilez le serveur web avec OpenSSL 1.1.1 (détails). C’est cette dernière option que nous avons retenue : Apache 2.4.69 compilé avec OpenSSL 1.1.1k.
4. Forcer les protocoles et les suites : TLS 1.2 et 1.3 uniquement, suites ECDHE + AES-GCM. Configuration express, identique à celle de notre serveur en production :
   Apache (ssl.conf, hors <VirtualHost>, et dans <VirtualHost _default_:443>)

   SSLProtocol          -all +TLSv1.2 +TLSv1.3
   SSLCipherSuite       ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
   SSLHonorCipherOrder  on

   nginx (bloc http ou server)

   ssl_protocols             TLSv1.2 TLSv1.3;
   ssl_ciphers               ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
   ssl_prefer_server_ciphers on;

   HAProxy (section global)

   ssl-default-bind-options       ssl-min-ver TLSv1.2
   ssl-default-bind-ciphers       ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
   ssl-default-bind-ciphersuites  TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

   Puis rechargez le service : httpd -t && systemctl reload httpd, nginx -t && systemctl reload nginx ou haproxy -c -f /etc/haproxy/haproxy.cfg && systemctl reload haproxy.
5. Valider : relancer l’audit (0 échec), puis nscurl --ats-diagnostics depuis un Mac, et un vrai enrôlement sur un iPhone en iOS 27.

Exemple d’audit : avant et après

Avant : un serveur non conforme

Audit d’un serveur web encore lié à un OpenSSL ancien (domaine et certificat masqués). Les protocoles, les suites et le certificat sont bons, mais l’audit échoue :

• section 2 : TLS 1.3 non proposé, une alerte qui trahit déjà un OpenSSL ancien ;
• section 4 : Extended Master Secret ABSENT et la simulation du client Apple échoue « sans EMS » : un iPhone en iOS 27 refusera la connexion ;
• section 6 : le fichier de découverte, lui, est correct. Il ne sera simplement jamais lu par l’iPhone ;
• synthèse : 15 PASS, 1 WARN, 2 FAIL, « Non conforme aux exigences iOS 27 ». Remède : étape 3 ci-dessus, mettre à jour la pile TLS.

Après : un serveur conforme, microsoft.com

Microsoft utilise lui-même l’enrôlement BYOD account-driven pour ses employés. Son domaine passe l’audit :

• sections 2 à 5 : TLS 1.3 proposé, EMS négocié, simulation du client Apple réussie, certificat conforme ;
• section 6 : le fichier est d’abord redirigé vers www.microsoft.com, seule alerte de l’audit. Le script suit la redirection, vérifie le TLS de l’hôte de destination puis lit le JSON : version mdm-byod et BaseURL Intune manage-beta, l’anneau de pré-production sur lequel Microsoft teste Intune en interne ;
• synthèse : 19 PASS, 1 WARN, 0 FAIL, conforme aux exigences iOS 27.

La suite de l’article détaille le problème (partie 1), puis la remédiation et l’audit (partie 2).

Ce qui change avec iOS 27

À partir de la version 27 d’iOS, iPadOS, macOS, watchOS, tvOS et visionOS, Apple applique des règles TLS strictes (ATS et FCP v2.1) aux connexions système liées à la gestion des appareils : MDM, Declarative Device Management, Automated Device Enrollment, installation de profils, distribution d’apps et mises à jour logicielles.

Le symptôme côté utilisateur : dans Réglages > Général > VPN et gestion de l’appareil, il touche « Se connecter avec un compte professionnel ou scolaire », saisit son adresse et obtient immédiatement le message « Sign-in Failed » présenté plus haut. Le message parle du compte Apple, mais la cause est côté serveur : l’iPhone n’a même pas pu lire le fichier de découverte.

Point important pour le diagnostic : les appareils déjà enrôlés avant la mise à jour ne sont pas touchés, même une fois passés en iOS 27. Seuls les nouveaux enrôlements, ou ceux refaits sous iOS 27, échouent. L’incident peut donc passer inaperçu plusieurs semaines.

Les types d’enrôlement iOS dans Intune

Intune propose huit façons de prendre en charge un iPhone ou un iPad. Elles se répartissent entre appareils personnels (BYOD) et appareils d’entreprise, et une seule d’entre elles passe par le site web de votre organisation : l’enrôlement utilisateur account-driven. C’est elle que concerne cet article.

Sources : CloudTek Space, Different types of iOS/iPadOS enrollment in Intune · Microsoft Learn, account-driven User Enrollment.

Périmètre : le BYOD account-driven

Comme le montre la section précédente, seul l’enrôlement utilisateur account-driven lit le fichier de découverte sur votre domaine. Les autres modes, personnels comme professionnels, contactent directement les services Microsoft, conformes et gérés par Microsoft. Les appareils déjà enrôlés avant iOS 27 ne sont pas touchés.

Le fichier de découverte, à quoi sert-il ?

En BYOD account-driven, l’iPhone ne connaît pas encore votre MDM. Il le découvre à partir du domaine de l’adresse saisie : pour prenom.nom@example.com, il lit https://example.com/.well-known/com.apple.remotemanagement. Ce petit fichier JSON lui indique quel MDM contacter et à quelle adresse. Pour Intune, il a cette forme (documentation Microsoft) :

{"Servers":[{"Version":"mdm-byod","BaseURL":"https://manage.microsoft.com/EnrollmentServer/PostReportDeviceInfoForUEV2?aadTenantId=<ID-du-tenant-Entra>"}]}

Ce fichier est souvent servi par le site vitrine ou un reverse proxy, géré par une autre équipe ou un prestataire. Si ce serveur échoue au contrôle TLS d’iOS 27, l’iPhone s’arrête à cette première étape, avant même d’atteindre Intune.

Ce que montrent les logs du serveur web

Le journal d’accès du serveur qui publie le fichier de découverte est le meilleur témoin, avant et après la correction.

Avant la correction, il ne contient aucune ligne pour les iPhone en iOS 27 : la négociation TLS échoue avant toute requête HTTP, donc rien n’arrive jusqu’au journal d’accès. C’est ce qui rend l’incident si discret côté serveur. Pour voir ces échecs, il faut passer temporairement le journal d’erreurs en LogLevel ssl:info (Apache).

Après la correction, chaque tentative d’enrôlement laisse une trace (adresse et identifiant anonymisés) :

203.0.113.24 - - [04/Oct/2026:17:36:12 +0200] "GET /.well-known/com.apple.remotemanagement?user-identifier=prenom.nom@example.com&model-family=iPhone HTTP/1.1" 200 360
203.0.113.24 - - [04/Oct/2026:18:56:51 +0200] "GET /.well-known/com.apple.remotemanagement?user-identifier=prenom.nom@example.com&model-family=iPhone HTTP/1.1" 200 360

Ces lignes servent à trois choses : confirmer que la correction fonctionne, suivre l’adoption du BYOD, et diagnostiquer un utilisateur bloqué.

# Dernières tentatives
grep -h "com.apple.remotemanagement" /var/log/httpd/*access_log* | tail -20

# Suivi en direct pendant un test
tail -f /var/log/httpd/ssl_access_log | grep --line-buffered "remotemanagement"

# Tentatives par jour
grep -h "com.apple.remotemanagement" /var/log/httpd/*access_log* | awk '{print substr($4,2,11)}' | sort | uniq -c

# Utilisateurs distincts
grep -ho "user-identifier=[^& ]*" /var/log/httpd/*access_log* | sort -u

Ces journaux contiennent des adresses professionnelles nominatives : appliquez-leur votre durée de conservation habituelle (RGPD).

Les exigences Apple

Apple n’invente pas ces règles : il applique aux connexions de gestion des appareils deux référentiels qu’il utilisait déjà ailleurs. App Transport Security (ATS) est la politique TLS imposée depuis des années aux applications iOS : TLS 1.2 minimum, confidentialité persistante, certificats solides. Le Functional Package for TLS 2.1 (FCP v2.1) vient du NIAP, l’organisme américain de certification des produits de sécurité : il ajoute notamment les suites AES-GCM uniquement et l’Extended Master Secret. Depuis iOS 27, un appareil Apple exige les deux pour le MDM, l’enrôlement, les profils, les apps et les mises à jour.

Exceptions prévues par Apple : les serveurs SCEP et les serveurs de mise en cache de contenu ne sont pas concernés.

Le piège : l’Extended Master Secret

Ce que c’est

Lors d’une connexion TLS 1.2, le client et le serveur calculent un secret commun, le master secret, d’où sont tirées toutes les clés de chiffrement de la session. Dans la version d’origine du protocole, ce secret dépend seulement de trois éléments : le secret échangé pendant la négociation et deux nombres aléatoires, l’un choisi par le client, l’autre par le serveur.

En 2014, des chercheurs ont montré avec l’attaque « Triple Handshake » qu’un serveur malveillant pouvait s’interposer et faire en sorte que deux connexions distinctes, l’une avec lui, l’autre avec le vrai serveur, partagent le même master secret. Combiné à la reprise de session et à la renégociation, cela permettait d’usurper l’identité d’un client, y compris authentifié par certificat.

L’Extended Master Secret, défini par la RFC 7627 en 2015, corrige ce défaut : le master secret est calculé à partir d’une empreinte (hash) de tous les messages de la négociation. Deux connexions différentes ne peuvent plus aboutir au même secret, car leurs négociations diffèrent forcément. Concrètement, le client annonce l’extension extended_master_secret dans son premier message, et le serveur l’accepte en la renvoyant dans sa réponse.

L’EMS ne concerne donc que TLS 1.2. Un serveur qui négocie TLS 1.3 est protégé par construction. Mais un iPhone peut se replier en TLS 1.2, et le serveur doit alors accepter l’EMS.

Pourquoi on ne peut pas le « configurer »

Restreindre les protocoles et les suites se fait en deux lignes de configuration. L’EMS, lui, est implémenté dans la bibliothèque TLS : il est activé automatiquement à partir d’OpenSSL 1.1.0, sans aucune directive. Si votre serveur web est lié à un OpenSSL plus ancien, rien dans sa configuration ne le fera apparaître. Il faut changer la bibliothèque, donc la version du serveur ou de l’OS.

Pour vérifier depuis n’importe quel poste avec OpenSSL 1.1.1 ou plus :

openssl s_client -connect example.com:443 -servername example.com -tls1_2 \
  </dev/null 2>/dev/null | grep "Extended master secret"
# Extended master secret: yes   -> conforme
# Extended master secret: no    -> bloquant pour iOS 27

Vérifier la bibliothèque réellement utilisée par le serveur, et non celle de la commande openssl du système :

nginx -V 2>&1 | grep -i openssl                  # nginx : "built with OpenSSL ..."
haproxy -vv | grep -i "openssl"                     # HAProxy : "Running on OpenSSL ..."
ldd $(find / -name mod_ssl.so 2>/dev/null | head -1) | grep libssl   # Apache : libssl.so.1.1 ou .so.3 = OK

Versions minimales et configuration

SSLProtocol          -all +TLSv1.2 +TLSv1.3
SSLCipherSuite       ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder  on
SSLCompression       off
SSLSessionTickets    off

ssl_protocols             TLSv1.2 TLSv1.3;
ssl_ciphers               ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_session_tickets       off;

ssl-default-bind-options       ssl-min-ver TLSv1.2 no-tls-tickets
ssl-default-bind-ciphers       ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
ssl-default-bind-ciphersuites  TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

Et si le serveur est bloqué sur un vieil OpenSSL ?

C’était mon cas : un reverse proxy Apache 2.4.6 sous CentOS 7, lié à OpenSSL 1.0.2k. Après durcissement, tout était vert sauf l’EMS. Trois options :

1. Migrer vers une distribution récente (Rocky/Alma 9, Debian 12…). La solution propre.
2. Placer un reverse proxy récent devant (HAProxy, nginx), sur la même machine ou une autre. Le backend ne change pas.
3. Compiler Apache récent contre OpenSSL 1.1.1 dans /opt, en reprenant la configuration existante. C’est la voie que j’ai choisie pour ne pas toucher à l’architecture, avec une instance de test en parallèle avant bascule et un retour arrière prêt.

Point d’attention si vous compilez : un autre OpenSSL présent dans /usr/local peut être pris pour les en-têtes alors que l’édition de liens utilise celui du système. Forcez CPPFLAGS et LDFLAGS vers le même OpenSSL.

Tester et valider

1. En une ligne avec OpenSSL

openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_2 </dev/null 2>/dev/null \
  | grep -E "Cipher is|Extended master secret|Verify return code"

Attendu : une suite ECDHE-…-GCM-…, Extended master secret: yes et Verify return code: 0. Pensez à -servername : sans lui, vous testez le vhost par défaut, pas votre site.

2. SSL Labs

SSL Labs donne une vue d’ensemble rapide depuis l’extérieur (cochez « Do not show the results on the boards »). À vérifier :

• Protocols : TLS 1.3 et 1.2 à Yes, TLS 1.1 et 1.0 à No.
• Cipher Suites : en TLS 1.2, uniquement des suites ECDHE avec GCM.
• Certificate : chaîne complète, clé et signature conformes.
• Handshake Simulation : les clients Apple récents doivent passer en TLS 1.3.

Les lignes marquées d’un astérisque concernent les clients sans SNI : elles ne reflètent pas ce que voit un iPhone. Pour l’EMS, fiez-vous à OpenSSL ou au script ci-dessous.

3. Le script d’audit

audit_intune_ios.sh fonctionne sur n’importe quel Linux (et macOS avec un OpenSSL Homebrew). Il est en lecture seule et peut viser un serveur distant : lancez-le depuis un serveur qui voit la cible.

chmod +x audit_intune_ios.sh
./audit_intune_ios.sh example.com                     # domaine de connexion (après le @)
./audit_intune_ios.sh 10.0.0.12 443 example.com       # IP interne, nom public en SNI
OPENSSL=/usr/bin/openssl11 ./audit_intune_ios.sh example.com   # client OpenSSL spécifique

Il contrôle les versions de protocole, énumère les suites TLS 1.2 acceptées, vérifie l’EMS, simule un client Apple en mode FCP v2.1, analyse le certificat, puis lit le fichier de découverte /.well-known/com.apple.remotemanagement : version mdm-byod, BaseURL Intune et, à titre informatif, TLS du service Microsoft. La section 6 du script, « Fichier de découverte Intune (BYOD account-driven) », vérifie que le fichier est présent en HTTP 200 (en cas de redirection, elle suit la chaîne et contrôle aussi le TLS de l’hôte de destination), servi en application/json, qu’il déclare la version mdm-byod (sans elle, l’enrôlement BYOD n’est pas proposé) et que sa BaseURL pointe en HTTPS vers Intune. À titre informatif, elle contrôle aussi le TLS du service Microsoft. Le script se termine par un récapitulatif exigence par exigence :

=== 7. Exigences Apple iOS 27 (support.apple.com/126655) ===
  Statut  Exigence                                             Niveau
  OK      TLS 1.2 accepté                                      obligatoire
  OK      SSLv3 / TLS 1.0 / TLS 1.1 refusés                    obligatoire
  OK      Suites ECDHE + AES-GCM (SHA-256/384) en TLS 1.2      obligatoire
  OK      Extended Master Secret (RFC 7627) en TLS 1.2         obligatoire
  OK      Signature du handshake SHA-256+ (pas SHA-1)          obligatoire
  OK      Certificat signé en SHA-256+                         obligatoire
  OK      Clé RSA >= 2048 bits ou ECDSA >= 256 bits            obligatoire
  OK      Certificat en cours de validité                      obligatoire
  OK      Extension SAN (nom du serveur)                       obligatoire
  OK      Chaîne de confiance reconnue par l'appareil          obligatoire
  OK      Connexion d'un client Apple FCP v2.1 simulé          synthèse
  OK      TLS 1.3 proposé                                      recommandé
  ALERTE  Aucune suite hors liste Apple acceptée               durcissement
  OK      Fichier de découverte Intune valide                  BYOD Intune

Une suite acceptée hors liste Apple (DHE, CHACHA20, CBC…) apparaît en alerte et non en échec : un appareil Apple ne la propose pas, elle ne sera jamais négociée avec lui. La retirer reste du bon durcissement. Code retour 0 si conforme, 1 sinon : le script peut servir dans une supervision.

4. La validation Apple

nscurl --ats-diagnostics https://www.example.com/.well-known/com.apple.remotemanagement

Cherchez le test « FCP_v2.1 » : il doit afficher PASS. Enfin, faites un vrai enrôlement sur un appareil en iOS 27. Un iPhone en iOS 26 s’enrôlera même face à un serveur non conforme : il ne prouve rien.

En résumé

1. Identifier tous les serveurs touchés par le MDM, en commençant par celui qui sert /.well-known/com.apple.remotemanagement.
2. Limiter à TLS 1.2 et 1.3, et aux suites ECDHE + AES-GCM.
3. Vérifier que le serveur est lié à OpenSSL 1.1.0 ou plus, sinon l’EMS manquera.
4. Auditer, puis valider avec nscurl et un enrôlement réel sous iOS 27.