> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/fr/autres/troubleshooting/general.md).

# 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 depuis l’URL configurée dans le paramètre d’application WEBSITE\_RUN\_FROM\_PACKAGE (voir [Configuration de l’application](/fr/configuration-de-scepman/application-artifacts.md#change-artifacts)).

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 précédentes de cette documentation redirige vers une autre URL. Microsoft a modifié le comportement de certaines de ses Web Apps et, désormais, certaines versions ne prennent pas en charge les redirections avec WEBSITE\_RUN\_FROM\_PACKAGE. Vous devez donc changer l’URL vers `https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip`.

### L’application web Azure SCEPman ne s’exécute pas

Vérifiez si la ressource Azure est en cours d’exécution.

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-fa1f838cc58fdfc0443c4d1e663643b3df01dd4e%2Fevent32_2%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(11\)%20\(2\).png?alt=media)

### 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.

C’est parce 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 est incluse dans cet ensemble de versions de .NET installées automatiquement. Nous procédons ainsi parce que notre mécanisme de mise à jour via [WEBSITE\_RUN\_FROM\_PACKAGE ](/fr/configuration-de-scepman/application-settings/basics.md#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é aucune importance.

### Mon App Service SCEPman ne fonctionnait pas le 2024-11-27 et il a cessé de fonctionner complètement depuis le 2024-12-16 après avoir fonctionné sans problème pendant de nombreuses années

Nous mettons hors service 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 2024-11-27, nous avons temporairement désactivé l’ancien emplacement afin d’informer les utilisateurs de l’arrêt définitif le lundi 2024-12-16.

Si vous êtes concerné, vérifiez votre paramètre WEBSITE\_RUN\_FROM\_PACKAGE et [mettez à jour la valeur](/fr/configuration-de-scepman/application-artifacts.md) 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](/fr/changelog.md) avec une compatibilité ascendante totale.

Si vous n’êtes pas sûr d’utiliser le dépôt le plus récent, visitez la page d’accueil de SCEPman. S’il est toujours configuré sur l’ancien dépôt, un avertissement s’affiche (et c’est déjà le cas depuis trois ans) qui ressemble à ceci :

<figure><img src="https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FbX4ATqv8O0f3cXCdqwLy%2Fimage.png?alt=media&amp;token=b9ed1f6f-ce4f-4745-b30b-9b01c518997c" alt=""><figcaption><p>SCEPman utilise l’ancien emplacement du package pour WEBSITE_RUN_FROM_PACKAGE</p></figcaption></figure>

## Problèmes lors de l’émission des certificats

### Le certificat racine de confiance est déployé, mais mon certificat d’appareil via le profil SCEP produit 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 de confiance 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 **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** puis cliquez dessus.
6. Dans la fenêtre qui s’affichera, 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’inscription du certificat a échoué. Résultat (la valeur de hachage n’est pas correcte.).

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-4e964c4cda9f70b7c0a4c24a293f0bf7133844c3%2Fevent32_1%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(11\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(12\).png?alt=media)

Si vous utilisez une AC intermédiaire, notez que vous devez [sélectionner le certificat de l’AC intermédiaire](/fr/deploiement-de-scepman/intermediate-certificate.md#intermediate-cas-and-intune-scep-profiles) et non le certificat de l’AC racine dans le profil de configuration SCEP ! Notez que cela est spécifique à la plateforme Windows et qu’Android, par exemple, nécessite la sélection du certificat de l’AC racine dans le profil de configuration SCEP.

### Mon certificat n’a pas la bonne entrée d’URL OCSP

{% hint style="info" %}
Ceci est uniquement un problème avant la version 1.2
{% endhint %}

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

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-13206c885994d08c4ec6e5996ea261b2d3ee5912%2Fevent32_7%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\).png?alt=media)

L’App Service ne dispose pas d’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 :

```
AppConfig:BaseUrl
https://scepman-XXXXX.azurewebsites.net
```

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 :

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-7729e8388eaa003c5561f926e7f26c54972fd5b2%2Fevent32_8%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\).png?alt=media)

### Mon profil de configuration SCEP apparaît en attente et n’est pas appliqué

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

### Certaines machines Windows n’inscrivent pas ou ne renouvellent pas les certificats

Vous pouvez vérifier à la fois du côté de SCEPman et du côté du client. Selon le problème, que vous ne connaissez souvent pas à l’avance, la cause racine n’apparaît que d’un seul 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](https://oliverkieselbach.com/2022/09/21/deep-dive-of-scep-certificate-request-renewal-on-intune-managed-windows-clients/) qui vous aide à identifier les problèmes d’inscription côté client.

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

{% code overflow="wrap" fullWidth="false" %}

```
TimeCreated  : 7/2/2025 12:51:06 PM
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 32
Message      : SCEP: l’inscription du certificat a échoué. Résultat : (Unknown Win32 Error code: 0x80072f8f).

TimeCreated  : 7/2/2025 12:51:06 PM
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 307
Message      : SCEP: Message d’erreur de journalisation échoué : (SCEPInstallCertificateWithScepHelper: échec de l’initialisation
               Inscription SCEP avec serveur NDES
               'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe', empreinte du certificat de l’AC
               '24C45EF4284A5093A9C3886A6466C1D6D84EE058' et certificats du serveur ''. LogError 0x80)
```

{% endcode %}

### Les appareils Windows 10 ne peuvent pas s’inscrire 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 pour les certificats nouvellement émis, car ils ne sont *pas encore* valides. Windows rejette alors ces certificats « non valides » et affiche une erreur. Par défaut, les certificats sont émis avec 10 minutes d’antériorité pour traiter les petits problèmes d’horloge, mais nous avons récemment vu des appareils Windows 10 qui avaient jusqu’à 9 heures de retard.

Vous pouvez poursuivre l’inscription et, une fois celle-ci terminée, l’appareil obtiendra correctement un certificat, car l’horloge sera alors correcte. Vous pouvez également utiliser la nouvelle option [**AppConfig:ValidityClockSkewMinutes**](/fr/configuration-de-scepman/application-settings/certificates.md#appconfig-validityclockskewminutes) pour dater les certificats de plus de 10 minutes. Utilisez 1440 minutes pour dater les certificats d’une journée entière. 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 antédate les certificats d’un jour pour contrer les problèmes liés aux appareils dont l’horloge est en retard, voir [Les appareils Windows 10 ne peuvent pas s’inscrire avec AutoPilot](#windows-10-devices-cannot-enroll-with-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 :

```
certutil -verifyStore MY
```

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

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-cb549f4e3708565d2455a9f459c2e54254ee26e8%2Fscepman_revocation1%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\).png?alt=media)

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

```
certutil -urlcache OCSP
```

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-6c46d2b65ee1277d01b26b0f496975a577d35f21%2Fscepman_revocation2%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(5\).png?alt=media)

#### 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 **Trousseau d’accès** (**Trousseaux système > Racines système**) au format \*.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 **Trousseau d’accès** (**Trousseaux système > Système > Mes certificats**) au format \*.cer dans le même dossier.
3. Extrayez l’URL du répartiteur OCSP à partir de la propriété du certificat d’authentification client **Authority Information Access** (AIA) :

   <figure><img src="https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FaJqT97xxEUx1py2f0xbT%2Fimage.png?alt=media&amp;token=3c0ca083-8cb9-471f-a7ab-4a314337b585" alt=""><figcaption></figcaption></figure>
4. Ouvrez une **session Terminal** et `cd` vers le dossier qui contient les certificats exportés.
5. Exécutez la commande suivante :

```
openssl ocsp -issuer <filename-scepman-root-ca-certificate> -cert <filename-certificate-to-be-verified> -text -url <ocsp-responder-url>
```

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

   <figure><img src="https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FRXQI4xRp0NRt5vBwDY89%2Fimage.png?alt=media&amp;token=ee8e2761-e249-4bd1-ae82-0eac933363d2" alt=""><figcaption></figcaption></figure>

### Vérifier les certificats d’autres machines

Sinon, 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 :

```
certutil -url <path-to-exported-device-certificate>
```

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-d3dffe20c2939eddc1ea08c0e4164440e9c7a3c3%2Fscepman_revocation4%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(5\).png?alt=media)

### Révoquer un utilisateur

Si vous souhaitez révoquer un **utilisateur** certificat, vous avez deux options :‌

1. Suppression de l’utilisateur de Microsoft Entra ID (Azure AD) ou
2. Blocage de la connexion pour l’utilisateur

Si vous souhaitez révoquer un **certificat d’** de l’appareil, vous avez plusieurs options selon [Validation Intune](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory):

1. Microsoft Entra ID (Azure AD) : supprimer ou désactiver l’appareil ([Portail Microsoft Entra ID (Azure AD)](https://aad.portal.azure.com/): « Devices » - « All devices »).
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 [Validation Intune](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-revokecertificatesonwipe)).
3. **Les deux annuaires**: exécuter les actions pour Microsoft Entra ID (Azure AD) **et** Intune comme décrit.

{% hint style="info" %}
Pour plus de détails sur les annuaires d’appareils, veuillez lire l’article [Répertoires des appareils](/fr/configuration-de-scepman/device-directories.md).
{% endhint %}

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 **Désactiver**

Ensuite, saisissez à nouveau la commande suivante :

```
certutil -verifyStore MY
```

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

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-42dfe633eca8d878a1bce1a117ef10e83ec46734%2Fscepman_revocation3%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\).png?alt=media)

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

{% hint style="info" %}
Cela peut prendre jusqu’à 5 minutes avant que l’invite « Marqué comme valide » apparaisse.
{% endhint %}

### 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 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 d’hôte 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 :

![](https://129332256-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-73190ac3e2e77c25974776ffa48e74b2c33f96da%2Fcisco-ocsp-error%20\(2\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(2\)%20\(1\).jpg?alt=media)

*Solution* : veuillez consulter [ici](/fr/autres/troubleshooting/cisco-ise-host-header-limitation.md).

### 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 met accidentellement l’ID d’appareil Intune dans le certificat au lieu de l’ID d’appareil AAD dans certains cas aléatoires, bien que vous configuriez la variable dans le profil de configuration SCEP. SCEPman ne peut alors pas trouver d’appareil 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) pour la méthode d’inscription des appareils dédiés détenus par 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é détenu par l’entreprise`, vous ne serez pas concerné par le problème. Intune mettra 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’inscription, allez dans les [paramètres d’inscription Android du centre d’administration Microsoft Endpoint Manager](https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesAndroidMenu/androidEnrollment) et choisissez `Appareil dédié détenu par l’entreprise (par défaut)` au lieu de `Appareil dédié détenu par l’entreprise avec le mode partagé Azure AD`. Veuillez vous référer à la [documentation Microsoft](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) 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 la page d’accueil de votre SCEPman affiche une étiquette rouge « Not Connected » pour la connectivité du Storage Account, il est possible que l’identité managée de l’App Service SCEPman (et peut-être celle du SCEPman Certificate Master) n’ait pas les autorisations nécessaires 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 une mise à niveau d’une version Community Edition vers Enterprise Edition -- dans ce cas, le problème d’autorisation existait déjà, mais la version 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 affectations de rôle peuvent être effectuées manuellement dans Azure Portal sous « Access Control (IAM) » dans le Storage Account. Sinon, exécutez simplement [à nouveau le CMDlet d’installation SCEPman à partir du module PowerShell SCEPman](/fr/deploiement-de-scepman/permissions/post-installation-config.md#running-the-scepman-installation-cmdlet).

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

Vérifiez vos variables d’environnement SCEPman pour voir ce qui est configuré pour [AppConfig:UseRequestedKeyUsages](/fr/configuration-de-scepman/application-settings/certificates.md#appconfig-userequestedkeyusages). S’il n’est pas défini, la valeur par défaut est « false ».

Les nouvelles installations le définiront automatiquement sur « true » ; toutefois, les anciennes installations SCEPman ont cette valeur à false. Les mises à jour SCEPman ne modifient aucun comportement, sauf pour des correctifs ou des changements qui n’ont en aucun cas d’inconvénient. Lorsque cette valeur est false, les EKU et usages de clé demandés sont ignorés.<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.scepman.com/fr/autres/troubleshooting/general.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
