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

# Dépannage

## Problèmes de connexion

### Vue client

#### XML incorrect&#x20;

{% hint style="warning" %}
Impossible de se connecter car vous avez besoin d'un certificat pour vous connecter. Contactez votre support informatique.
{% endhint %}

![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/k8FhkMHpqVOne7UXpLzC/image.png)

Vérifiez que votre client dispose d'un certificat pour s'authentifier et que vous utilisez le bon [profil de configuration WiFi](/fr/deploiement-des-profils/microsoft-intune/wifi-profile.md) ou [XML](/fr/portail-dadministration/settings/trusted-roots.md#xml).

#### Problèmes de racine approuvée&#x20;

{% hint style="warning" %}
Impossible de se connecter à ce réseau.
{% endhint %}

![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/g3XbpcPNSLDJPrr96nYr/image.png)

Vérifiez que vous avez effectué les opérations suivantes :&#x20;

* Indiqué à votre serveur RADIUS quels certificats sont autorisés à se connecter, comme décrit [ici](/fr/portail-dadministration/settings/trusted-roots.md#add)
* Importé le certificat actif du serveur RADIUS comme racine approuvée sur votre client, comme décrit [ici](/fr/deploiement-des-profils/microsoft-intune/trusted-root.md#to-add-a-trusted-root-profile-for-your-clients)
* Vérifiez vos [Journaux](/fr/portail-dadministration/insights/log.md#logs). Il existe une description détaillée de l'erreur. Peut-être s'agit-il de [ce](/fr/autre/troubleshooting.md#fatal-decrypt-error) problème.

#### Continuer la connexion ?

{% hint style="warning" %}
Continuer la connexion ? \
Si vous vous attendez à trouver Corporate WiFi dans cet emplacement, poursuivez et connectez-vous. Sinon, il peut s'agir d'un autre réseau portant le même nom.&#x20;

Afficher les détails du certificat.
{% endhint %}

Si vos clients doivent vérifier lors de la première connexion et que cette boîte de dialogue s'affiche :

![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/8uYG1oXtvKS2IJkLbQyL/image.png)

Assurez-vous d'avoir référencé le certificat du serveur RADIUS dans votre profil WiFi et fourni l'attribut SAN (FQDN) et le nom commun (CN) du certificat du serveur :

<figure><img src="https://1168716614-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FnGm2WIeddAuswGilqRcF%2Fimage.png?alt=media&amp;token=a5186af0-375c-4fc7-a2fe-24741adf14d7" alt=""><figcaption><p>Affichage de l'attribut SAN (FQDN) et du nom commun (CN) du certificat du serveur</p></figcaption></figure>

### Vue serveur

#### CA inconnue

Si vos [Journaux](/fr/portail-dadministration/insights/log.md#logs) contiennent des messages d'erreur similaires à ceux affichés ci-dessous

```
ERROR: (14872) eap_tls: ERROR: SSL says error 20 : unable to get local issuer certificate
ERROR: (14872) eap_tls: ERROR: TLS Alert write:fatal:unknown CA
Error: tls: TLS_accept: Error in error
Auth: (14872) Login incorrect (eap_tls: SSL says error 20 : unable to get local issuer certificate): [host/8dc38402-20fb-41db-a8f3-4e4e95637173/<via Auth-Type = eap>] (from client contoso port 1 cli 18-9K-EA-0H-7F-C5)
```

elle peut avoir les causes profondes suivantes :&#x20;

* Le client renvoie l'erreur `TLS Alert read:fatal:unknown CA`
  * Votre client ne connaît pas le **certificat serveur** et rejette la connexion. Vérifiez que vous avez ajouté votre **certificat serveur** comme décrit [ici](/fr/deploiement-des-profils/microsoft-intune/trusted-root.md#adding-a-trusted-root-profile-for-your-clients).
  * Vous avez modifié/ajouté un nouveau **certificat serveur** et votre profil XML sur le client utilise l'ancien. Dans ce cas, veuillez vérifier que vous avez bien mis à jour votre profil WiFi/Filaire ou régénéré votre [XML](/fr/portail-dadministration/settings/trusted-roots.md#xml) après avoir ajouté les certificats et l'avoir déployé auprès de vos clients.&#x20;
* Le serveur renvoie l'erreur `TLS Alert write:fatal:unknown CA`
  * Votre serveur RADIUS ne connaît pas l'émetteur du certificat utilisé pour l'authentification. Ajoutez votre CA comme décrit [ici](/fr/portail-dadministration/settings/trusted-roots.md#add).

#### Certificat inconnu

Si vous utilisez macOS (et éventuellement d'autres plateformes Apple) et si vos [Journaux](/fr/portail-dadministration/insights/log.md#logs) contiennent des messages d'erreur similaires à celui affiché ci-dessous

```
eap_tls: (TLS) TLS - Alert read:fatal:certificate unknown
```

elle peut avoir les causes profondes suivantes :

* Il y a un caractère espace quelque part dans le **Nom du serveur de certificat** dans votre [WiFi](/fr/deploiement-des-profils/microsoft-intune/wifi-profile/apple-devices.md) ou [Filaire](/fr/deploiement-des-profils/microsoft-intune/wired-profile/mac.md) profil de configuration.

#### Erreur de déchiffrement | Accès refusé

Si vos [Journaux](/fr/portail-dadministration/insights/log.md#logs) contiennent des messages d'erreur similaires à ceux affichés ci-dessous

```
Auth: (312) Login incorrect (eap_tls: TLS Alert write:fatal:decrypt error): [host/00128t09-cbna-469c-9768-2783d28eikl9/<via Auth-Type = eap>] (from client contoso port 1 cli 84-FD-D1-8C-0E-33)
ERROR: (320) eap_tls: ERROR: TLS Alert write:fatal:decrypt error
Error: tls: TLS_accept: Error in error
```

... alors il s'agit probablement d'un bogue du logiciel TPM sur vos machines Windows. Vous trouverez plus d'informations dans la [documentation SCEPman](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail).

Si vous voyez quelque chose comme ceci dans vos [Journaux](/fr/portail-dadministration/insights/log.md#logs)

```
ERROR: (95878) eap_tls: ERROR: (TLS) Alert read:fatal:access denied
Auth: (95878) Login incorrect (eap_tls: (TLS) Alert read:fatal:access denied): [host/kad933-161d-4aa8-aeaa-b5a4d3d53b12]
ERROR: (95717) eap_tls: ERROR: (TLS) Alert read:fatal:access denied
```

... il peut y avoir deux raisons. L'une est que votre profil WiFi référence le mauvais certificat racine pour la validation du serveur. Veuillez vous assurer que votre profil est correctement configuré. Si c'est le cas et que vous rencontrez toujours ce problème, essayez de définir votre KSP sur [**Software KSP**](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail).&#x20;

{% hint style="warning" %}
Le paramètre Key Storage Provider (KSP) détermine l'emplacement de stockage de la clé privée pour les certificats de l'utilisateur final. Le stockage dans le TPM est plus sûr que le stockage logiciel, car le TPM fournit une couche de sécurité supplémentaire pour empêcher le vol de clés. Cependant, il existe **un bogue dans certaines versions plus anciennes du microprogramme TPM** qui invalide certaines signatures créées avec une clé privée hébergée par le TPM. Dans ce cas, le certificat ne peut pas être utilisé pour l'authentification EAP, comme c'est courant pour les connexions Wi-Fi et VPN. Les versions de microprogramme TPM concernées incluent :

* STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100
* Intel: 11.8.50.3399, 2.0.0.2060
* Infineon: 7.63.3353.0
* IFX: Version 3.19 / Spécification 1.2

Si vous utilisez le TPM avec ce microprogramme, mettez à jour votre microprogramme vers une version plus récente ou sélectionnez "Software KSP" comme fournisseur de stockage de clés.
{% endhint %}

#### Impossible de continuer, car le pair a un comportement défaillant

Si vos Journaux contiennent des refus avec l'erreur *"Impossible de continuer, car le pair a un comportement défaillant"*  cela indique que le client a cessé de communiquer avec le service RADIUS, le plus souvent parce que les paramètres de confiance sont incorrects. Dans ce cas, veuillez vérifier les certificats sur les appareils concernés.

#### Secret RADIUS partagé incorrect

Si votre (proxy) [Journaux](/fr/portail-dadministration/insights/log.md#logs) contiennent des messages d'erreur similaires à ceux affichés ci-dessous

```
- authentificateur de message, valeur incorrecte
- buf2radmsg : l'authentification du message a échoué
- radsrv : requête ignorée de default (8.222.246.231), échec de la validation
```

alors l'un de vos points d'accès ou commutateurs qui tente de se connecter à votre instance RADIUSaaS via un [proxy RADIUS](/fr/portail-dadministration/settings/settings-proxy.md) utilise un [Secret partagé](/fr/portail-dadministration/settings/settings-server.md#properties-1).

Pour identifier le point d'accès ou le commutateur concerné, déterminez d'abord le proxy RADIUS en développant le message d'erreur et en recherchant la propriété `proxyip` . Maintenant que vous connaissez le proxy, utilisez votre inventaire et votre connaissance des emplacements ou groupes spécifiques d'appareils qui ne peuvent pas se connecter à votre réseau pour identifier l'appareil réseau mal configuré. Enfin, mettez à jour le secret partagé afin qu'il corresponde à la valeur configurée dans votre instance RADIUSaaS pour ce proxy.

### Résolution des problèmes de connexion avec les journaux CAPI2

Les clients Windows utilisent le **API cryptographique (CAPI2)** sous-système pour gérer les opérations de certificat pendant l'authentification EAP-TLS. Lorsqu'une connexion échoue et que ni l'interface utilisateur du client ni les journaux du serveur RADIUSaaS n'indiquent clairement la cause racine, l'activation de la journalisation CAPI2 sur l'appareil concerné peut révéler des échecs de validation de certificat, des erreurs de construction de chaîne ou des problèmes d'accès à la clé privée qui seraient autrement invisibles.

***

#### **Étape 1 : Activer la journalisation CAPI2**

La journalisation CAPI2 est désactivée par défaut. Pour l'activer :

1. Ouvrez **Observateur d'événements**: appuyez sur **Win + R**, tapez `eventvwr.exe`, puis appuyez sur **Entrée**.
2. Dans l'arborescence de gauche, développez **Journaux des applications et des services**.
3. Développez **Microsoft → Windows → CAPI2**.
4. Cliquez avec le bouton droit sur **Opérationnel** et sélectionnez **Activer le journal**.

Une fois activé, Windows commencera à enregistrer tous les événements CAPI2. Reproduisez l'échec de la connexion. Essayez maintenant de vous connecter au réseau Wi-Fi ou filaire, puis passez à l'étape suivante.

> **Astuce :** Désactivez à nouveau le journal après avoir collecté les données (**cliquez avec le bouton droit sur Opérationnel → Désactiver le journal**) afin d'éviter une utilisation inutile de l'espace disque.

***

#### **Étape 2 : Localiser les événements pertinents**

Après avoir reproduit le problème, recherchez les événements dans les sources de journaux suivantes :

| Source du journal   | Chemin dans l'Observateur d'événements                                                           |
| ------------------- | ------------------------------------------------------------------------------------------------ |
| **CAPI2**           | Journaux des applications et des services → Microsoft → Windows → CAPI2 → Opérationnel           |
| **WLAN AutoConfig** | Journaux des applications et des services → Microsoft → Windows → WLAN-AutoConfig → Opérationnel |

Concentrez-vous sur les événements enregistrés **au moment de la tentative de connexion échouée**. Les indicateurs utiles incluent :

* **CAPI2** — erreurs liées à la construction de la chaîne de certificats, aux vérifications de révocation ou à l'accès à la clé privée (par exemple, IDs d'événements 11, 70, 90).
* **WLAN-AutoConfig** — événements décrivant le résultat de la négociation 802.1X (par exemple, IDs d'événements 8001, 8002, 12013).

***

#### **Étape 3 : Exporter et envoyer les journaux**

Pour nous envoyer les journaux à examiner :

1. Dans l'Observateur d'événements, cliquez avec le bouton droit sur le **Opérationnel** journal sous **CAPI2** et sélectionnez **Enregistrer tous les événements sous…**
2. Enregistrez le fichier en tant que **journal d'événements (\*.evtx)** et nommez-le de manière descriptive, par exemple `CAPI2_<device-name>_<date>.evtx`.
3. Répétez les mêmes étapes pour le **WLAN-AutoConfig → Opérationnel** journal.
4. Envoyez les deux `.evtx` fichiers à notre équipe d'assistance à <https://www.radius-as-a-service.com/help/> ainsi qu'une brève description de l'appareil concerné, de la version du système d'exploitation et du moment où le problème se produit.

## Problèmes de certificat

### La chaîne de certificats n'a pas pu être vérifiée

<figure><img src="https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/4S5eHRu1C0h4kGOUJlzl/image.png" alt=""><figcaption></figcaption></figure>

Quand vous souhaitez utiliser votre propre certificat serveur, votre serveur RADIUS nécessite la chaîne de certificats complète afin de permettre aux autres participants (Proxy, clients RadSec, points de terminaison qui tentent de se connecter) de vérifier l'identité du serveur.  \
Si vous voyez ce message, copiez et collez soit le certificat CA sous le certificat serveur dans le champ de texte, soit créez un ensemble de certificats PCKS8 qui inclut tous les certificats de la feuille jusqu'à la racine.

## Problèmes du portail d'administration

### Connexion

Pour vous connecter au portail web RADIUSaaS ("RADIUSaas Admin Portal"), les exigences suivantes doivent être remplies :

* L'adresse UPN/e-mail que vous avez fournie comme administrateur technique doit pouvoir être authentifiée auprès de **un** Microsoft Entra ID (Azure AD) (il n'est pas nécessaire qu'il s'agisse d'une identité du Tenant dont les utilisateurs utiliseront RADIUSaaS pour l'authentification réseau).
* L'adresse UPN/e-mail que vous avez fournie comme administrateur technique doit avoir été enregistrée sur votre instance RADIUSaaS comme décrit [ici](/fr/portail-dadministration/acces-et-regles/permissions.md). S'il s'agit de l'administrateur initial, veuillez [nous contacter](https://www.radius-as-a-service.com/help/) si vous pensez que nous avons enregistré le mauvais utilisateur.
* L'objet utilisateur Microsoft Entra ID (Azure AD) derrière l'adresse UPN/e-mail doit être autorisé à accorder à l'application d'entreprise RADIUSaaS les autorisations suivantes (voir la capture d'écran ci-dessous) :
  * **Lire** le profil utilisateur de base
  * **Maintenir** l'accès aux données auxquelles vous lui avez accordé l'accès (autoriser la demande de jeton d'actualisation)\
    ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/zBRh87CJ75R1N8hz7mZF/Screenshot_2022-04-11_at_09_31_26.png)
* Si votre utilisateur Microsoft Entra ID (Azure AD) n'a pas les droits pour accorder les autorisations requises, aucune **application d'entreprise** ne sera créée automatiquement dans votre Microsoft Entra ID (Azure AD). Pour contourner cela, demandez à votre service informatique d'accorder à votre utilisateur les autorisations nécessaires.

## Problèmes de configuration Intune

### Attribution de profil

La configuration Wi-Fi n'est pas déployée si les profils Wi-Fi, SCEP et certificat approuvé sont attribués à différents groupes. Ils peuvent apparaître comme « En attente » ou il n'y a aucun statut du tout. Veuillez utiliser le **même groupe ou « Tous les appareils » resp. « Tous les utilisateurs »** pour **tous les profils liés**.

Vous pouvez attribuer le profil de certificat racine SCEP à la fois à « Tous les utilisateurs » et à « Tous les appareils » si vous utilisez un certificat d'appareil (attribué à « Tous les appareils ») et un certificat utilisateur (attribué à « Tous les utilisateurs »).

### certificat SCEP

#### Android

Android semble exiger un UPN dans le nom alternatif du sujet dans les versions récentes (même pour les certificats d'appareil). Veuillez l'ajouter dans votre profil SCEP (par ex. {{DeviceId}}@contoso.com) :

<figure><img src="https://1168716614-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FvzOjRbRuXtYp866efU2w%2Fimage.png?alt=media&amp;token=9180ae03-2a52-4dbc-b2f8-cba97afb8af7" alt=""><figcaption></figcaption></figure>

### profil Wi-Fi

#### Android

Codes d'erreur courants : 0xc7d24fc5 ou -942518331

Les points clés sont :

* sélectionnez le **certificat CA racine** pour **validation du serveur** (important : ne téléversez pas le certificat serveur de RADIUSaaS)\
  **- et -**
* définissez un **nom de serveur RADIUS**
  * Remarque : il semble y avoir une limite de caractères pour ce champ. Pour résoudre d'éventuels problèmes, vous pouvez simplement utiliser la partie domaine sans sous-domaine, comme « radius-as-a-service.com » (au lieu de « contoso.radius-as-a-service.com »).
  * [Développeurs Android](https://developer.android.com/guide/topics/connectivity/wifi-enterprise) indique : « \[...] doit configurer **à la fois un certificat CA racine**, et soit un **correspondance de suffixe de domaine** ou une correspondance de sujet alternative » . Ainsi, le MDM peut utiliser « setAltSubjectMatch » ou « setDomainSuffixMatch » après avoir ajouté un certificat racine à la configuration Wi-Fi. Intune semble utiliser « setDomainSuffixMatch » car « radius-as-a-service.com » suffit.
* parfois **confidentialité de l'identité** est nécessaire (par ex. observée sur les appareils kiosque Android / Android Enterprise dédiés)


---

# 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.radiusaas.com/fr/autre/troubleshooting.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.
