Dépannage
Problèmes de connexion
Vue client
XML incorrect
Impossible de se connecter, car vous avez besoin d’un certificat pour vous authentifier. Contactez votre interlocuteur du support informatique.
Vérifiez que votre client possède un certificat pour s’authentifier et que vous utilisez le bon profil de configuration Wi-Fi ou XML.
Problèmes liés au certificat racine de confiance
Impossible de se connecter à ce réseau.
Vérifiez que vous avez effectué les actions suivantes :
Indiqué à votre serveur RADIUS quels certificats sont autorisés à se connecter, comme décrit ici
Importé le certificat actif du serveur RADIUS comme racine de confiance sur votre client, comme décrit ici
Continuer la connexion ?
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.
Si vos clients doivent effectuer une vérification lors de la première connexion et que cette boîte de dialogue s’affiche :
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) :
Vue serveur
AC inconnue
Si vos journaux contiennent des messages d’erreur semblables à ceux ci-dessous
cela peut avoir les causes profondes suivantes :
Erreur renvoyée par le client
TLS Alert read:fatal:unknown CAVotre 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.
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 après avoir ajouté les certificats et l’avoir déployé sur vos clients.
Le serveur renvoie une erreur
TLS Alert write:fatal:unknown CAVotre serveur RADIUS ne connaît pas l’émetteur du certificat utilisé pour l’authentification. Ajoutez votre AC comme décrit ici.
Certificat inconnu
Si vous utilisez macOS (et peut-être d’autres plateformes Apple) et si vos journaux contiennent des messages d’erreur semblables à celui ci-dessous
cela peut avoir les causes profondes suivantes :
Erreur de déchiffrement | Accès refusé
Si vos journaux contiennent des messages d’erreur semblables à ceux ci-dessous
... 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.
Si vous voyez quelque chose comme ceci dans vos journaux
... 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.
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.
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 contiennent des messages d’erreur semblables à ceux ci-dessous
alors l’un de vos points d’accès ou commutateurs qui essaie de se connecter à votre instance RADIUSaaS via un Proxy RADIUS utilise un Secret partagé.
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 :
Ouvrez Observateur d’événements : appuyez sur Win + R, tapez
eventvwr.exe, puis appuyez sur Entrée.Dans l’arborescence de gauche, développez Journaux des applications et des services.
Développez Microsoft → Windows → CAPI2.
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 :
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 :
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…
Enregistrez le fichier comme fichier Journal d’événements (*.evtx) et nommez-le de manière explicite, par exemple
CAPI2_<nom_de_l’appareil>_<date>.evtx.Répétez les mêmes étapes pour le journal WLAN-AutoConfig → Opérationnel .
Envoyez les deux
.evtxfichiers à notre équipe support à https://www.radius-as-a-service.com/help/ 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. Dans le cas où il s’agit de l’administrateur initial, veuillez nous contacter 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)
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) - 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 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)
Mis à jour
Ce contenu vous a-t-il été utile ?