# Problèmes courants

## Problèmes au 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 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](https://docs.scepman.com/fr/configuration-de-scepman/application-artifacts#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 antérieures de cette documentation redirige vers une autre URL. Microsoft a changé le comportement de certaines de leurs Web Apps et maintenant 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 SCEPman Azure ne fonctionne pas

Vérifiez si la ressource Azure est active et fonctionne.

![](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\).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 la pile. Même si la pile est .NET, la version de .NET peut ne pas correspondre à ce que vous attendez pour votre version de SCEPman, par exemple .NET 8 pour SCEPman 2.8.

Ceci s'explique par le 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 mettons à jour SCEPman vers une nouvelle version de .NET que lorsque cette version fait partie de cet ensemble de versions .NET automatiquement installées. Nous procédons ainsi parce que notre mécanisme de mise à jour via [WEBSITE\_RUN\_FROM\_PACKAGE ](https://docs.scepman.com/fr/configuration-de-scepman/application-settings/basics#website_run_from_package)ne nous donne aucun contrôle sur le paramètre de version .NET. Par conséquent, en pratique, peu importe ce qui est configuré comme version de .NET.

### Mon App Service SCEPman ne fonctionnait pas le 2024-11-27 et il a complètement cessé de fonctionner depuis le 2024-12-16 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 2024-11-27, nous avons temporairement désactivé l'ancien emplacement pour informer les utilisateurs de l'arrêt définitif prévu le lundi 2024-12-16.

Si vous êtes concerné, vérifiez votre paramètre WEBSITE\_RUN\_FROM\_PACKAGE et [mettez à jour la valeur](https://docs.scepman.com/fr/configuration-de-scepman/application-artifacts) vers le nouvel emplacement du paquet. Cela mettra également à jour votre version de SCEPman de la 1.8 vers la dernière version, apportant [de nombreuses améliorations](https://docs.scepman.com/fr/changelog) avec une compatibilité rétroactive complète.

Si vous n'êtes pas sûr d'utiliser le dernier dépôt, 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 cela fait déjà 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&#x26;token=b9ed1f6f-ce4f-4745-b30b-9b01c518997c" alt=""><figcaption><p>SCEPman utilise l'ancien emplacement de paquet pour WEBSITE_RUN_FROM_PACKAGE</p></figcaption></figure>

## Problèmes d'émission de certificats

### Le certificat racine de confiance est déployé mais mon certificat de périphérique 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 arriver lorsqu'un mauvais certificat racine de confiance a été sélectionné dans le profil de certificat SCEP. Cela est également affiché dans le journal des événements :

1. Ouvrez l'application Événements Windows
2. Cliquez sur **Journaux d'applications et de 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 apparaîtra, 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'enrôlement 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\).png?alt=media)

Si vous utilisez une CA intermédiaire, notez que vous devez [sélectionner le certificat de la CA intermédiaire](https://docs.scepman.com/fr/deploiement-de-scepman/intermediate-certificate#intermediate-cas-and-intune-scep-profiles) et non le certificat de la CA racine dans le profil de configuration SCEP ! Notez que cela est spécifique à la plateforme Windows et par exemple Android exige de sélectionner le certificat de la CA racine dans le profil de configuration SCEP.

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

{% hint style="info" %}
Ceci est juste 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 manque un paramètre d'application important nommé **AppConfig:BaseUrl** réglé 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 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 d'appareils Azure Active Directory pour vous assurer que l'utilisateur ou l'appareil se recoupe et que les deux profils sont ciblés vers l'appareil. Ne mélangez pas des groupes d'utilisateurs et des groupes d'appareils. 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'enrôlent pas ou ne renouvellent pas les certificats

Vous pouvez vérifier à la fois du côté SCEPman et du 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 générer de 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 certificats](https://oliverkieselbach.com/2022/09/21/deep-dive-of-scep-certificate-request-renewal-on-intune-managed-windows-clients/) qui vous aide à localiser 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 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  : 02/07/2025 12:51:06
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 32
Message      : SCEP : l'enrôlement du certificat a échoué. Résultat : (Code d'erreur Win32 inconnu : 0x80072f8f).

TimeCreated  : 02/07/2025 12:51:06
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 307
Message      : SCEP : échec LogError Message : (SCEPInstallCertificateWithScepHelper : Échec de l'initialisation
               Enrôlement SCEP avec le serveur NDES
               'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe', empreinte du certificat de la CA
               '24C45EF4284A5093A9C3886A6466C1D6D84EE058' et certificats du serveur ''. LogError 0x80)
```

{% endcode %}

### Les appareils Windows 10 ne peuvent pas s'enrôler 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. Par défaut, les certificats sont datés 10 minutes dans le passé pour pallier de petits décalages d'horloge, mais nous avons récemment vu des appareils Windows 10 ayant jusqu'à 9 heures de retard.

Vous pouvez continuer l'enrôlement et une fois celui-ci terminé, l'appareil obtiendra un certificat avec succès, car l'horloge sera correcte alors. Vous pouvez également utiliser la nouvelle option [**AppConfig:ValidityClockSkewMinutes**](https://docs.scepman.com/fr/configuration-de-scepman/application-settings/certificates#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 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 recule la date du certificat d'un jour pour pallier les problèmes avec les appareils dont l'horloge est en retard, voir [Les appareils Windows 10 ne peuvent pas s'enrôler avec AutoPilot](#windows-10-devices-cannot-enroll-with-autopilot).

## Problèmes avec la 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
```

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

![](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épondant OCSP fonctionne, vous pouvez consulter le cache d'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\).png?alt=media)

#### Machine macOS

Pour vérifier la validité d'un certificat sur une machine macOS en utilisant OCSP, veuillez suivre ces étapes :

1. Exportez le certificat Root CA de SCEPman depuis **Trousseau d'accès (Keychain Access)** (**Trousseaux système > Racines système**) en fichier \*.cer et placez-le dans un dossier (alternativement, vous pouvez le télécharger depuis le site de votre instance SCEPman).
2. Exportez le certificat d'authentification client que vous souhaitez vérifier depuis **Trousseau d'accès (Keychain Access)** (**Trousseaux système > Système > Mes certificats**) en fichier \*.cer dans le même dossier.
3. Extrait l'URL du répondant OCSP depuis la propriété **Authority Information Access** (AIA) du certificat d'authentification client :

   <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&#x26;token=3c0ca083-8cb9-471f-a7ab-4a314337b585" alt=""><figcaption></figcaption></figure>
4. Ouvrez un **Terminal** session et `cd` dans le dossier qui contient les certificats exportés.
5. Exécutez la commande suivante :

```
openssl ocsp -issuer <nom-fichier-certificat-root-ca-scepman> -cert <nom-fichier-certificat-à-vérifier> -text -url <url-répondant-ocsp>
```

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&#x26;token=ee8e2761-e249-4bd1-ae82-0eac933363d2" alt=""><figcaption></figcaption></figure>

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

```
certutil -url <chemin-vers-certificat-appareil-exporté>
```

![](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\).png?alt=media)

### Révoquer un utilisateur

Si vous souhaitez révoquer un **utilisateur** certificat, 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 **appareil** certificat, vous avez plusieurs options selon [#appconfig-intunevalidation-devicedirectory](https://docs.scepman.com/fr/configuration-de-scepman/application-settings/points-de-terminaison-scep/intune-validation#appconfig-intunevalidation-devicedirectory "mention"):

1. Microsoft Entra ID (Azure AD) : Supprimer ou désactiver l'appareil ([Portail Microsoft Entra ID (Azure AD)](https://aad.portal.azure.com/) : « Appareils » - « Tous les appareils »).
2. **Intune** : Supprimez l'appareil ou déclenchez une action à distance (plusieurs états de gestion comme « WipePending » révoquent automatiquement les certificats comme indiqué sous [#appconfig-intunevalidation-revokecertificatesonwipe](https://docs.scepman.com/fr/configuration-de-scepman/application-settings/points-de-terminaison-scep/intune-validation#appconfig-intunevalidation-revokecertificatesonwipe "mention")).
3. **Les deux annuaires** : Exécutez 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 [device-directories](https://docs.scepman.com/fr/configuration-de-scepman/device-directories "mention").
{% 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 sur **Désactiver**

Ensuite, tapez à nouveau la commande suivante :

```
certutil -verifyStore MY
```

Comme vous pouvez le voir dans 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 tapez à nouveau la commande ci-dessus, le certificat devrait être marqué comme valide.

{% hint style="info" %}
Il peut s'écouler jusqu'à 5 minutes avant que l'invite « Marqué comme valide » n'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 par un paquet de réinitialisation TCP à la requête OCSP.

*Cause* : Tant Cisco ISE qu'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 :

![](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 voir [ici](https://docs.scepman.com/fr/autre/troubleshooting/cisco-ise-host-header-limitation).

### 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 accident l'ID de périphérique Intune dans le certificat au lieu de l'ID d'appareil AAD dans des 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 n'arrive que 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 d'appareil 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](https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesAndroidMenu/androidEnrollment) et choisissez `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](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) 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 concerné.

### Mon compte de stockage 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 compte de stockage, il est possible que l'identité géré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 arrive 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 édition Community vers l'édition Enterprise -- dans ce cas, le problème d'autorisation existait auparavant, mais l'édition Community ne le vérifiait pas.

Pour corriger cela, vous devez accorder à l'identité géré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 affectations 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 SCEPman depuis le module PowerShell SCEPman](https://docs.scepman.com/fr/deploiement-de-scepman/permissions/post-installation-config#running-the-scepman-installation-cmdlet).

## SCEPman n'émettra pas de certificats avec des EKU autres que Authentification du client

Vérifiez vos variables d'environnement SCEPman pour voir ce qui est configuré pour [AppConfig:UseRequestedKeyUsages](https://docs.scepman.com/fr/configuration-de-scepman/application-settings/certificates#appconfig-userequestedkeyusages). Si ce n'est pas défini, la valeur par défaut est « false ».&#x20;

Les nouvelles installations définiront automatiquement ceci sur « true », cependant les anciennes installations de SCEPman ont ceci défini à false. Les mises à jour de SCEPman ne changent aucun comportement sauf pour des corrections ou des modifications qui en aucune circonstance constituent un désavantage. Lorsque ceci est défini sur false, les EKU et usages de clé demandés sont ignorés.<br>
