Upcoming community maintenance Oct. 27th through Oct. 29th
For more info click here

How does EAP-TLS work when the controller is used to terminate the tunnel (EAP offload)?

Aruba Employee
Aruba Employee

Product and Software: This article applies to all Aruba platforms and ArubaOS 3.3.x and later.


The EAP-TLS offload feature consists of a termination of the EAP-TLS tunnel at the controller rather than at the RADIUS server.

The purpose of this feature is to drastically reduce the number of packets that are exchanged between the wireless client and the RADIUS server. The load on the RADIUS server is reduced and the intranet delay with the controller is minimized.


For the EAP-TLS offload feature to work and for the controller to terminate the EAP-TLS tunnel, the controller must have a valid server certificate and the root CA that signed the client certificates. The server certificate and the client certificate do not need to be signed by the same CA.

How It Works

When the client initiates a connection to the wireless network using EAP-TLS, both the server and client certificates are exchanged. Upon successful certificate verifications and TLS negotiations, the tunnel gets established.

The Aruba controller does not currently support CRL verification of the client certificate, so the controller parses the client certificate and checks if the "principal name" field exists in the "Subject alternative name" option. If that field does not exist, the controller picks up the CN name. The controller sends an "Authorize only" RADIUS request if the server configured in the associated aaa profile is a RADIUS server. The controller does an LDAP search if the configured server is an LDAP server. In both cases, the controller checks if the principal name or CN name exists in the backend database.

If the server returns a successful response, the controller declares the EAP-TLS connection successful, moves to the dynamic key exchange phase, and places the user in the configured dot1x role.

If the server returns a failed response, the controller declares the user validation has failed and based on a dot1x profile option called "TLS Guest Access", it decides to fail or pass the client EAP-TLS authentication.

If the "TLS Guest Access" option is enabled and user verification fails, the client is placed in a configurable "TLS Guest Role". If the "TLS Guest Access" option is disabled and user verification fails, the client is deemed to have failed EAP-TLS authentication, and its connection to the wireless network is rejected.

Version history
Revision #:
1 of 1
Last update:
‎07-05-2014 04:25 AM
Updated by:
Labels (1)