Self signed certificate on 9800 wlc

[erga]

We have a 9800 wlc in our environment. When a user joins an SSID broadcast by an AP joined to the 9800 they get a warning about not trusted certificate. The certificate is the self signed wlc cert. I am not exactly clear on who is presenting this cert, the wlc or the AP. I tried to replace the cert with a 3rd party one, but if I do that the AP won't join the wlc anymore. I see SSC hash not allowed error in console.

Has anyone experienced this, and if there's a workaround. The users will start complaining about the cert that they have to accept when on wifi

TIA

[marce1000]

 - You may find this document useful :

                https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-3/config-guide/b_wl_17_3_cg/m_controller-self-signed-certificate.html

 M.

[Arshad Safrulla]

Hi since this SSC warning is prompted to the users, I am almost certain that this is due to the radius server configuration. Solution is either you have to ignore the certificate validation which is not recommended at all or reconfigure the radius server and integrate it with a proper pki infrastructure and deploy certificates to the clients. 

[erga]

The certificate warning doesn't seem to come from the radius server. I have dot1x implemented, tunneled PEAP, users are being authenticated using the cert installed in the ISE server.

I have seen something similar on 3800 switches, they're throwing a warning while my client goes through the compliance checks.

I am trying to install LSC certificate in the AP and it seems that is only supported on 17.5. I am in the process of upgrading to test this. If I use the LSC cert on the current version (17.3.3) the AP can't join the wlc

[Arshad Safrulla]

Locally significant certificate is for the communication between AP and WLC. I don’t recall any instances where this can help to solve an issue faced by client.

PEAP encapsulates the inner authentication mechanism EAP-MSCHAPv2 using TLS. Provided configuration is correct this can be used for server side authentication. In your case you may not be having a trusted certificate which is signed by the same ca as the cert in ISE or May be using a self signed certificate in ISE . Read the below article 

https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-cert-requirements

[erga]

The certificate that is presented is the self signed wlc certificate.

The dot1x/radius configs are correct. The same configuration works fine for the vwlc running aireos.

The user is authenticated, but while going through compliance checks the warning pops up. It doesn't matter if you chose to trust the cert or not you will be granted access if compliant. The problem is that users will start complaining about this even though it is not service impacting. I have seen something similar on wired before and the explanation was that some applications are trying to go online while the compliance check is running (outlook is one). If I could replace this certificate with something my machine trusts we shouldn't have the warning. 

I have a TAC case open about it and they are not fully understanding what is happening. 

[Scott Fella]

So just to be clear, you are using the NAC feature, but if you test on a policy with just 802.1x on the radius, everything works fine?  The certificate error you see is from applications or during the initial association?  You will never see the self signed during an 802.1x to radius, only if 802.1x is define to use internal authentication.

[erga]

Yes, I am using the NAC feature. I'm using tunneled PEAP, the wlc is the authenticator. No local authentication involved.

I am using flexconnect so if I understand correctly my traffic doesn't go through the controller, only the AP.

Same ISE/radius configuration, same laptop, no certificate warnings when connecting to the APs joined to the vwlc running aireos. 

When connecting to the AP joined to the 9800 I get the warning. The 9800 is running the same core config as the aireos vwlc. 

This certificate has no impact in the user authenticating, and it pops up during posturing when the traffic is limited by the DACL

[Scott Fella]

So then what tac needs to better understand is what is happening when using posturing.  Might be a redirect issue or something that is missing.  TAC would be the best route as they can review your acl's and your ISE configuration.

[erga]

Thanks, TAC seems lost lol. They need me to recreate it and get captures which I will do in my next visit in the office.

I was trying to replace the self-signed cert with a 3rd party one but then the AP won't join if you're using LSC certificates. According to the documentation that should be possible in 17.5, I tested it with no success.

[Scott Fella]

I haven't tried it, but I though you can import certificates to the controller for different use.  I would think that the 3rd party might be hitting the webauth cert.  Have you tried to change the webauth cert to your 3rd party cert?  With any troubleshooting, it's always better to try to reproduce it and provide as much information as possible.  Not everyone hits the same issue and or bugs, but I don't think they can fix anything without more data.

[ptryniszewski]

Did you manage to solve it? We are in the same situation now - TAC does not know what to do and recommended SW upgrade... we are on 17.3.3

regards

Paweł

[erga]

I was able to solve it somewhat differently. I upgraded to 17.5.5 and installed my CA certificates and the APs weren't able to join the wlc. The app that was causing the warning was outlook. During posturing the email client was trying to get out on the internet. Created an outlook object-group and allowed that in the redirect ACL. 

The syntax for the object group:
object-group fqdn OUTLOOK
pattern microsoft\.outlook\.com

The ACL line:

permit ip any fqdn-group OUTLOOK

Its working fine for me so I'm happy to not deal with it anymore. Someone below is saying that someone from TAC was able to resolve it. My experience with TAC regarding the 9800 has been wildly different depending on who you get

[Arshad Safrulla]

Great to hear that your issue was sorted. But can you post the redirect ACL you use;

I hope you have gone through this document already.

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213920-central-web-authentication-cwa-on-cata.html#:~:text=in%20the%20image.-,You,-need%20to%20deny

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213920-central-web-authentication-cwa-on-cata.html#:~:text=any%20eq%2080-,Note,-%3A%20If%20you%20end

[ammahend]

.