Problèmes courants
Problèmes de démarrage de SCEPman
J'ai déployé SCEPman depuis GitHub et il fonctionnait auparavant, mais maintenant l'application Web ne démarre plus
Si l'erreur est «503 Impossible de télécharger le ZIP», alors l'application web ne peut pas télécharger le ZIP contenant les binaires de l'application depuis l'URL configurée dans le paramètre d'application WEBSITE_RUN_FROM_PACKAGE (voir Configuration de l'application).
L'URL https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip que nous avions recommandée pour les déploiements GitHub dans les versions antérieures de cette documentation redirige vers une autre URL. Microsoft a modifié le comportement de certaines de leurs Web Apps et désormais certaines versions ne prennent pas en charge les redirections avec WEBSITE_RUN_FROM_PACKAGE. Par conséquent, vous devez changer l'URL en https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip.
L'Application Web Azure SCEPman ne fonctionne pas
Vérifiez si la ressource Azure est activée et en cours d'exécution.
Mon App Service utilise la mauvaise version de .NET
Dans la ressource App Service de SCEPman ou Certificate Master, vous pouvez vérifier quelle pile et quelle version sont configurées pour cet App Service sous Paramètres -> Configuration -> Paramètres généraux -> Paramètres de la pile. Bien que la pile soit .NET, la version de .NET peut ne pas correspondre à ce que vous attendez pour votre version de SCEPman, p. ex. .NET 8 pour SCEPman 2.8.
Ceci est dû au fait que certaines versions courantes de .NET sont automatiquement disponibles sur tous les App Services Windows, indépendamment de la version de .NET que vous sélectionnez dans les paramètres. Nous ne passons SCEPman à une nouvelle version de .NET que lorsque cette version est incluse dans cet ensemble de versions de .NET installées automatiquement. Nous procédons ainsi car notre mécanisme de mise à jour via WEBSITE_RUN_FROM_PACKAGE ne nous donne aucun contrôle sur le paramètre de version .NET. Par conséquent, il n'a en réalité aucune importance ce qui est configuré comme version de .NET.
Mon App Service SCEPman ne fonctionnait pas le 27/11/2024 et il a cessé de fonctionner complètement depuis le 16/12/2024 alors qu'il fonctionnait sans problèmes depuis de nombreuses années
Nous fermons le dépôt d'artefacts SCEPman obsolète https://github.com/glueckkanja/gk-scepman après plus de trois ans de déplacement des artefacts vers le nouvel emplacement https://github.com/scepman/install. Le mercredi 27/11/2024, nous avons temporairement désactivé l'ancien emplacement pour informer les utilisateurs de l'arrêt définitif le lundi 16/12/2024.
Si vous êtes concerné, vérifiez votre paramètre WEBSITE_RUN_FROM_PACKAGE et mettez à jour la valeur vers le nouvel emplacement du package. Cela mettra également à jour votre version de SCEPman de 1.8 vers la dernière version, offrant de nombreuses améliorations avec une pleine compatibilité ascendante.
Si vous n'êtes pas sûr d'utiliser le dépôt le plus récent, visitez la page d'accueil de votre SCEPman. Si elle est toujours configurée sur l'ancien dépôt, elle affiche un avertissement (et affiche cela depuis déjà trois ans) qui ressemble à ceci :
Problèmes d'émission de certificats
Le certificat racine de confiance est déployé mais mon certificat d'appareil via le profil SCEP renvoie une erreur
Le profil SCEP renverra une erreur si le déploiement du certificat n'a pas réussi. Les erreurs peuvent avoir plusieurs causes :
Le profil de certificat SCEP est configuré avec une erreur
Cela peut se produire lorsqu'un mauvais certificat racine de confiance a été sélectionné dans le profil de certificat SCEP. Cela est également montré dans le journal des événements :
Ouvrez l'application Observateur d'événements Windows
Cliquer sur Journaux d'applications et de services
Ensuite, cliquez sur Microsoft
Puis, cliquez sur Windows
Faites défiler vers le bas et recherchez DeviceManagement-Enterprise-Diagnostics-Provider et cliquez dessus.
Dans la fenêtre qui apparaîtra, cliquez sur Admin
Parcourez la liste et recherchez l'ID d'événement 32
Il contient un court rapport d'erreur
SCEP : l'enrôlement du certificat a échoué. Résultat (La valeur de hachage n'est pas correcte).
Si vous utilisez une CA intermédiaire, notez que vous devez sélectionner le certificat de la CA intermédiaire et non le certificat de la CA racine dans le profil de configuration SCEP ! Notez que ceci est spécifique à la plateforme Windows et par exemple Android exige la sélection du certificat de la CA racine dans le profil de configuration SCEP.
Mon certificat n'a pas la bonne entrée d'URL OCSP
Si le certificat de l'appareil a une URL localhost pour l'entrée OCSP dans le certificat comme ceci :
L'App Service manque un paramètre d'application important portant le nom AppConfig:BaseUrl défini sur l'URL azurewebsite. Pour corriger cela, ajoutez la variable et enregistrez la configuration de l'App Service :
Supprimez ce certificat de l'appareil et effectuez la synchronisation MDM. Si vous le faites, vous verrez une URL correcte pour l'entrée OCSP :
Mon profil de configuration SCEP affiche en attente et n'est pas appliqué
Le profil de configuration SCEP dépend du profil de certificat racine de confiance. Assignez les deux profils au même groupe d'utilisateurs ou de périphériques Azure Active Directory afin de vous assurer que l'utilisateur ou le périphérique se recouvre et que les deux profils ciblent l'appareil. Ne mélangez pas les groupes d'utilisateurs et de périphériques. Si vous voyez le statut en attente pour les profils de configuration dans Intune pendant longtemps, l'affectation est probablement incorrecte.
Certaines machines Windows ne s'inscrivent pas ou ne renouvellent pas les certificats
Vous pouvez vérifier des deux côtés, côté SCEPman et côté client. Selon le problème, que vous ne connaissez souvent pas à l'avance, la cause racine n'est affichée que sur l'un des deux côtés.
Vérifiez s'il y a un [ERROR] entrée dans les journaux SCEPman. Éventuellement recherchez aussi le terme de recherche [WARN, mais cela peut produire des faux positifs.
Oliver Kieselbach et Christoph Hannebauer ont écrit un article de blog sur l'analyse des problèmes de demande ou de renouvellement de certificat qui vous aide à traquer les problèmes d'enrôlement côté client.
Le client SCEP Windows ne prend en charge que TLS jusqu'à la version 1.2. Définir la version TLS minimale entrante sur 1.3 dans l'App Service SCEPman provoque des entrées d'erreur particulières dans le DeviceManagement-Enterprise-Diagnostics-Provider journal des événements. Voici un exemple provenant d'une machine Windows 11 :
Les appareils Windows 10 ne peuvent pas s'inscrire avec AutoPilot
Actuellement, certains appareils Windows 10 n'ont pas la bonne heure pendant l'expérience OOBE. Ce n'est pas facile à voir, car l'écran n'affiche pas d'horloge. Cela pose un problème avec les certificats nouvellement émis, car ils sont pas encore valables. Windows rejette alors ces certificats "invalides" et affiche une erreur. Les certificats sont émis par défaut avec une antériorité de 10 minutes pour pallier de petits problèmes d'horloge, mais nous avons récemment vu des appareils Windows 10 ayant jusqu'à 9 heures de retard.
Vous pouvez poursuivre l'enrôlement et une fois terminé, l'appareil obtiendra un certificat avec succès, car l'horloge sera alors correcte. Vous pouvez également utiliser la nouvelle option AppConfig:ValidityClockSkewMinutes pour reculer la date des certificats de plus de 10 minutes. Utilisez 1440 minutes pour reculer les certificats d'une journée entière. Cela sera le comportement par défaut pour les nouvelles installations de SCEPman afin de résoudre ce problème.
J'ai émis un certificat aujourd'hui, mais la date d'émission indique que c'était hier
C'est parce que SCEPman recule la date du certificat d'un jour pour contrer les problèmes avec des appareils dont l'horloge est en retard, voir Les appareils Windows 10 ne peuvent pas s'inscrire avec AutoPilot.
Problèmes de validité des certificats
Vérifier le certificat local
Machine Windows
Tout d'abord, vous devez vérifier la validité du certificat de l'appareil. Pour cela, ouvrez une invite de commandes en tant qu'administrateur et tapez la commande suivante :
Regardez le certificat avec l'ID de l'appareil émis par la SCEPman-Device-Root-CA-V1 et vérifiez si le certificat est valide (voir la dernière ligne).
Pour vérifier que le répondeur OCSP fonctionne, vous pouvez examiner le cache d'URL OCSP avec la commande suivante :
Machine macOS
Pour vérifier la validité d'un certificat sur une machine macOS en utilisant OCSP, veuillez suivre ces étapes :
Exportez le certificat racine CA de SCEPman depuis Trousseau d'accès (Trousseaux système > Racines système) en tant que fichier *.cer et placez-le dans un dossier (alternativement, vous pouvez le télécharger depuis le site de votre instance SCEPman).
Exportez le certificat d'authentification client que vous souhaitez vérifier depuis Trousseau d'accès (Trousseaux système > Système > Mes certificats) en tant que fichier *.cer dans le même dossier.
Extrayez l'URL du répondeur OCSP depuis la propriété Authority Information Access (AIA) du certificat d'authentification client :
Ouvrez un Terminal session et
cddans le dossier qui contient les certificats exportés.Exécutez la commande suivante :
Vers la fin de la réponse, l'état de révocation est affiché:\
Vérifier les certificats depuis d'autres machines
En alternative, vous pouvez exporter le certificat de l'appareil et utiliser certutil sur une machine Windows pour afficher une petite interface certutil pour la vérification OCSP :
Révoquer un utilisateur
Si vous souhaitez révoquer un utilisateur certificat, vous avez deux options :
Supprimer l'utilisateur de Microsoft Entra ID (Azure AD) ou
Bloquer la connexion pour l'utilisateur
Si vous souhaitez révoquer un périphérique certificat, vous avez plusieurs options selon AppConfig:IntuneValidation:DeviceDirectory:
Microsoft Entra ID (Azure AD) : Supprimer ou désactiver l'appareil (Portail Microsoft Entra ID (Azure AD): "Périphériques" - "Tous les périphériques").
Intune: Supprimer l'appareil ou déclencher une action à distance (plusieurs états de gestion comme "WipePending" révoquent automatiquement les certificats comme indiqué sous AppConfig:IntuneValidation:RevokeCertificatesOnWipe).
Les deux annuaires: Exécuter des actions pour Microsoft Entra ID (Azure AD) et Intune comme décrit.
L'exemple suivant révoque un certificat d'appareil via Microsoft Entra ID (Azure AD) :
Accéder à Périphériques - Tous les périphériques dans votre Microsoft Entra ID (Azure AD)
Choisissez un appareil
Cliquer sur Désactiver
Ensuite, saisissez à nouveau la commande suivante :
Comme vous pouvez le voir dans la dernière ligne, le Certificat est RÉVOQUÉ
Lorsque vous réactivez l'appareil dans Microsoft Entra ID (Azure AD) et que vous saisissez de nouveau la commande ci-dessus, le certificat devrait être marqué comme valide.
Le point d'accès ne peut pas vérifier un certificat d'authentification émis par SCEPman
Symptômes: Cisco ISE affiche une erreur OCSP inaccessible. Aruba ClearPass rencontre également ce problème. Le serveur, apparemment SCEPman, répond avec un paquet de réinitialisation TCP à la requête OCSP.
Cause: Tant Cisco ISE que Aruba ClearPass ne prennent pas en charge HTTP 1.1 lors de la recherche OCSP et n'envoient pas d'en-tête Host dans leur requête OCSP. Par conséquent, ils ne peuvent pas se connecter à une instance SCEPman générale fonctionnant sur Azure App Services. Le message d'erreur peut ressembler à ceci :
Solution: Veuillez consulter ici.
Les certificats d'appareil sur mes systèmes Android (dédiés) ne sont pas valides
Sur les systèmes Android (dédiés), Intune ou Android insèrent accidentellement l'ID de périphérique Intune dans le certificat au lieu de l'ID de périphérique AAD dans des cas aléatoires, bien que vous configuriez la variable dans le profil de configuration SCEP. SCEPman ne peut alors pas trouver un périphérique avec cet ID dans AAD et considère donc le certificat comme révoqué.
Cela se produit uniquement lorsque vous utilisez le mode partagé Microsoft Entra ID (Azure AD) comme méthode d'enrôlement pour les appareils dédiés appartenant à l'entreprise au lieu du mode par défaut. Si vous utilisez le mode par défaut pour les types de jetons Appareil dédié appartenant à l'entreprise, vous ne serez pas affecté par le problème. Intune continuera à placer l'ID de périphérique Intune dans le certificat au lieu de l'ID de périphérique AAD, mais ils seront identiques pour le mode par défaut, donc cela n'a pas d'importance. Pour changer le mode d'enrôlement, allez dans les paramètres d'enrôlement Android du centre d'administration Microsoft Endpoint Manager et choisir Appareil dédié appartenant à l'entreprise (par défaut) au lieu de Appareil dédié appartenant à l'entreprise en mode partagé Azure AD. Veuillez vous référer à la documentation Microsoft pour les implications de ce choix.
Nous travaillons actuellement avec Microsoft pour résoudre ce problème dans toutes les configurations. Veuillez contacter notre support si vous êtes également affecté.
Mon compte de stockage indique qu'il n'est pas connecté
Si la page d'accueil de votre SCEPman affiche une étiquette rouge «Non connecté» pour la connectivité du compte de stockage, il est possible que l'identité managée de l'App Service SCEPman (et éventuellement celle de SCEPman Certificate Master) n'ait pas les autorisations sur le compte de stockage. Dans ce cas, SCEPman ne peut pas vérifier si un certificat est révoqué manuellement et ne peut donc pas répondre aux requêtes OCSP. Cela se produit généralement si vous déplacez le compte de stockage vers un autre abonnement ou groupe de ressources. Cela peut aussi se produire après la mise à niveau d'une version Community Edition vers Enterprise Edition -- dans ce cas, le problème d'autorisation existait auparavant, mais la Community Edition ne le vérifiait pas.
Pour corriger cela, vous devez accorder à l'identité managée de l'App Service SCEPman et à celle de SCEPman Certificate Master le rôle «Storage Table Data Contributor» sur le compte de stockage. Les attributions de rôle peuvent être effectuées manuellement dans le portail Azure sous «Contrôle d'accès (IAM)» du compte de stockage. Alternativement, simplement exécutez à nouveau le CMDlet d'installation de SCEPman depuis le module PowerShell SCEPman.
SCEPman n'émettra pas de certificats avec des EKU autres que Authentification client
Vérifiez vos variables d'environnement SCEPman pour voir ce qui est configuré pour AppConfig:UseRequestedKeyUsages. Si ce n'est pas défini, la valeur par défaut est «false».
Les nouvelles installations définiront automatiquement ceci sur «true», cependant les anciennes installations de SCEPman ont ceci réglé sur false. Les mises à jour de SCEPman ne changent aucun comportement sauf pour des corrections ou modifications qui n'ont en aucun cas d'inconvénient. Lorsque ceci est défini sur false, les EKU et usages de clé des requêtes sont ignorés.
Mis à jour
Ce contenu vous a-t-il été utile ?