802.1X authentication is used to authenticate clients or sensors in a domain. For more information on understanding 802.1x authentication, you can refer to this link.

Most of the time you will have to look at the logs on the RADIUS server for any client authentication failures. The problems with 802.1x authentication failures can be resolved by taking packet capture either as on-demand or triage for issues on the sensors.

802.1x error codes are from the WAP_supplicant output which corresponds to the error codes seen in the error details here.

If you are getting an 802.1x auth failed error you must look for EAP handshake packets and expand the Client Hello packet[to check what sensor is using] or Server Hello packet[to check what RADIUS server using] > EAP packet to look for TLS details.

The server reports that it is using TLSv1.0

The sensor rejects it because it only supports TLSv.1.2

We recommend using TLSv1.2 on the RADIUS server side since our sensor supports it and v1.0 has a lot of vulnerabilities.

Note: Using TLSv1.3 we can't tell which certificate is being used since the certificate in TLSv1.3 is sent encrypted.

On Clearpass the setting is here:

You can now see the Certificate Expiry date in the Sensors About section.

Also, you should able to see the CA cert and client cert info as a part of triage:

Once you get pcap under triage and open the pcap file[for ethernet it would be ethernet-default and for wireless, it would be datagrams], look for Server Hello packet, open certificate, look for root cert, export to bytes and save it as .pem file.
​

Go to Sensor settings > select wireless or wired network > Advanced > Specify server CA > upload the file
​

Once you add root cert to the sensor you will get past the part where the sensor does not trust the radius server. Sometimes there will be an error on the next step where the RADIUS server doesn't trust the sensor, to get around that you must edit your RADIUS server and add the root certificate of CA that issues the sensor certificate to the trust list. In Clearpass that setting is under here:

The easy way to do certificate-based authentication with EAP-TLS is to create one certificate manually which can be used by all sensors. You would create the certificate in PKCS12 format and upload it to our dashboard. You can follow this help article here.

On the other hand, if you want to have a unique certificate on each sensor then you should use SCEP enrollment here.

Note:

The G6 series sensors only support OpenSSL Security Level 2 and above which provides elevated security. This means that for EAP-TLS, the [public] key on the client certificate which was uploaded on the PKCS#12 file on the dashboard must have 2048 bits and above. For more info, you can read here.
​

Advanced troubleshooting:

In most of the cases, we see an error code negative 3, the sensor gives up waiting for a response from the AP after 802.1x authentication fails. AP will ignore clients sometimes if there have been too many authentication errors. Sometimes you may have a RADIUS server in Datacenter DC or in the cloud, hence path latency, and packet loss causes RADIUS packets(Access-Request/Challenge/Reject/Accept) to drop.

Clearpass Example configuration:

This example talks about using Clearpass as a Certificate Authority(CA) and the RADIUS server. In Clearpass onboard under onboard > Certificate Authorities > Run CA in root mode and you can check the certificate that has been issued so far to the clients. If you don't have one then you can generate a new certificate signing request.

Note: Common name will match a user with Clearpass policy manager.

Once the certificate is created go ahead and export the certificate with the key [format: PKCS#12(.p12)] and give this key a password.

You can upload this certificate to a wired or wireless network using our help article 802.1X authentication on wired networks.

Once the sensor starts testing that network with a certificate, you should see the sensor under Clearpass policy manager > Configuration > Identity > Local users with the role.