View Only
last person joined: yesterday 

Enterprise security using ClearPass Policy Management, ClearPass Security Exchange, IntroSpect, VIA, 360 Security Exchange, Extensions and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

verify the server's identity by validating the certificate

This thread has been viewed 7 times
  • 1.  verify the server's identity by validating the certificate

    Posted Dec 07, 2015 01:16 AM

    Last week, any client could connect to my wireless network and this week they can not. I have a Aruba EOL 3200 with 8 access points. The windows/android/iphone/OSX clients were able to connect with 802.1x verifying against a local, Aruba based database of one user name. This week when I get in, I notice that my phone can not connect to the wireless. Then my Windows 10 laptop could not connect (both have connected before). Only clients that have not disconnect from the network were still able to access it. This only happens with the 802.1x WPA 2 ssid (staff) and not with the PSK WPA 2 ssid (for guests). I then verified that the only way for a windows computer to connect to this is to uncheck the "verify the server's identity by validating the certificate" option while manually adding the profile. Android devices are still unable to connect. When an OSX connects, it obtains the Aruba certificate. I am completely baffled by this. Any help? I do not want to manually configure all of my companies laptops with the ssid (I know I can do it from group policy). I want the abaility back for any computer or phone to be able to sign in as if they are not part of the domain and have never seen the Aruba's certificate.


  • 2.  RE: verify the server's identity by validating the certificate

    Posted Dec 07, 2015 02:51 AM

    From you description, it seems that for 802.1x you are using the controller internal database. In that case, also the server certificate used in the controller is used. As this is an EOL 3200, the certificate in the controller might have expired (certificates have a valid-to date in them).


    If you are still under support, what you can do is upgrade to the most recent version, I expect the certificate in the most recent version still valid (however it is deprecated to use the controller built-in certificate for 802.1x for various security reasons, most obvious one is that anyone with an Aruba controller has access to that certificate).


    The recommended solution is to use a self-controlled certificate and put that on the controller. Depending on your environment, that might be a self-signed or a public certificate. For getting understanding about what certificate to use, you may read the ClearPass Certificate 101 Technote, see also:



  • 3.  RE: verify the server's identity by validating the certificate

    Posted Dec 09, 2015 04:08 PM

    Ok, I have generated self signed root and server certificates. I have also changed the authentication from the internal database to a server group with a NAP server configured for RADIUS. I have the same setup at another site with a Ruckus controller and that system operates as expected, loging in, any device, and receives the certificate from the server's certificate authority (domain controller certificate). I tried to mirror that setup here but am receiving the same behavior from the controller. I have created a NAP and created the policy for what I believe to be accurate. I can authenticate and connect with the "verify the server's identity by validating the certificate" unchecked but I can not with it checked. It does not pull the certificate from the domain controller's certificate authority like my other location. Again I am baffeled again. User rolls are set up, in the NAP server I have configured Vender specific attributes. Like I described in my first post, the Aruba randomly started doing this, within the past two weeks.


    I should also remention that this controller has ArubaOS on it.

  • 4.  RE: verify the server's identity by validating the certificate

    Posted Dec 10, 2015 04:08 AM

    So it seems like Windows 10 has changed behavior recently, by requiring TLS 1.2 during the session setup. ArubaOS 3.x or 5.x do not support TLS 1.2 for EAP Termination; however I do not see any reason why it shouldn't with an external NPS server. However make sure that NPS does support TLS 1.2.


    May be the following information may help you:


    • Problem Statement
      • When the controller is configured to perform EAP termination, newer clients that support TLS1.2 may fail 802.1X authentication 
      • 1X authentication is NOT affected if a) EAP termination is disabled and b) the authentication server supports TLS 1.2 (e.g. ClearPass v. 6.5.2)
    • Observations
      • Windows 10 WiFi clients are using TLS 1.2 by default and is failing 802.1X authentication when controller is configured with EAP Termination
    • Workaround
      • Disable EAP termination on the controller and make sure the authentication server supports TLS 1.2
      • Please take a look at There is a method to modify registry keys to use a different TLS version, e.g. TLS 1.0



    It does not really make sense that with an external NPS RADIUS server, setup with certificates for EAP-802.1x, it does work for a Ruckus AP while it does not for the Aruba controller, as in that setup all communication is tunneled and performed on the RADIUS server. If you connect to the SSID, do you see the correct certifcate?? If you have an iOS device is nicely shows the server certificate so you can check if you are indeed seeing the cert from the RADIUS server, not the controller internal.


    The advise I gave you to put your own cert on the controller and still use EAP termination has been obsoleted by this new information about Windows 10 requiring TLS1.2.