Sophos Mobile : vérifier les certificats SCEP et les chemins de connexion

SCEP permet d’installer et de renouveler des certificats dans Sophos Mobile (MDM). Cette procédure traite de la connexion SCEP côté tenant et des différents chemins de communication à distinguer. Elle ne couvre pas la configuration complète d’une autorité de certification Windows, d’une infrastructure Wi-Fi/VPN ni de toutes les charges utiles des politiques Android, Apple et Windows. L’installation et le renouvellement SCEP selon cette procédure ne prennent pas en charge les Chromebooks.

Avant toute modification en production : les responsables de l’AC/PKI, du réseau et du MDM, ainsi que, le cas échéant, l’exploitant du service d’authentification Wi-Fi/VPN, déterminent ensemble les appareils et les modes d’enrôlement concernés, si et comment un service donné peut utiliser le certificat SCEP, et comment joindre les appareils en cas de perte du réseau. Ni Save ni la distribution d’une politique ne prouvent qu’un certificat client a été émis, renouvelé ou associé à un profil Wi-Fi/VPN.

Trois chemins de communication, pas une ouverture générale de ports

Sophos Fusion se connecte à votre propre AC compatible SCEP ; l’appareil géré communique séparément avec Sophos Mobile. Une authentification ultérieure auprès du service Wi-Fi/VPN avec ce même certificat SCEP n’est pas automatique : elle doit être démontrée pour chaque plateforme et chaque profil. Ici, tenant désigne votre environnement Sophos Mobile et MDM sa gestion des appareils.

Déterminer la région du tenant : dans Sophos Fusion, sous My Products > Mobile, examiner l’URL dans la barre d’adresse du navigateur. La région figure dans le premier élément du nom d’hôte, avant le premier point, directement après smc-user-if-cloudstation-. Dans l’exemple smc-user-if-cloudstation-eu-west-1, la région est eu-west-1. Pour les autorisations réseau, utiliser la région de sa propre URL de navigateur, et non la valeur de l’exemple ni un texte identique dans le chemin de l’URL ou ses paramètres de requête. La région d’hébergement est choisie lors de la création du compte Sophos Fusion ; pour les comptes existants, elle est déterminée ici à partir de l’URL réelle du navigateur. Cet hôte d’administration n’est ni un point de terminaison pour les appareils ni un serveur SCEP. La méthode de détermination de la région s’applique aussi à Mobile Threat Defense, mais ne démontre pas l’existence d’une fonction SCEP propre à MTD.
De Fusion vers vos serveurs (entrant) : la liste actuelle des IP sources régionales pour définir précisément l’autorisation de trafic entrant indique TCP 443 pour SCEP et TCP 636 pour la connexion LDAP/AD distincte. N’autoriser vers votre serveur SCEP ou AD concerné que les adresses IP sources Mobile actuellement publiées pour la région réelle du tenant. Ne pas reprendre la région utilisée comme exemple ni créer de règle entrante globale ou illimitée. La connexion LDAP/AD sert à l’authentification des utilisateurs avec leurs identifiants AD lors de l’enregistrement des appareils via Apple Business (anciennement Apple Business Manager), Google Zero-touch ou Samsung KME. Cette authentification n’est ni la première émission d’un certificat client SCEP pour un appareil géré ni son renouvellement ultérieur.
De l’appareil vers Sophos Mobile (sortant) : les appareils gérés doivent accéder en HTTPS sur le port 443 à l’hôte régional smc-device-if-cloudstation-. Les destinations complètes des appareils sont smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com pour eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com pour eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com pour us-west-2 et smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com pour us-east-2, chacune via HTTPS 443. Utiliser uniquement la destination correspondant à la région réelle du tenant déterminée au préalable ; ces destinations pour les appareils ne sont ni l’hôte d’administration ni vos propres destinations SCEP. Des connexions supplémentaires sont nécessaires pour les notifications push, l’enrôlement et d’autres fonctions propres aux plateformes. Les vérifications distinctes et les guides internes ci-dessous les précisent selon le type d’appareil et la fonction effectivement utilisée ; les quatre hôtes régionaux des appareils ne constituent pas une liste complète des destinations de trafic sortant. Ces destinations supplémentaires ne sont ni des IP sources de trafic entrant SCEP ni une liste de ports SCEP à ouvrir indistinctement.

Distinguer les autres dépendances de trafic sortant des appareils :

Notifications push Windows : pour les ordinateurs Windows, les destinations documentées pour Windows Notification Service (WNS) et Microsoft Push Notification Service (MPNS) sont *.notify.windows.com, *.wns.windows.com et *.notify.live.net, chacune via HTTPS 443. Il s’agit de connexions push Windows, et non de ports entrants SCEP.
Enrôlement et provisionnement Android : pour Android, consulter le guide Android Enterprise et, pour les prérequis QR/Zero-touch/KME, le guide de provisionnement ; l’autorisation réseau doit toujours y être vérifiée pour l’appareil et le mode concernés.
Notifications push de gestion Apple : pour la gestion des iPhone, iPad et Mac, vérifier séparément le chemin des notifications push Apple ; le guide APNs décrit l’identité du certificat, son renouvellement et la vérification de l’accessibilité disponible sur iPhone/iPad.
Informations sur les mises à jour Apple et conformité : indépendamment de ce chemin, Sophos Mobile a besoin d’informations sur les mises à jour Apple disponibles : si le service Apple prévu à cet effet n’est pas accessible, ces informations manquent et les règles de conformité imposant des mises à jour restent sans effet. Vérifier le chemin réseau de l’organisation et les limites liées à la plateforme, au système d’exploitation et au mode d’enrôlement dans le guide de conformité. Les notifications push pour la gestion Apple et les informations sur les mises à jour relèvent des exigences de trafic sortant des appareils, et non de points de terminaison entrants SCEP ou d’émission de certificats.
Trafic de l’application IXM : pour les iPhone/iPad avec Sophos Intercept X for Mobile (IXM), vérifier les connexions propres à l’application dans le guide réseau IXM ; ce guide précise les services et les ports correspondants, ainsi que les limites selon la version de l’application, l’édition, le mode de gestion et la fonction effectivement utilisée. Il ne s’agit pas de connexions entrantes SCEP ; la rubrique Apple d’une liste de connexions réseau ne permet pas de conclure qu’IXM s’applique aux Mac.

Une adresse de destination documentée ne prouve pas encore son accessibilité depuis le réseau de l’organisation.

En cas d’incident, consigner donc séparément si (a) Fusion atteint votre point de terminaison SCEP, (b) l’appareil atteint Sophos Mobile et reçoit sa politique et (c) le service Wi-Fi/VPN accepte le certificat émis. La réussite d’un de ces chemins ne dispense pas de vérifier les deux autres.

Définir au préalable les responsabilités et la confiance

Notions utiles à la décision : la PKI est l’infrastructure de certificats et l’AC, l’autorité qui les émet. SCEP demande le certificat client ; le Subject et le SAN (Subject Alternative Name), ainsi que, le cas échéant, l’UPN (identifiant utilisateur), définissent l’identité à vérifier. EAP est une méthode d’authentification pour un service Wi-Fi. L’importation d’un fichier PKCS-#12 (.pfx) est un mode de déploiement différent de SCEP : son certificat n’est pas renouvelé automatiquement par l’intervalle de renouvellement SCEP.

Traiter séparément les trois questions de confiance, même si la même AC assume plusieurs rôles dans votre PKI :

Connexion au serveur SCEP : avant SCEP, l’équipe MDM déploie une configuration Root certificate contenant le certificat de l’AC du serveur SCEP dans la politique appropriée. Pour les politiques d’appareils Android Enterprise, sélectionner également ce certificat dans le champ SCEP Root certificate parmi les certificats de la même politique. Ce certificat n’est pas le certificat client émis et ne prouve pas l’identité d’un client.
Identité du client certifié : sur Android Enterprise et iOS, le Subject doit être un nom X.500 valide de la personne ou de l’appareil concerné après remplacement de toutes les valeurs de substitution. Définir séparément le type et la valeur du SAN ; dans les champs SCEP des appareils, AD user logon name désigne l’UPN AD de l’utilisateur et non un identifiant quelconque de l’appareil. Sur iOS, le champ CA name est un nom compris par l’AC, notamment pour distinguer ses instances : il ne prouve ni l’identité de l’AC émettrice ni la présence d’une ancre de confiance. L’équipe PKI/AC vérifie donc sur le certificat effectivement émis l’AC émettrice et la chaîne de certification, les valeurs Subject/SAN/UPN autorisées, l’usage de la clé et l’accès à la clé privée. Les équipes MDM et du service conviennent de la manière dont le service concerné vérifie effectivement cette identité ; ne pas reprendre les valeurs fictives des exemples.
Confiance du service : si le Wi-Fi/VPN doit utiliser le certificat client, le service concerné doit faire confiance à sa chaîne d’AC. Avec EAP, vérifier en outre que l’appareil fait confiance au certificat du serveur Wi-Fi. Aucun de ces contrôles ne découle de la seule confiance accordée au serveur SCEP.

Responsables avant validation :

Équipe PKI/AC : vérifier que l’AC Windows prend en charge SCEP, que /CertSrv/MSCEP_ADMIN et /CertSrv/MSCEP sont accessibles, et que les droits permettent de générer les challenges et d’enrôler les certificats. Ne pas consigner les mots de passe des challenges, les identifiants d’accès au service ou les clés privées dans des tickets ou des captures d’écran. La mention historique de Windows 2003 dans l’aide Sophos ne constitue pas une garantie actuelle de prise en charge de cette version du serveur.
Équipe réseau : vérifier le FQDN de destination, le chemin via le proxy TLS/HTTP et l’autorisation strictement limitée des IP sources régionales en fonction de la topologie réelle ; vérifier séparément le trafic sortant des appareils, les notifications push et un chemin de gestion/réseau indépendant pour les situations d’urgence. Ne pas remplacer ces vérifications par une désactivation générale du filtrage.
Équipes MDM et du service : définir la plateforme, le type de politique appareil ou utilisateur et le mode d’enrôlement avant la configuration. Pour le chemin décrit ici pour les appareils Android Enterprise, utiliser une Android Enterprise device policy ; une politique Work Profile relève d’un autre périmètre de gestion. Le guide Android Enterprise explique ce choix de mode. Traiter séparément la charge utile SCEP des appareils iOS et ne pas l’utiliser comme preuve pour les politiques utilisateur iOS. Les champs SCEP communs et propres à chaque plateforme sont vérifiés séparément dans la procédure pilote ci-dessous. Arrêter si le type de politique n’est pas confirmé ou si le mode d’enrôlement n’est pas pris en charge.

Arrêter l’opération si l’identité prévue ou la chaîne de confiance de l’AC reste à définir, si le type ou le mode de l’appareil ne correspond pas à la politique vérifiée, ou si l’appareil n’est administrable que par le réseau Wi-Fi/VPN à remplacer et qu’aucun autre chemin de retour indépendant n’existe.

L’émission du certificat ne signifie pas son association au Wi-Fi/VPN

La configuration SCEP demande un certificat à l’AC. Avant toute modification du Wi-Fi/VPN, vérifier séparément :

Champ de sélection Wi-Fi : dans les politiques d’appareils Android Enterprise et les politiques d’appareils iOS, Identity certificate sélectionne un certificat issu d’une configuration Client certificate de la même politique. Cette configuration importe un fichier PKCS-#12 (.pfx) ; il s’agit d’un mode de déploiement différent de SCEP. Cela ne démontre pas qu’un certificat émis par SCEP peut être sélectionné dans le champ Wi-Fi. Un réseau Wi-Fi EAP sur Android Enterprise ne doit pas être masqué : le SSID doit être diffusé.
Renouvellement et confiance dans le serveur : planifier séparément l’importation, la validité et le remplacement des certificats PKCS-#12 ; SCEP renewal interval ne les renouvelle pas automatiquement. Le certificat racine du serveur EAP dans la politique Wi-Fi ne doit pas être automatiquement assimilé à celui utilisé pour faire confiance au serveur SCEP.

Le VPN n’offre pas non plus d’intégration SCEP uniforme : sur Android Enterprise, la politique sélectionne une application VPN Google Play gérée déjà installée ; les paramètres de connexion se trouvent dans sa Managed Configuration. Sur iOS, l’authentification par certificat et la sélection du certificat dépendent du type de connexion. Cette sélection ne prouve pas à elle seule qu’un certificat SCEP peut être utilisé. Avant tout pilote Wi-Fi/VPN, confirmer l’association du certificat prise en charge et le comportement après renouvellement pour la plateforme, le type de politique, la méthode d’authentification et, le cas échéant, le client VPN, au moyen des documents du fabricant pertinents ou dans un pilote circonscrit. Sans cette preuve, limiter le pilote à l’émission et au renouvellement SCEP ; ne déclencher ni migration Wi-Fi/VPN ni suppression de la chaîne de confiance existante.

Configurer SCEP dans un pilote limité uniquement

Sous Setup > Sophos setup > SCEP, valider avec l’équipe PKI l’URL du serveur SCEP https://<server>/CertSrv/MSCEP et celle du challenge https://<server>/CertSrv/MSCEP_ADMIN. Utiliser un compte autorisé au format username@domain et son mot de passe ; vérifier avec l’équipe PKI les types de caractères admis pour le challenge et les autorisations. Sélectionner les types de caractères convenus dans le champ Challenge characters pour le mot de passe du challenge avant de cliquer sur Save ; conserver la longueur de challenge définie par défaut par Sophos. N’adopter une exigence PKI différente qu’à titre d’exception documentée, approuvée et testée séparément. Si un proxy HTTP est activé, Use HTTP proxy s’applique initialement à cette connexion ; ne désactiver cette option que si Sophos Mobile doit volontairement atteindre le serveur SCEP sans passer par le proxy.
Cliquer sur Save et documenter le test de connexion au serveur SCEP. En cas d’échec, vérifier avec les responsables les URL, la confiance dans le certificat, le proxy, les autorisations et les IP sources permises, plutôt que de modifier immédiatement des politiques à grande échelle.
Commencer par créer une politique ou modifier une politique existante, adaptée au mode du pilote. Pour la création, la modification des configurations, l’enregistrement et l’attribution ultérieure au pilote, consulter le guide des politiques ; vérifier au préalable la plateforme et le type de politique pris en charge. Dans cette politique, configurer d’abord Root certificate avec le certificat de l’AC du serveur SCEP, puis SCEP et SCEP renewal interval. Pour les champs SCEP URL et Challenge, les aides des politiques pour appareils Android Enterprise et iOS indiquent respectivement les valeurs de substitution %_SCEPPROXYURL_% et %_CACHALLENGE_% pour les URL du serveur SCEP et du challenge configurées au préalable ; convenir du Subject, du SAN/UPN, de la taille de clé et de son usage avec la PKI et le service cible pour la plateforme concernée. N’attribuer la politique qu’au groupe pilote circonscrit. Les équipes PKI et MDM définissent à l’avance, pour cette plateforme et ce mode de politique précis, où observer la distribution de la politique, le certificat sur l’appareil et les opérations d’émission/renouvellement dans la PKI ; si l’association Wi-Fi/VPN est également établie, déterminer aussi le journal du service à consulter. Ne pas supposer que les champs d’état ou les noms de journaux sont identiques sur tous les appareils. SCEP renewal interval détermine quand l’appareil envoie la demande, pas si elle aboutit.
Champs SCEP propres à chaque plateforme : dans les politiques d’appareils Android Enterprise, définir un Alias name reconnaissable dans les boîtes de dialogue de sélection et sélectionner, dans le champ Root certificate, le certificat de l’AC du serveur SCEP provenant de la même politique. Dans les politiques d’appareils iOS, convenir du CA name avec l’AC ; Retries compte les nouvelles tentatives après une réponse pending du serveur, et Retry delay définit leur espacement en secondes. Ne pas présenter ces champs iOS comme des champs Android. Key size doit correspondre à la configuration du serveur SCEP. Pour Certificate usage, convenir séparément avec la PKI et le service de l’usage prévu, Use as digital signature ou Use for encryption ; ne pas inventer de taille ni de sélection par défaut.
Pour Type of Subject Alternative Name et Value of Subject Alternative Name, vérifier séparément le type et la valeur documentés : RFC 822 name pour une adresse e-mail valide, DNS name pour le nom DNS du serveur de l’AC ou Uniform resource identifier pour son URL complète. AD user logon name reste l’UPN AD de l’utilisateur. La description des champs ne remplace pas la vérification de l’identité sur le certificat effectivement émis.
Première émission après distribution de la politique : sur l’appareil pilote, comparer l’émetteur/la chaîne, le Subject et le SAN/UPN, le numéro de série, les dates de début et de fin de validité ainsi que l’usage de la clé aux exigences PKI approuvées. Un enregistrement d’appareil dans AD ne compte pas comme émission d’un certificat client SCEP. Sans émission observée : arrêter ; ne pas valider la rotation.
Renouvellement ultérieur : les équipes PKI et MDM définissent une période d’observation à partir de l’intervalle et de la durée de validité du certificat. Pendant cette période, vérifier sur l’appareil la présence d’un nouveau certificat valide, doté d’un nouveau numéro de série et des valeurs d’identité et d’émetteur attendues, ainsi que l’opération PKI correspondante confirmée. Si le renouvellement ne peut être observé ou n’a pas eu lieu pendant le pilote, ne pas valider la rotation.
Uniquement si l’association Wi-Fi/VPN a été démontrée pendant le pilote : dans le journal du service concerné, rattacher l’authentification réussie avant et après le renouvellement à cet appareil et à ce certificat pilotes précis. Sans journal du service ni association confirmée : ne pas basculer le Wi-Fi/VPN.

Rotation et solution de repli

Avant de changer l’URL SCEP, les identifiants d’accès au challenge ou l’AC, ainsi qu’avant tout changement de profil Wi-Fi/VPN justifié séparément, consigner dans le compte rendu du pilote, pour chaque classe d’appareils, l’ancienne et la nouvelle attribution des politiques, les ancres de confiance et les groupes concernés. Les équipes PKI, réseau et MDM définissent le chemin de gestion réellement accessible, indépendant du réseau reposant sur le certificat à remplacer, le responsable local de la reprise et le critère d’arrêt. La méthode concrète permettant de réattribuer ou de retirer une politique, ainsi que ses effets sur les appareils, doivent être validés pendant le pilote pour la plateforme et le mode d’enrôlement concernés ; aucune méthode universelle de retour en arrière n’est affirmée ici. Selon Sophos, Uninstall policy n’est prévu que pour les politiques d’appareils Android, de conteneurs Knox et d’appareils iOS ; pour les autres types, dont les politiques d’appareils Android Enterprise, il faut plutôt mettre à jour la politique ou en attribuer une autre. Cela ne prouve pas qu’une AC ou un certificat client déjà installé sera supprimé ou rétabli.

Décision avant déploiement : distribuer d’abord la nouvelle chaîne de confiance dans le pilote uniquement si le mode concerné permet sa distribution en parallèle. Vérifier la nouvelle émission et un renouvellement ultérieur réel. Si un changement Wi-Fi/VPN est prévu, vérifier en outre l’association au profil démontrée et l’authentification auprès du service avant et après le renouvellement. Ne supprimer les anciens profils et ancres de confiance qu’après une validation contrôlée et un déploiement planifié. Ne pas retirer prématurément l’ancienne AC tant qu’elle reste nécessaire aux connexions existantes.

En cas d’échec, agir selon l’accessibilité de l’appareil :

Arrêter toute nouvelle attribution ou suppression. Conserver l’AC, les profils et les ancres de confiance existants ; mobiliser les responsables PKI, réseau et MDM sur la base du compte rendu du pilote.
Appareil accessible par le chemin indépendant vérifié : l’équipe MDM rétablit l’attribution antérieure documentée de la politique, du réseau et de l’AC selon la méthode d’attribution ou de retrait préalablement validée pour ce mode ; les équipes PKI et réseau vérifient leurs parties respectives. Si le Wi-Fi/VPN a changé, retester l’authentification dans le journal du service.
Appareil hors ligne ou sans chemin indépendant : le responsable local de la reprise désigné au préalable utilise exclusivement la méthode locale de récupération prévue et testée à l’avance ; revérifier ensuite l’accessibilité et, si nécessaire, l’authentification auprès du service. Le simple rétablissement d’un paramètre dans le cloud n’est pas une restauration démontrée pour des appareils devenus hors ligne. Si la méthode locale n’a pas été validée, ne pas prétendre pouvoir restaurer les appareils à distance en toute sécurité ni étendre le changement.

Sans première émission observée, sans renouvellement et sans chemin de retour vérifié, le changement SCEP en production reste bloqué ; un changement Wi-Fi/VPN exige en plus une association du certificat démontrée et une utilisation réussie avant et après le renouvellement.

Limite des vérifications : ce document est un brouillon fondé sur des sources, non testé dans un tenant ni sur des appareils. Les versions de systèmes d’exploitation et de serveurs prises en charge, le comportement du client lors d’un renouvellement hors ligne et la vérification concrète de l’identité dans EAP/VPN doivent être confirmés séparément dans votre environnement.