Security

So I've set up this EAP-TLS SSID and have the right certificates installed on the client devices and controller. Testing with a user, I see that he's not able to connect on his iPhone. This is what I see in show auth-tracebuf:

 

Feb 16 12:29:38  station-up             *  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap                           -     -     wpa2 aes
Feb 16 12:29:38  station-term-start     *  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap                           50    -     
Feb 16 12:29:38  client-cert           ->  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof  1261  3995  
Feb 16 12:29:38  client-cert           ->  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof  1270  3995  
Feb 16 12:29:38  client-cert           ->  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof  1270  3995  
Feb 16 12:29:38  client-cert           ->  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof  194   3995  
Feb 16 12:29:38  client-cert verified   *  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap                           -     -     
Feb 16 12:29:38  cert-signature-verify ->  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof  -     -     verified
Feb 16 12:29:38  client-finish         ->  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof  -     -     
Feb 16 12:29:38  server-finish         <-  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof  -     61    
Feb 16 12:29:38  server-finish-ack     ->  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof  -     -     
Feb 16 12:29:38  user-validate-req     ->  aa:bb:cc:dd:ee:ff  ap:ap:ap:ap:ap:ap                           -     -     
Feb 16 12:29:38 user-validate-failed <- aa:bb:cc:dd:ee:ff ap:ap:ap:ap:ap:ap/Internal - - Feb 16 12:29:38 eap-failure <- aa:bb:cc:dd:ee:ff ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof - 4     

 

What I want to know is why despite the right certificates, the controller needs to verify the client with the internal database? After seeing this message, I created a manual entry in the internal DB for this user and then it starts working! Why should I even need to do this? Can someone please explain?

 

Feb 16 12:44:23 user-validate-success <- aa:bb:cc:dd:ee:ff ap:ap:ap:ap:ap:ap/Internal - -
Feb 16 12:44:23 eap-success <- aa:bb:cc:dd:ee:ff ap:ap:ap:ap:ap:ap/TEST-SSID-dot1x_prof - 4  

 

 

Can you let us know which version of ArubaOS you are using and it appears you are also using EAP termination on the controller.

In version 6.x a new UI option was exposed called Check CN in AAA and I suspect it will be this trigger that is causing the failure based on the aaa profile pointing to the local database.

The controller takes the common name from the cert and tries to authorize the user with the AAA server used for that AAA profile. This happens becuase the Check cetificate common name against AAA server option is enabled by default. Disable this option to slove your issue.

 

aaa authentication dot1x "corp-employee-dot1x"
  no cert-cn-lookup

 

 

Thanks for the help guys.

 

Sathya, I don't even have that option in the GUI or the CLI. I'm using 5.0.4.3.

You will need 6.1 before that option becomes available.

The reason this check is there is because prior to 6.1, the controller has no ability to check revocation status of client certificates.  So if you do EAP-TLS and a client presents a certificate that is valid under the CA, but has been revoked by the CA, the controller won't know about it.  Thus there is a lookup to RADIUS, LDAP, or the internal DB to see if it knows about the certificate.

 

Starting in 6.1, the controller can use OCSP to check certificate revocation status.  In the same release, we added the knob to disable the cert lookup in RADIUS/LDAP/internalDB.

 

Hope that helps.