cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3942
Views
5
Helpful
15
Replies

Cisco Catalyst 9800-CL Wireless Controller: Error Web Auth with https

Bolivar
Level 1
Level 1

Hi guys

I'm having Web Auth issues with https.
For some devices, authentication works correctly (with https).
For others, the user is redirected to an (unsecured) http page.

I noticed that this problem occurs mainly when I use radius authentication.
On the other hand, when using local authentication, the problem does not occur.

NOTE: authentication via radios is working, but without https.

can you help me?

1 Accepted Solution

Accepted Solutions

Adding these lines in apache server configuration

SSLCertificateFile /etc/apache2/certificate/mydomain.crt
SSLCertificateKeyFile /etc/apache2/certificate/mydomain.key
SSLCertificateChainFile /etc/apache2/certificate/intermediate.pem

View solution in original post

15 Replies 15

Hi

 which WLC do you have? Which version? Which RADIUS? If ISE, which version?

 

Cisco Catalyst 9800-CL Wireless Controller

Version: 17.3.5a

Free Radius with Open LDAP 

 

 Did you create a ACL for web redirect on the WLC? For both ports 80 and 443?  It seems to me that you did por port 80 only.

Bolivar
Level 1
Level 1

Virtual IPv4 Address: 192.168.2.151

 

 

C9800#show access-lists
Extended IP access list AutoQos-4.0-Output-Acl-CAPWAP-C
10 permit udp any eq 5246 16666 any
Extended IP access list IP-Adm-V4-Int-ACL-global
10 permit tcp any any eq www
20 permit tcp any host 192.168.2.151 eq 443
Extended IP access list IP-Adm-V4-LOGOUT-ACL
10 permit tcp any host 192.168.2.151 eq www
20 permit tcp any host 192.168.2.151 eq 443
Extended IP access list implicit_deny
10 deny ip any any
Extended IP access list implicit_permit
10 permit ip any any
Extended IP access list meraki-fqdn-dns
Extended IP access list preauth_v4
10 permit udp any any eq domain
20 permit tcp any any eq domain
30 permit udp any eq bootps any
40 permit udp any any eq bootpc
50 permit udp any eq bootpc any
60 deny ip any any
IPv6 access list implicit_deny_v6
deny ipv6 any any sequence 10
IPv6 access list implicit_permit_v6
permit ipv6 any any sequence 10
IPv6 access list preauth_v6
permit udp any any eq domain sequence 10
permit tcp any any eq domain sequence 20
permit icmp any any nd-ns sequence 30
permit icmp any any nd-na sequence 40
permit icmp any any router-solicitation sequence 50
permit icmp any any router-advertisement sequence 60
permit icmp any any redirect sequence 70
permit udp any eq 547 any eq 546 sequence 80
permit udp any eq 546 any eq 547 sequence 90
deny ipv6 any any sequence 100

Your ACL must deny Radius IP address.

 

Take a look on this doc

 

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213920-central-web-authentication-cwa-on-cata.html 

 

Redirect ACL Configuration

Thanks for answering.


I had already checked the documentation you sent.

 

To test, I created an ACL that completely frees communication with the RADIUS server address. However, the problem persists.

I don't think it's a problem with ACLs, since on some devices, both HTTPs and RADIO authentication work normally.

 

On a notebook, with Windows 11 installed, web authentication is working correctly. On the other hand, when I try to use a notebook with linux (debian), an android smartphone or an iphone, I get errors (invalid certificate) or a captive portal opens with http (no security).

 

I noticed that each of the devices uses the default captive portal:

Android:
http://connectivitycheck.gstatic.com
or, when opened via browser, an https error is displayed

 

Debian Linux via firefox: http://detectportal.firefox.com/succex.txt

 

Windows 11:
When trying to access, the standard windows portal is opened (http://www.msftconnecttest.com/redirect), and then it is redirected to the correct personalized page, with https, that is, it works correctly.

 

NOTE: both in windows and in other operating systems, authentication via RADIUS server works correctly. The problem lies in not always guaranteeing a secure connection.

 

Also, if I manually access the correct captive portal address, on the device I want to authenticate, in some cases it works normally, in others, it doesn't load the complete certificate chain, resulting in non-validation and error due to lack of root certificate.

 Radius communication and web auth happens totally different, so, you can not compare.

 

For Web auth in previous WLC version based on AIROS, you should have an ACL allowing the Radius IP address for Central Web Authentication.

On the WLC 9800, for some reason, they change the logic and now we need to deny the Radius IP address.  The experience I have is based in ISE for the process with  FreeRadius might be different. 

 But for ISE with CWA, I am sure that you need the ACL for web auth.

 

Rich R
VIP
VIP

Whether you use ISE or FR makes no difference - they both use radius.

This sounds more like a certificate problem - that's why the redirect from the captive portal http pages isn't working.

Have you used a valid public certificate with correct matching working DNS domain for the certificate name?

Your ACL also needs to allow access to the certificate's CRL, OCSP and policy servers so that devices can fully verify/validate the certificate.

For example:

X509v3 CRL Distribution Points:

Full Name: URI:http://crl3.digicert.com/DigiCertTLSRSASHA2562020CA1.crl

Full Name: URI:http://crl4.digicert.com/DigiCertTLSRSASHA2562020CA1.crl

X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.1.1  CPS: https://www.digicert.com/CPS
Authority Information Access: 

OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1.crt

 

Yes, I believe it is a problem with the certificate validation.


The domain was signed with a public certificate.

I noticed that on computers where the capitve portal is working correctly, the complete certificate chain is shown.

On the other hand, on computers that have an error, the root certificate does not appear. As shown:

 

Incomplete string, with error:
RNP ICPEdu OV SSL CA 2019 --> wlogin.cpd.ufsm.br

 

Complete string, no error:
GlobalSign Root CA - R3 --> Trusted Root TLS SHA256 G3 --> RNP ICPEdu OV SSL CA 2019 --> wlogin.cpd.ufsm.br

Are you delivering the full cert chain together with your cert (best to make sure you are)?

In some cases the OS may need to be updated to support the latest certs and root CAs.

I performed the procedures as described:


https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213917-generate-csr-for-third-party-certificate.html

 

PKCS12 Format Conversion and Certificate Chain in Multi-Level CA Scenarios.


It is possible to end up in a situation where you have a private key file and certificate in PEM or CRT format and want to combine them in a PKCS12 (.pfx) format to upload to the 9800 WLC. In order to do so, enter this command:

 

openssl pkcs12 -export -in <PEM certificate filename> -inkey <privatekey.key> -out <output new .pfx filename>
In the case where you have a chain of certificate (one or multiple intermediate CA and root CA) all in PEM format, you then need to combine all in a single .pfx file.

 

First, manually combine the CA certificates in a single file as such. Copy and paste the contents together (save the file in .pem format):

----- BEGIN Certificate --------
<intermediate CA cert>
------END Certificate --------
-----BEGIN Certificate -----
<root CA cert>
-----END Certificate--------


Later you can then combine all in one PKCS12 certificate file with :

openssl pkcs12 -export -out chaincert.pfx -inkey <deviceprivatekey> -in <device private certificate> -certfile <combined CA file.pem>



 

And if you do a packet capture can you see the client receiving the complete chain?

If it's receiving the complete chain but not recognising/accepting the root certs then OS update is the only option or some devices will need to be replaced if there is no update available.

ammahend
VIP
VIP

For others, the user is redirected to an (unsecured) http page.

on this insecure page, can you check the correct certificate is presented by radius server, if yes then this might be device issue. Some devices specially Apple It usually occurs when the public certificate includes a Certificate Revocation List (CRL) distribution point that the iOS device needs to verify. The iOS device cannot verify the CRL without network access.

-hope this helps-

Bolivar
Level 1
Level 1

I was able to solve the problem by entering the signed certificate along with the root and intermediary certificate on an external apache server.
Thanks a lot for the help.

Review Cisco Networking for a $25 gift card