Cet article a été traduit automatiquement. La traduction peut contenir des imprécisions.
Passer à la version originale en anglais.
Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Problèmes courants

Problèmes au démarrage de SCEPman

J’ai déployé SCEPman depuis GitHub et cela fonctionnait auparavant, mais maintenant l’application web ne démarre plus

Si l’erreur est « 503 Cannot download ZIP », alors l’application web ne peut pas télécharger le ZIP contenant les binaires de l’application à partir de 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 anciennes versions de cette documentation redirige vers une autre URL. Microsoft a modifié le comportement de certaines de ses applications web et certaines versions ne prennent désormais plus en charge les redirections avec WEBSITE_RUN_FROM_PACKAGE. Vous devez donc modifier l’URL en https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip.

L’application web Azure de SCEPman ne fonctionne pas

Vérifiez si la ressource Azure est opérationnelle.

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 pile. Bien que la pile soit .NET, la version de .NET peut ne pas correspondre à ce que vous attendez pour votre version de SCEPman, par ex. .NET 8 pour SCEPman 2.8.

Cela 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 faisons évoluer SCEPman vers une nouvelle version de .NET que lorsque cette version fait partie de cet ensemble de versions .NET installées automatiquement. Nous procédons ainsi parce que notre mécanisme de mise à jour via WEBSITE_RUN_FROM_PACKAGE ne nous donne aucun contrôle sur le paramètre de version de .NET. Par conséquent, la version de .NET configurée n’a en réalité pas d’importance.

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ème 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 migration des artefacts vers le nouvel emplacement https://github.com/scepman/install. Le mercredi 27/11/2024, nous avons temporairement désactivé l’ancien emplacement afin d’informer les utilisateurs de la fermeture définitive 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 compatibilité totale avec les versions précédentes.

Si vous n’êtes pas sûr d’utiliser le dernier dépôt, visitez la page d’accueil de SCEPman. S’il est encore configuré sur l’ancien dépôt, un avertissement s’affiche (et cela fait déjà trois ans que c’est le cas) semblable à celui-ci :

SCEPman utilise l’ancien emplacement du package pour WEBSITE_RUN_FROM_PACKAGE

Problèmes lors de l’émission de certificats

Le certificat racine approuvé est déployé, mais mon certificat d’appareil via le profil SCEP entraîne une erreur

Le profil SCEP entraînera une erreur si le déploiement du certificat n’a pas réussi. Les erreurs peuvent avoir plusieurs raisons :

Le profil de certificat SCEP est configuré avec une erreur

Cela peut se produire lorsqu’un mauvais certificat racine approuvé a été sélectionné dans le profil de certificat SCEP. Cela est également indiqué dans le journal des événements :

  1. Ouvrez l’application Événements Windows

  2. Cliquez sur Journaux des applications et des services

  3. Ensuite, cliquez sur Microsoft

  4. Puis, cliquez sur Windows

  5. Faites défiler vers le bas et recherchez DeviceManagement-Enterprise-Diagnostics-Provider et cliquez dessus.

  6. Dans la fenêtre qui s’affiche, cliquez sur Admin

  7. Parcourez la liste et recherchez l’ID d’événement 32

  8. Il contient un court rapport d’erreur

    • SCEP : l’enregistrement 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 cela est spécifique à la plateforme Windows et qu’Android, par exemple, nécessite de sélectionner le certificat de la CA racine dans le profil de configuration SCEP.

Mon certificat n’a pas l’entrée d’URL OCSP correcte

C’est seulement un problème avant la version 1.2

Si le certificat de l’appareil contient une URL localhost pour l’entrée OCSP dans le certificat, comme ceci :

L’App Service manque un paramètre d’application important nommé 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 l’avez fait, vous verrez une URL correcte pour l’entrée OCSP :

Mon profil de configuration SCEP affiche l’état en attente et n’est pas appliqué

Le profil de configuration SCEP dépend du profil de certificat Trusted Root. Attribuez les deux profils au même groupe d’utilisateurs ou d’appareils Azure Active Directory afin de vous assurer que l’utilisateur ou l’appareil se recoupe et que les deux profils ciblent l’appareil. Ne mélangez pas les groupes d’utilisateurs et d’appareils. Si vous voyez l’état en attente pour les profils de configuration dans Intune pendant longtemps, l’attribution est probablement incorrecte.

Certaines machines Windows n’enrôlent pas ou ne renouvellent pas les certificats

Vous pouvez vérifier à la fois du côté de SCEPman et du côté client. Selon le problème, que vous ne connaissez souvent pas à l’avance, la cause racine n’apparaît que d’un des deux côtés.

Vérifiez s’il existe une entrée [ERROR] dans les journaux SCEPman. Recherchez éventuellement aussi le terme de recherche [WARN, mais cela peut produire quelques faux positifs.

Oliver Kieselbach et Christoph Hannebauer ont rédigé un article de blog sur l’analyse des problèmes de demande ou de renouvellement de certificats qui vous aide à localiser les problèmes d’enrôlement côté client.

Le client SCEP Windows ne prend en charge TLS que jusqu’à la version 1.2. Définir la version minimale TLS 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’enrôler avec AutoPilot

Actuellement, certains appareils Windows 10 n’ont pas l’heure correcte 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 ne sont pas encore valides. Windows rejette alors ces certificats « invalides » et affiche une erreur. Les certificats sont émis par défaut 10 minutes dans le passé pour remédier aux petits problèmes d’horloge, mais nous avons récemment vu des appareils Windows 10 avec un retard allant jusqu’à 9 heures.

Vous pouvez poursuivre l’enrôlement et, une fois celui-ci 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 dater les certificats de plus de 10 minutes dans le passé. Utilisez 1440 minutes pour dater les certificats d’une journée entière dans le passé. Ce sera la valeur 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 qu’il a été émis hier

C’est parce que SCEPman date les certificats d’un jour dans le passé pour contrer les problèmes liés aux appareils dont l’horloge est en retard, voir Les appareils Windows 10 ne peuvent pas s’enrôler 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 :

Examinez le certificat avec l’ID d’appareil émis par SCEPman-Device-Root-CA-V1 et vérifiez si le certificat est valide (voir la dernière ligne).

Pour vérifier que le répondant OCSP fonctionne, vous pouvez consulter le cache de l’URL OCSP avec la commande suivante :

Machine macOS

Pour vérifier la validité d’un certificat sur une machine macOS à l’aide d’OCSP, veuillez suivre ces étapes :

  1. Exportez le certificat SCEPman Root CA depuis Accès au trousseau (Trousseaux système > Racines système) en tant que fichier *.cer et placez-le dans un dossier (vous pouvez également le télécharger depuis le site web de votre instance SCEPman).

  2. Exportez le certificat d’authentification client que vous souhaitez vérifier depuis Accès au trousseau (Trousseaux système > Système > Mes certificats) en tant que fichier *.cer dans le même dossier.

  3. Extrayez l’URL du répondant OCSP à partir de la propriété Accès aux informations d’autorité (AIA) du certificat d’authentification client :

  4. Ouvrez une session Terminal et cd vers le dossier qui contient les certificats exportés.

  5. Exécutez la commande suivante :

  1. Vers la fin de la réponse, l’état de révocation est affiché :\

Vérifier les certificats d’autres machines

Comme autre possibilité, 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 certificat utilisateur , vous avez deux options :‌

  1. Supprimer l’utilisateur de Microsoft Entra ID (Azure AD) ou

  2. Bloquer la connexion pour l’utilisateur

Si vous souhaitez révoquer un certificat appareil certificate, vous have multiple options depending on AppConfig:IntuneValidation:DeviceDirectory:

  1. Microsoft Entra ID (Azure AD) : supprimer ou désactiver l’appareil (Portail Microsoft Entra ID (Azure AD): « Appareils » - « Tous les appareils »).

  2. 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).

  3. Les deux répertoires: exécuter des actions pour Microsoft Entra ID (Azure AD) et Intune comme décrit.

Pour plus de détails sur les répertoires d’appareils, veuillez lire l’article Répertoires des appareils.

L’exemple suivant révoque un certificat d’appareil via Microsoft Entra ID (Azure AD) :

  1. Accédez à Appareils - Tous les appareils dans votre Microsoft Entra ID (Azure AD)

  2. Choisissez un appareil

  3. Cliquez sur Désactiver

Ensuite, tapez à nouveau la commande suivante :

Comme vous pouvez le voir sur la dernière ligne, le Certificat est RÉVOQUÉ

Lorsque vous réactivez l’appareil dans Microsoft Entra ID (Azure AD) et que vous retapez la commande ci-dessus, le certificat devrait être marqué comme valide.

Cela peut prendre jusqu’à 5 minutes avant que l’invite « Marqué comme valide » n’apparaisse.

Access Point ne peut pas vérifier un certificat d’authentification émis par SCEPman

Symptômes: Cisco ISE affiche une erreur OCSP inaccessible. Aruba ClearPass a également ce problème. Le serveur, apparemment SCEPman, répond à la requête OCSP avec un paquet de réinitialisation TCP.

Cause: Cisco ISE et 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 exécutée 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 place par erreur l’ID d’appareil Intune dans le certificat au lieu de l’ID d’appareil AAD dans certains cas aléatoires, même si vous configurez la variable dans le profil de configuration SCEP. SCEPman ne peut alors pas trouver un appareil avec cet ID dans AAD et considère donc le certificat comme révoqué.

Cela ne se produit que lorsque vous utilisez le mode partagé Microsoft Entra ID (Azure AD) pour la méthode d’enrôlement des 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 concerné par le problème. Intune placera toujours l’ID d’appareil Intune dans le certificat au lieu de l’ID d’appareil AAD, mais ils seront identiques dans le mode par défaut, donc cela n’a pas d’importance. Pour modifier le mode d’enrôlement, rendez-vous dans les paramètres d’enrôlement Android du centre d’administration Microsoft Endpoint Manager et choisissez Appareil dédié appartenant à l’entreprise (par défaut) au lieu de Appareil dédié appartenant à l’entreprise avec le mode partagé Azure AD. Veuillez vous référer à la documentation Microsoft pour connaître les implications de cette sélection.

Nous travaillons actuellement avec Microsoft pour résoudre ce problème dans toutes les configurations. Veuillez contacter notre support si vous êtes également concerné.

Mon Storage Account indique qu’il n’est pas connecté

Si votre page d’accueil SCEPman affiche une étiquette rouge « Not Connected » pour la connectivité Storage Account, il se peut que l’identité managée de l’App Service SCEPman (et éventuellement celle de SCEPman Certificate Master) n’ait pas les autorisations requises sur le Storage Account. 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 Storage Account vers un autre abonnement ou groupe de ressources. Cela peut également se produire après la mise à niveau d’une version Community Edition vers Enterprise Edition — dans ce cas, le problème d’autorisations existait déjà, mais la Community Edition ne le vérifiait pas.

Pour corriger cela, vous devez attribuer à l’identité managée de l’App Service SCEPman et à celle de SCEPman Certificate Master le rôle « Storage Table Data Contributor » sur le Storage Account. Les attributions de rôles peuvent être effectuées manuellement dans le Portail Azure sous « Contrôle d’accès (IAM) » dans le Storage Account. Sinon, exécutez simplement à nouveau le cmdlet d’installation SCEPman à partir du module PowerShell SCEPman.

SCEPman n’émettra pas de certificats avec des EKU autres que l’authentification client

Vérifiez vos variables d’environnement SCEPman pour voir ce qui est configuré pour AppConfig:UseRequestedKeyUsages. S’il n’est pas défini, la valeur par défaut est « false ».

Les nouvelles installations définiront automatiquement cette valeur sur « true » ; cependant, les anciennes installations SCEPman l’ont définie sur false. Les mises à jour SCEPman ne changent aucun comportement, sauf pour les corrections ou modifications qui n’ont en aucun cas d’inconvénient. Lorsque cette valeur est définie sur false, les EKU et les utilisations de clé demandés sont ignorés.

Mis à jour

Ce contenu vous a-t-il été utile ?