Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
Dans la documentation de ce produit, les auteurs s‘efforcent d‘utiliser un langage exempt de préjugés. Aux fins de cet ensemble de documents, l’expression « sans préjugés » est définie comme un langage sans discrimination fondée sur l’âge, le handicap, le sexe, l’identité raciale, l’identité ethnique, l’orientation sexuelle, la situation socio-économique et l’intersectionnalité. Des exceptions peuvent être présentes dans la documentation en raison de la langue codée en dur dans les interfaces utilisateur du logiciel du produit, de la langue utilisée en fonction de la documentation de l’appel d’offres ou de la langue utilisée par un produit tiers référencé. En savoir plus sur la façon dont Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les processus d'authentification Web sur un contrôleur de réseau local sans fil (WLC).
Cisco vous recommande d'avoir une connaissance de base de la configuration du WLC.
Les informations de ce document sont basées sur tous les modèles matériels WLC.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
L'authentification Web (WebAuth) est la sécurité de couche 3. Il permet une sécurité conviviale qui fonctionne sur n'importe quelle station qui exécute un navigateur. Il peut également être combiné avec n'importe quelle sécurité de clé prépartagée (PSK) (stratégie de sécurité de couche 2). Bien que la combinaison de WebAuth et de PSK réduise considérablement la partie conviviale et ne soit pas utilisée souvent, elle a l'avantage de chiffrer le trafic client. WebAuth est une méthode d'authentification sans chiffrement.
WebAuth ne peut pas être configuré avec 802.1x/RADIUS (Remote Authentication Dial-In User Service) tant que le logiciel WLC version 7.4 n'est pas installé où il peut être configuré en même temps. Cependant, sachez que les clients doivent passer par dot1x et l'authentification Web. Il n'est pas destiné aux invités, mais à l'ajout d'un portail Web pour les employés (qui utilisent 802.1x). Il n'existe pas de SSID (Service Set Identifier) tout-en-un pour dot1x pour les employés ou de portail Web pour les invités.
Le processus d'authentification 802.11 est ouvert, vous pouvez donc vous authentifier et vous associer sans problème. Après cela, vous êtes associé, mais pas dans l'état EXÉCUTION WLC. Lorsque l'authentification Web est activée, vous êtes maintenu dans WEBAUTH_REQD où vous ne pouvez pas accéder à une ressource réseau (aucune requête ping, etc.). Vous devez recevoir une adresse IP DHCP avec l'adresse du serveur DNS dans les options.
Vous devez taper une URL valide dans votre navigateur. Le client résout l'URL via le protocole DNS. Le client envoie ensuite sa requête HTTP à l'adresse IP du site Web. Le WLC intercepte cette demande et retourne la page de connexion webauth, qui fausse l'adresse IP du site Web. Dans le cas d'une authentification Web externe, le WLC répond avec une réponse HTTP qui inclut votre adresse IP de site Web et indique que la page a été déplacée. La page a été déplacée vers le serveur Web externe utilisé par le WLC. Lorsque vous êtes authentifié, vous accédez à toutes les ressources réseau et êtes redirigé vers l'URL initialement demandée, par défaut (sauf si une redirection forcée a été configurée sur le WLC). En résumé, le WLC permet au client de résoudre le DNS et d'obtenir automatiquement une adresse IP à l'état WEBAUTH_REQD.
Astuce : Si vous voulez que le WLC regarde un autre port au lieu du port 80, vous pouvez utiliser config network web-auth-port <numéro de port> pour créer également une redirection sur ce port. Par exemple, l'interface Web Access Control Server (ACS), qui se trouve sur le port 2002 ou d'autres applications similaires.
Remarque à propos de la redirection HTTPS : Par défaut et dans les versions 7.x et antérieures, le WLC n'a pas redirigé le trafic HTTPS. Cela signifie que si vous ouvrez votre navigateur et tapez une adresse HTTPS, rien ne se passe. Vous devez taper une adresse HTTP afin d'être redirigé vers la page de connexion qui a été servie dans HTTPS.
Dans les versions 8.0 et ultérieures, vous pouvez activer la redirection du trafic HTTPS avec la commande CLI config network web-auth https-redirect enable.
Sachez que cela consomme des ressources pour le WLC au cas où de nombreuses requêtes HTTPS seraient envoyées. Il est conseillé de ne pas utiliser cette fonctionnalité avant la version 8.7 du WLC où l'évolutivité de cette fonctionnalité a été améliorée. Notez également qu'un avertissement de certificat est inévitable dans ce cas. En effet, si votre client demande une URL (telle que https://www.cisco.com), le WLC présente toujours son propre certificat émis pour l'adresse IP de l'interface virtuelle. Cela ne correspond évidemment jamais à l'adresse URL/IP demandée par le client et le certificat ne sera pas approuvé à moins que le client ne force l'exception dans son navigateur.
Débit de performance indicatif de la version du logiciel WLC avant 8.7 mesuré :
Webauth | Taux atteint |
---|---|
3 URL - HTTP | 140/seconde |
1ère URL - HTTP 2e et 3e URL - HTTPS |
20/seconde |
3 URL - HTTPS (déploiement important) |
< 1/seconde |
3 URL - HTTPS (maximum de 100 clients) |
10/seconde |
Dans ce tableau de performances, les 3 URL sont appelées :
Le tableau des performances indique les performances du WLC dans le cas où les 3 URL sont HTTP, dans le cas où les 3 URL sont HTTPS, ou si le client passe de HTTP à HTTPS (scénario le plus courant).
Si vous devez configurer un WLAN avec une interface dynamique opérationnelle, les clients doivent également recevoir une adresse IP de serveur DNS via DHCP. Avant de définir un webauth, vous devez tester le bon fonctionnement de votre WLAN, que vous pouvez résoudre des requêtes DNS (nslookup) et que vous pouvez parcourir des pages Web. Ensuite, vous pouvez définir l'authentification Web en tant que fonctions de sécurité de couche 3. Vous pouvez créer vos utilisateurs dans la base de données locale ou sur un serveur RADIUS externe, par exemple. Reportez-vous au document Exemple de configuration de l'authentification Web du contrôleur de réseau local sans fil.
L'authentification Web personnalisée peut être configurée avec redirectUrl à partir de l'onglet Sécurité. Cela force une redirection vers une page Web spécifique que vous entrez. Lorsque l'utilisateur est authentifié, il remplace l'URL d'origine demandée par le client et affiche la page pour laquelle la redirection a été affectée.
La fonction personnalisée vous permet d'utiliser une page HTML personnalisée au lieu de la page de connexion par défaut. Téléchargez votre bundle de fichiers html et image sur le contrôleur. Dans la page de téléchargement, recherchez webauth bundle au format tar. Habituellement, PicoZip crée des goudrons qui fonctionnent de manière compatible avec le WLC. Pour obtenir un exemple de bundle WebAuth, reportez-vous à la page Download Software pour les bundles WebAuth du contrôleur sans fil. Veillez à sélectionner la version appropriée pour votre WLC. Il est recommandé de personnaliser un bundle existant ; ne créez pas un bundle à partir de zéro.
Il y a certaines limitations avec webauth personnalisé qui varient avec les versions et les bogues. Les éléments à surveiller sont les suivants :
Si votre package client ne fonctionne pas, essayez avec un package personnalisé simple. Ajoutez ensuite des fichiers et de la complexité un par un pour atteindre le package que le client a essayé d'utiliser. Cela devrait vous aider à identifier le problème. Pour obtenir un exemple de configuration d'une page personnalisée, reportez-vous à Création d'une page de connexion d'authentification Web personnalisée, une section du Guide de configuration du contrôleur de réseau local sans fil Cisco, version 7.6.
Pour chaque WLAN, vous devez configurer avec la commande override global config et définir un type WebAuth pour chaque WLAN. Cela signifie que vous pouvez disposer d'un WebAuth interne/par défaut avec un WebAuth interne/par défaut personnalisé pour un autre WLAN. Cela vous permet également de configurer différentes pages personnalisées pour chaque WLAN. Vous devez combiner toutes vos pages dans le même bundle et les télécharger sur le WLC. Vous pouvez ensuite définir votre page personnalisée à l'aide de la commande override global config sur chaque WLAN et sélectionner le fichier correspondant à la page de connexion de tous les fichiers du bundle. Vous pouvez choisir une page de connexion différente dans le bundle pour chaque WLAN.
Il y a une variable dans le bundle HTML qui permet la redirection. N'y mettez pas votre URL de redirection forcée. Pour tout problème de redirection dans WebAuth personnalisé, Cisco recommande de vérifier le bundle. Si vous entrez une URL de redirection avec += dans l'interface graphique du WLC, cela peut remplacer ou ajouter à l'URL définie dans le bundle. Par exemple, dans l'interface utilisateur graphique du WLC, le champ redirectURL est défini sur www.cisco.com ; cependant, dans l'offre groupée, on peut lire : redirectURL+= 'www.google.com'. Le += redirige les utilisateurs vers www.cisco.comwww.google.com, qui est une URL non valide.
Comme expliqué brièvement, l'utilisation d'un serveur WebAuth externe n'est qu'un référentiel externe pour la page de connexion. Les informations d'identification de l'utilisateur sont toujours authentifiées par le WLC. Le serveur Web externe vous permet uniquement d'utiliser une page de connexion spéciale ou différente. Voici les étapes effectuées pour un WebAuth externe :
Remarque : nous utilisons 192.0.2.1 comme exemple d'adresse IP virtuelle dans ce document. La plage 192.0.2.x est recommandée pour l'adresse ip virtuelle car elle n'est pas routable. Une documentation plus ancienne peut faire référence à « 1.1.1.x » ou qui est peut-être encore ce qui est configuré dans votre WLC comme cela était le paramètre par défaut. Cependant, notez que cette adresse IP est maintenant une adresse IP routable valide et que le sous-réseau 192.0.2.x est donc conseillé à la place.
Remarque : Si les points d'accès (AP) sont en mode FlexConnect, une liste de contrôle d'accès prédéfinie n'est pas pertinente. Les listes de contrôle d’accès flexibles peuvent être utilisées pour autoriser l’accès au serveur Web pour les clients qui n’ont pas été authentifiés. Référez-vous à Exemple de configuration de l'authentification Web externe avec des contrôleurs de réseau local sans fil.
Il s'agit d'une variante de l'authentification Web interne. Il affiche une page avec un avertissement ou une instruction d'alerte, mais n'invite pas les informations d'identification. L'utilisateur doit cliquer sur ok. Vous pouvez activer l'entrée d'e-mail et l'utilisateur peut entrer son adresse e-mail, qui devient son nom d'utilisateur. Lorsque l'utilisateur est connecté, vérifiez la liste de vos clients actifs ; cet utilisateur est répertorié avec l'adresse e-mail qu'il a entrée en tant que nom d'utilisateur. Pour plus d'informations, référez-vous à l'exemple de configuration du passage Web du contrôleur LAN sans fil 5760/3850.
Si vous activez une redirection Web conditionnelle, l'utilisateur est redirigé conditionnellement vers une page Web particulière après que l'authentification 802.1x a réussi. Vous pouvez spécifier la page de redirection et les conditions sous lesquelles celle-ci se produit sur votre serveur RADIUS. Les conditions peuvent inclure le mot de passe de l'utilisateur lorsqu'il atteint la date d'expiration ou lorsque l'utilisateur doit payer une facture pour une utilisation/accès continue. Si le serveur RADIUS retourne l'url-redirect de paire AV Cisco, l'utilisateur est redirigé vers l'URL spécifiée lorsqu'il ouvre un navigateur. Si le serveur renvoie également l'url-redirect-acl de paire AV Cisco, alors la liste de contrôle d'accès spécifiée est installée comme liste de contrôle d'accès pré-authentification pour ce client. Le client n’est pas considéré comme entièrement autorisé à ce stade et ne peut transmettre que le trafic autorisé par la liste de contrôle d’accès pré-authentification. Une fois que le client a terminé une opération particulière à l'URL spécifiée (par exemple, un changement de mot de passe ou un paiement de factures), le client doit se réauthentifier. Lorsque le serveur RADIUS ne retourne pas d'url-redirect, le client est considéré comme entièrement autorisé et autorisé à transmettre le trafic.
Remarque : La fonction de redirection Web conditionnelle est disponible uniquement pour les WLAN configurés pour la sécurité de couche 2 802.1x ou WPA+WPA2.
Après avoir configuré le serveur RADIUS, vous pouvez configurer la redirection Web conditionnelle sur le contrôleur à l'aide de l'interface utilisateur graphique ou de l'interface de ligne de commande du contrôleur. Reportez-vous aux guides pas à pas suivants : Configuration de Web Redirect (GUI) et Configuration de Web Redirect (CLI).
Si vous activez la redirection Web de la page de démarrage, l'utilisateur est redirigé vers une page Web particulière après que l'authentification 802.1x a réussi. Après la redirection, l'utilisateur a un accès complet au réseau. Vous pouvez spécifier la page de redirection sur votre serveur RADIUS. Si le serveur RADIUS retourne l'url-redirect de paire AV Cisco, l'utilisateur est redirigé vers l'URL spécifiée lorsqu'il ouvre un navigateur. Le client est considéré comme entièrement autorisé à ce stade et est autorisé à passer le trafic, même si le serveur RADIUS ne retourne pas d'url-redirect.
Remarque : La fonction de redirection Web de la page de démarrage est disponible uniquement pour les réseaux locaux sans fil configurés pour la sécurité de couche 2 802.1x ou WPA+WPA2.
Après avoir configuré le serveur RADIUS, vous pouvez configurer la redirection Web de la page de démarrage sur le contrôleur à l'aide de l'interface graphique du contrôleur ou de l'interface de ligne de commande.
Pour cela, vous devez configurer les filtres MAC dans le menu de sécurité de couche 2. Si les utilisateurs sont validés avec succès avec leurs adresses MAC, ils passent directement à l'état d'exécution. Si ce n'est pas le cas, ils passent à l'état WEBAUTH_REQD et l'authentification Web normale se produit.
Remarque: Ceci n'est pas pris en charge avec le passthrough Web. Pour plus d'informations, suivez l'activité sur la demande d'amélioration ID de bogue Cisco CSCtw73512.
L'authentification Web centrale fait référence à un scénario où le WLC n'héberge plus de services. La différence réside dans le fait que le client est directement envoyé au portail Web ISE et ne passe pas par 192.0.2.1 sur le WLC. La page de connexion et l'ensemble du portail sont externalisés.
L'authentification Web centrale a lieu lorsque le contrôle d'admission au réseau RADIUS (NAC) est activé dans les paramètres avancés des filtres WLAN et MAC activés.
Le concept global est que le WLC envoie une authentification RADIUS (généralement pour le filtre MAC) à ISE, qui répond avec la paire redirect-url attribute value (AV). L'utilisateur est alors placé dans l'état POSTURE_REQD jusqu'à ce que ISE donne l'autorisation avec une demande de changement d'autorisation (CoA). Le même scénario se produit dans Posture ou Central WebAuth. Le WebAuth central n'est pas compatible avec WPA-Enterprise/802.1x, car le portail invité ne peut pas retourner les clés de session pour le chiffrement comme il le fait avec le protocole EAP (Extensible Authentication Protocol).
Ceci n'est valide que pour Local WebAuth lorsque WLC gère les informations d'identification ou lorsqu'une stratégie Web de couche 3 est activée. Vous pouvez ensuite authentifier les utilisateurs localement sur le WLC ou en externe via RADIUS.
Il existe un ordre dans lequel le WLC vérifie les informations d'identification de l'utilisateur.
Dans tous les cas, il regarde d'abord dans sa propre base de données.
S'il n'y trouve pas les utilisateurs, il se dirige vers le serveur RADIUS configuré dans le WLAN invité (s'il en existe un configuré).
Il vérifie ensuite la liste des serveurs RADIUS globaux par rapport aux serveurs RADIUS sur lesquels l'utilisateur réseau est coché.
Ce troisième point est très important et répond à la question de beaucoup de ceux qui ne configurent pas RADIUS pour ce WLAN, mais remarquez qu'il vérifie toujours contre RADIUS lorsque l'utilisateur n'est pas trouvé sur le contrôleur. Ceci est dû au fait que l'utilisateur réseau est contrôlé par rapport à vos serveurs RADIUS dans la liste globale.
WLC peut authentifier les utilisateurs sur le serveur RADIUS avec le protocole PAP (Password Authentication Protocol), le protocole CHAP (Challenge Handshake Authentication Protocol) ou EAP-MD5 (Message Digest5). Il s'agit d'un paramètre global qui peut être configuré à partir de l'interface utilisateur graphique ou de l'interface de ligne de commande :
À partir de l'interface utilisateur graphique : accédez à Controller > Web RADIUS Authentication
À partir de CLI : entrez config custom-web RADIUSauth <pap|chap|md5chap>
Remarque : le serveur invité NAC utilise uniquement le protocole PAP.
Il est facile à configurer et très proche de la configuration des invités sans fil. Vous pouvez le configurer avec un ou deux contrôleurs (uniquement s'il s'agit d'une auto-ancrage).
Choisissez un VLAN comme VLAN dans lequel vous placez les utilisateurs invités câblés, par exemple, sur VLAN 50. Lorsqu'un invité filaire souhaite accéder à Internet, branchez l'ordinateur portable sur un port d'un commutateur configuré pour VLAN 50. Ce VLAN 50 doit être autorisé et présent sur le chemin via le port d'agrégation WLC. Dans le cas de deux WLC (une ancre et une étrangère), ce VLAN invité câblé doit conduire au WLC étranger (appelé WLC1) et non à l'ancre. WLC1 s'occupe ensuite de la transmission tunnel du trafic vers le WLC DMZ (l'ancrage, appelé WLC2), qui libère le trafic dans le réseau routé.
Voici les cinq étapes à suivre pour configurer l'accès invité filaire :
Cette section fournit les processus que vous devez suivre si vous voulez placer votre propre certificat sur la page WebAuth, ou si vous voulez masquer l'URL WebAuth 192.0.2.1 et afficher une URL nommée.
Grâce à l'interface graphique (WebAuth > Certificate) ou à l'interface de ligne de commande (CLI) (type de transfert webauthcert), vous pouvez télécharger un certificat sur le contrôleur. Qu'il s'agisse d'un certificat que vous avez créé avec votre autorité de certification (CA) ou d'un certificat officiel tiers, il doit être au format .pem. Avant d'envoyer, vous devez également saisir la clé du certificat.
Après le téléchargement, un redémarrage est nécessaire pour que le certificat soit en place. Une fois redémarré, accédez à la page de certificat WebAuth de l'interface utilisateur graphique et elle affiche les détails du certificat que vous avez téléchargé (validité, etc.). Le champ important est le nom commun (CN), qui est le nom attribué au certificat. Ce champ est traité dans ce document sous la section « Autorité de certification et autres certificats sur le contrôleur ».
Après avoir redémarré et vérifié les détails du certificat, le nouveau certificat de contrôleur s'affiche sur la page de connexion WebAuth. Toutefois, il peut y avoir deux situations.
Pour être débarrassé de l'avertissement « ce certificat n'est pas fiable », vous devez également entrer le certificat de l'autorité de certification qui a émis le certificat du contrôleur sur le contrôleur. Ensuite, le contrôleur présente les deux certificats (certificat du contrôleur et certificat CA). Le certificat de l'autorité de certification doit être une autorité de certification de confiance ou disposer des ressources nécessaires pour vérifier l'autorité de certification. Vous pouvez en fait créer une chaîne de certificats d'autorité de certification qui mène à une autorité de certification de confiance en haut.
Vous devez placer la chaîne entière dans le même fichier. Cela signifie que votre fichier contient du contenu tel que cet exemple :
BEGIN CERTIFICATE ------ device certificate* END CERTIFICATE ------ BEGIN
CERTIFICATE ------ intermediate CA certificate* END CERTIFICATE ------ BEGIN
CERTIFICATE ------ Root CA certificate* END CERTIFICATE ------
L'URL WebAuth est définie sur 192.0.2.1 afin de vous authentifier et le certificat est émis (il s'agit du champ CN du certificat WLC). Si vous voulez changer l'URL WebAuth en 'myWLC.com', par exemple, accédez à la configuration de l'interface virtuelle (l'interface 192.0.2.1) et vous pouvez y entrer un nom d'hôte DNS virtuel, tel que myWLC.com. Ceci remplace le 192.0.2.1 dans votre barre d'URL. Ce nom doit également pouvoir être résolu. La trace du renifleur montre comment tout fonctionne, mais lorsque le WLC envoie la page de connexion, le WLC affiche l'adresse myWLC.com et le client résout ce nom avec son DNS. Ce nom doit être résolu en 192.0.2.1. Cela signifie que si vous utilisez également un nom pour la gestion du WLC, vous devriez utiliser un autre nom pour WebAuth. En d'autres termes, si vous utilisez myWLC.com mappé à l'adresse IP de gestion du WLC, vous devez utiliser un nom différent pour WebAuth, tel que myWLCwebauth.com.
Cette section explique comment et quoi vérifier pour résoudre les problèmes de certificat.
Vous pouvez télécharger OpenSSL (pour Windows, rechercher OpenSSL Win32) et l'installer. Sans aucune configuration, vous pouvez aller dans le répertoire bin et essayer openssl s_client -connect www.mywebauthpage.com:443, si cette URL est l'URL où votre page WebAuth est liée sur votre DNS. Reportez-vous à la section « Que vérifier » de ce document pour un exemple.
Si vos certificats utilisent une autorité de certification privée, vous devez placer le certificat d'autorité de certification racine dans un répertoire sur une machine locale et utiliser l'option openssl -CApath. Si vous avez une autorité de certification intermédiaire, vous devez également la placer dans le même répertoire.
Afin d'obtenir des informations générales sur le certificat et de le vérifier, utilisez :
openssl x509 -in certificate.pem -noout -text
openssl verify certificate.pem
Il peut également être utile de convertir des certificats à l'aide d'openssl :
openssl x509 -in certificate.der -inform DER -outform PEM -out certificate.pem
Vous pouvez voir quels certificats sont envoyés au client lorsqu'il se connecte. Lisez le certificat de périphérique : le CN doit être l'URL à laquelle la page Web est accessible. Lisez le “ émis par ” ligne du certificat de périphérique. Cette valeur doit correspondre au CN du deuxième certificat. Ensuite, ce deuxième certificat “ délivré par ” doit correspondre au CN du certificat suivant, et ainsi de suite. Sinon, il ne fait pas une chaîne réelle. Dans la sortie OpenSSL affichée ici, vous pouvez voir que openssl ne peut pas vérifier le certificat du périphérique car son “ émis par ” ne correspond pas au nom du certificat CA fourni.
Sortie SSL
Loading 'screen' into random state - done CONNECTED(00000760) depth=0 /O=
<company>.ac.uk/OU=Domain Control Validated/CN=<company>.ac.uk verify error:
num=20:unable to get local issuer certificate verify return:1 depth=0 /O=
<company>.ac.uk/OU=Domain Control Validated/CN=<company>.ac.uk verify error:
num=27:certificate not trusted verify return:1 depth=0 /O=<company>.ac.uk/OU=
Domain Control Validated/CN=<company>.ac.uk verify error:num=21:
unable to verify the first certificate verify return:1 --- Certificate chain
0 s:/O=<company>.ac.uk/OU=
Domain Control Validated/CN=<company>.ac.uki:/C=US/ ST=
Arizona/L=Scottsdale/O=.com/OU=http://certificates.gocompany.com/repository/CN=
Secure Certification Authority/serialNumber=079
692871 s:/C=US/O=Company/OU=Class 2 Certification Authority
i:/C=US/O=Company/OU=Class 2 Certification Authority --- Server certificate
BEGIN CERTIFICATE-----
MIIE/zCCA+egAwIBAgIDRc2iMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
output cut*
YMaj/NACviEU9J3iot4sfreCQSKkBmjH0kf/Dg1l0kmdSbc=
END CERTIFICATE-----
subject=/O=<company>.ac.uk/OU=Domain Control Validated/CN=<company>c.ac.uk
issuer=/C=US/ST=Arizona/L=Scottsdale/O=.com/OU=http://certificates.
.com/repository/CN=Secure Certification Authority/serialNumber=0
7969287 --- No client certificate CA names sent --- SSL handshake has read
2476 bytes and written 322 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: A32DB00A7AB7CD1CEF683980F3696C2BBA31A1453324F711F50EF4B86A4A7F03
Session-ID-ctx:Master-Key: C95E1BDAC7B1A964ED7324955C985CAF186B92EA34CD69E10
5F95D969D557E19
939C6A77C72350AB099B3736D168AB22
Key-Arg : None
Start Time: 1220282986
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
Un autre problème possible est que le certificat ne peut pas être téléchargé sur le contrôleur. Dans cette situation, il n'y a pas de question de validité, de CA, et ainsi de suite. Afin de vérifier cela, vous pouvez d'abord vérifier la connectivité TFTP (Trivial File Transfer Protocol) et essayer de transférer un fichier de configuration. Ensuite, si vous entrez la commande debug transfer all enable, vous voyez que le problème est l'installation du certificat. Cela peut être dû à la mauvaise clé utilisée avec le certificat. Il se peut également que le certificat soit dans un format incorrect ou endommagé.
Cisco vous recommande de comparer le contenu du certificat à un certificat valide connu. Cela vous permet de voir si un attribut LocalkeyID affiche tous les 0 (déjà arrivé). Dans ce cas, le certificat doit être reconverti. Il existe deux commandes avec OpenSSL qui vous permettent de retourner de .pem à .p12, puis de réémettre un .pem avec la clé de votre choix.
Pré-étape : Si vous avez reçu un .pem contenant un certificat suivi d'une clé, copiez/collez la partie clé : —BEGIN KEY — jusqu'à — END KEY — de .pem à « key.pem ».
Bien que l'ancrage de mobilité n'ait pas été abordé dans ce document, si vous êtes dans une situation d'invité ancré, assurez-vous que l'échange de mobilité se produit correctement et que vous voyez le client arriver sur l'ancrage. Tous les autres problèmes WebAuth doivent être résolus sur l'ancrage.
Voici quelques problèmes courants que vous pouvez résoudre :
Pour plus d'informations à ce sujet, consultez : Dépannage de l'authentification Web sur un contrôleur de réseau local sans fil (WLC).
Vous pouvez utiliser un serveur proxy HTTP. Si vous avez besoin que le client ajoute une exception dans son navigateur que 192.0.2.1 ne doit pas passer par le serveur proxy, vous pouvez faire que le WLC écoute le trafic HTTP sur le port du serveur proxy (généralement 8080).
Pour comprendre ce scénario, vous devez savoir ce qu'un proxy HTTP fait. Il s'agit d'un élément que vous configurez du côté client (adresse IP et port) dans le navigateur.
Le scénario habituel lorsqu'un utilisateur visite un site Web consiste à résoudre le nom sur IP avec DNS, puis il demande la page Web au serveur Web. Le processus doit toujours envoyer la requête HTTP de la page au proxy. Le proxy traite le DNS, le cas échéant, et le transmet au serveur Web (si la page n'est pas déjà mise en cache sur le proxy). La discussion porte uniquement sur le client à proxy. Le fait que le proxy obtienne ou non la véritable page Web n'est pas pertinent pour le client.
Voici le processus d'authentification Web :
Les types d'utilisateur dans une URL.
Le PC client envoie au serveur proxy.
WLC intercepte et falsifie l'adresse IP du serveur proxy ; il répond au PC avec une redirection vers 192.0.2.1
À ce stade, si le PC n'est pas configuré pour lui, il demande la page 192.0.2.1 WebAuth au proxy afin qu'elle ne fonctionne pas. Le PC doit faire une exception pour 192.0.2.1 ; ensuite, il envoie une requête HTTP à 192.0.2.1 et passe à WebAuth. Une fois authentifiées, toutes les communications passent de nouveau par le proxy. Une configuration d'exception se trouve généralement dans le navigateur proche de la configuration du serveur proxy. Le message doit s'afficher : « N'utilisez pas de proxy pour ces adresses IP ».
Avec WLC version 7.0 et ultérieure, la fonction webauth proxy redirect peut être activée dans les options de configuration globale du WLC. Lorsqu'il est activé, le WLC vérifie si les clients sont configurés pour utiliser manuellement un proxy. Dans ce cas, ils redirigent le client vers une page qui leur montre comment modifier leurs paramètres de proxy pour que tout fonctionne. La redirection de proxy WebAuth peut être configurée pour fonctionner sur différents ports et est compatible avec l'authentification Web centrale.
Pour un exemple de redirection de proxy WebAuth, référez-vous à Exemple de configuration du proxy d'authentification Web sur un contrôleur de réseau local sans fil.
Vous pouvez vous connecter à l'authentification Web sur HTTP au lieu de HTTPS. Si vous vous connectez sur HTTP, vous ne recevez pas d'alertes de certificat.
Pour le code antérieur à la version 7.2 du WLC, vous devez désactiver la gestion HTTPS du WLC et quitter la gestion HTTP. Cependant, ceci autorise uniquement la gestion Web du WLC sur HTTP.
Pour le code WLC version 7.2, utilisez la commande config network web-auth secureweb disable pour désactiver. Ceci désactive uniquement HTTPS pour l'authentification Web et non la gestion. Notez que cela nécessite un redémarrage du contrôleur !
Sur les versions 7.3 et ultérieures du WLC, vous pouvez activer/désactiver HTTPS pour WebAuth uniquement via l'interface utilisateur graphique et l'interface de ligne de commande.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
07-Feb-2014 |
Première publication |