> 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 {% hint style="warning" %} Impossible de se connecter, car vous avez besoin d’un certificat pour vous authentifier. Contactez votre interlocuteur du support informatique. {% endhint %} ![](/files/7956ad4861482bd9b275d9b3d3c941a54e74b99d) Vérifiez que votre client possède un certificat pour s’authentifier et que vous utilisez le bon [profil de configuration Wi-Fi](/fr/deploiement-des-profils/microsoft-intune/wifi-profile.md) ou [XML](/fr/portail-dadministration/settings/trusted-roots.md#xml). #### Problèmes liés au certificat racine de confiance {% hint style="warning" %} Impossible de se connecter à ce réseau. {% endhint %} ![](/files/a4fc698076718956cb72ddfc85dbdcadf71de916) Vérifiez que vous avez effectué les actions suivantes : * 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 de confiance 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 y a 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 le Wi-Fi d’entreprise à cet endroit, poursuivez la connexion. Sinon, il peut s’agir d’un autre réseau portant le même nom. Afficher les détails du certificat. {% endhint %} Si vos clients doivent effectuer une vérification lors de la première connexion et que cette boîte de dialogue s’affiche : ![](/files/b8f75f831e0e1ccfe3c0b84e886bc5d42a6cc654) Assurez-vous d’avoir référencé le certificat du serveur RADIUS dans votre profil Wi-Fi et fourni l’attribut SAN du certificat serveur (FQDN) ainsi que le nom commun (CN) :

Affichage de l’attribut SAN du certificat serveur (FQDN) et du nom commun (CN)

### Vue serveur #### AC inconnue Si vos [journaux](/fr/portail-dadministration/insights/log.md#logs) contiennent des messages d’erreur semblables à ceux 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/] (from client contoso port 1 cli 18-9K-EA-0H-7F-C5) ``` cela peut avoir les causes profondes suivantes : * Erreur renvoyée par le client `TLS Alert read:fatal:unknown CA` * Votre client ne connaît pas le **certificat du serveur** et rejette la connexion. Vérifiez que vous avez ajouté votre **certificat du 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 du serveur** et votre profil XML sur le client utilise l’ancien. Dans ce cas, veuillez vérifier à nouveau que vous avez mis à jour votre profil Wi-Fi/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é sur vos clients. * Le serveur renvoie une erreur `TLS Alert write:fatal:unknown CA` * Votre serveur RADIUS ne connaît pas l’émetteur du certificat utilisé pour l’authentification. Ajoutez votre AC comme décrit [ici](/fr/portail-dadministration/settings/trusted-roots.md#add). #### Certificat inconnu Si vous utilisez macOS (et peut-être d’autres plateformes Apple) et si vos [journaux](/fr/portail-dadministration/insights/log.md#logs) contiennent des messages d’erreur semblables à celui ci-dessous ``` eap_tls: (TLS) TLS - Alert read:fatal:certificate unknown ``` cela peut avoir les causes profondes suivantes : * Il y a un caractère espace quelque part dans le **Nom du serveur du certificat** dans votre [Wi-Fi](/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 semblables à ceux ci-dessous ``` Auth: (312) Login incorrect (eap_tls: TLS Alert write:fatal:decrypt error): [host/00128t09-cbna-469c-9768-2783d28eikl9/] (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 bug du logiciel TPM sur vos machines Windows. Vous trouverez plus d’informations à ce sujet 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 Wi-Fi 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 [**KSP logiciel**](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail). {% hint style="warning" %} Le paramètre Key Storage Provider (KSP) détermine l’emplacement de stockage de la clé privée des certificats 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 anciennes du micrologiciel TPM** qui invalide certaines signatures créées avec une clé privée prise en charge par TPM. Dans de tels 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 micrologiciel TPM concernées comprennent : * 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 / Specification 1.2 Si vous utilisez TPM avec ce micrologiciel, mettez à jour votre micrologiciel vers une version plus récente ou sélectionnez "KSP logiciel" comme fournisseur de stockage de clés. {% endhint %} #### Impossible de continuer, car le pair se comporte de manière anormale Si vos journaux contiennent des refus avec l’erreur *"Impossible de continuer, car le pair se comporte de manière anormale"* 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 partagé RADIUS incorrect Si votre (proxy) [journaux](/fr/portail-dadministration/insights/log.md#logs) contiennent des messages d’erreur semblables à ceux ci-dessous ``` - authentificateur de message, valeur incorrecte - buf2radmsg: l’authentification du message a échoué - radsrv: requête ignorée depuis default (8.222.246.231), validation échouée ``` alors l’un de vos points d’accès ou commutateurs qui essaie 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 `proxyip` propriété. Maintenant que vous connaissez le proxy, utilisez votre inventaire et votre connaissance des emplacements ou groupes d’appareils spécifiques 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. ### Dépannage 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 ne fournissent d’indication claire sur 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 resteraient 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. Faites un clic 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 connexion. Essayez maintenant de vous connecter au réseau Wi-Fi ou filaire, puis passez à l’étape suivante. > **Conseil :** Désactivez à nouveau le journal après avoir collecté les données (**clic droit sur Opérationnel → Désactiver le journal**) afin d’éviter une utilisation inutile du disque. *** #### **Étape 2 : localiser les événements pertinents** Après avoir reproduit le problème, recherchez les événements dans les sources de journal 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 comprennent : * **CAPI2** — les 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 (p. ex. les ID d’événement 11, 70, 90). * **WLAN-AutoConfig** — les événements décrivant le résultat de la négociation 802.1X (p. ex. les ID d’événement 8001, 8002, 12013). *** #### **Étape 3 : exporter et envoyer les journaux** Pour nous envoyer les journaux à examiner : 1. Dans l’Observateur d’événements, faites un clic droit sur le **Opérationnel** journal sous **CAPI2** et sélectionnez **Enregistrer tous les événements sous…** 2. Enregistrez le fichier comme **fichier Journal d’événements (\*.evtx)** et nommez-le de manière explicite, par exemple `CAPI2__.evtx`. 3. Répétez les mêmes étapes pour le journal **WLAN-AutoConfig → Opérationnel** . 4. Envoyez les deux `.evtx` fichiers à notre équipe support à accompagnés d’une brève description de l’appareil concerné, de la version de l’OS 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
Lorsque vous souhaitez utiliser votre propre certificat serveur, votre serveur RADIUS a besoin de 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-collez soit le certificat CA sous le certificat serveur dans le champ de texte, soit créez un bundle de certificats PCKS8 qui inclut tous les certificats de la chaîne jusqu’à la racine. ## Problèmes du portail administrateur ### Connexion Pour vous connecter au portail web RADIUSaaS ("RADIUSaas Admin Portal"), les conditions suivantes doivent être remplies : * L’adresse UPN/e-mail que vous avez fournie en tant qu’administrateur technique doit pouvoir être authentifiée auprès de **certain** 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 en tant qu’administrateur technique doit avoir été enregistrée sur votre instance RADIUSaaS comme décrit [ici](/fr/portail-dadministration/settings/permissions.md). Dans le cas où 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 donné accès (autoriser la demande de jeton d’actualisation)\ ![](/files/dca5551d28bf84af4be02b1f5333a2617156f9e2) * Dans le cas où 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 ### Affectation du profil La configuration Wi-Fi ne se déploie pas si les profils Wi-Fi, SCEP et certificat de confiance sont affectés à des groupes différents. Ils peuvent apparaître comme « En attente » ou n’avoir aucun état du tout. Veuillez utiliser le **même groupe ou « Tous les appareils » resp. « Tous les utilisateurs »** pour **tous les profils liés**. Vous pouvez affecter le profil de certificat racine SCEP à la fois à « Tous les utilisateurs » et à « Tous les appareils » si vous utilisez un certificat d’appareil (affecté à « Tous les appareils ») et un certificat utilisateur (affecté à « Tous les utilisateurs »). ### certificat SCEP #### Android Android semble nécessiter 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) :
### profil Wi-Fi #### Android Codes d’erreur courants : 0xc7d24fc5 ou -942518331 Les points clés sont les suivants : * sélectionnez le **certificat CA racine** pour **validation du serveur** (important : ne téléversez pas le certificat serveur de RADIUSaaS)\ \&#xNAN;**- et -** * définissez un **nom du 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 »). * [Les développeurs Android](https://developer.android.com/guide/topics/connectivity/wifi-enterprise) indiquent : « \[...] doit configurer **à la fois un certificat CA racine**, et soit un **correspondance du 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 **la 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radiusaas.com/fr/autre/troubleshooting.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.