Today, I'm going to share a secret with y'all: I HATE troubleshooting certificates. In recent time, I have learned some tricks so I do not hate it as much, but I still feel I'm looking for needles in a haystack often. For simplicity's sake, I will discuss an EAP-TLS scenario for an 802.1x wireless SSID using client certificates without OSCP or LDAP protocols.

Before going through some tricks, lets review the fundamental components for an EAP-TLS based SSID. EAP-TLS requires certificate installation on the client and server. In a typical wireless configuration interface, you will see the following terms:
Certificate Authority - Called the root CA. Provides root certificates for verification
Root Certificate - Called the root certificate/root CA certificate and acquired from the certificate authority
Intermediary Certificate - Installed on the "Authenticator" device in AAA terms. This is could be the AP or wireless controller, depending on the vendor architecture.
Client Certificate - Generated from the intermediary certificate and installed on the client
Certificates are validated in a chain of trust from the client certificate to the intermediate certificate to the root certificate. This chain of trust is used to establish the TLS session inside EAP-TLS. For a more in depth explanation on the the entire 802.1x SSID process with EAP-TLS, check out Rasika Nayanajith's blog here. Without further ado, lets dive into how to make sense of WiFi certificate validation for EAP-TLS.
Read up on the required settings for each certificate
Each of the aforementioned certificates have settings requirements that if not set properly, will cause the EAP-TLS session to fail. Here are a few common issues I have encountered and the source for the requirements:
-RFC 5280 - keyEncipherment or keyAgreement bit must be enabled on the root and client certificate in keyUsage
-RFC 8446 - digitalSignature bit must be enabled on the root and client certificate in keyUsage
-The client certificates need to have the clientAuth bit set in extendedKeyUsage
-The root certificates need to have the serverAuth bit set in extendedKeyUsage
-The certificate validity must be for the correct time (unexpired).
Read these references and become familiar with them if they find themselves deploying certificates often. So now that we know what could go wrong, how do verify these settings? There are two ways:
-Use OpenSSL to open the certificate and view the attributes. This is my preferred way because the packet captures will show unrelated certificate sections and can be hard to interpret.
In this example, the client certificate here is set for clientAuth (SSL client, "X509v3 Extended Key Usage: critical TLS Web Client Authentication") and has the digitalSignature/ keyEncipherment bits enabled. This is the correct setting for the client certificate:
% openssl x509 -noout -in [client cert].pem -purpose -text
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : No
SSL server CA : No
Netscape SSL server : No
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : No
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
Time Stamp signing : No
Time Stamp signing CA : No
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=[Organization name}, OU=[OU name], CN=[Common Name here]
Validity
Not Before: [date here]
Not After : [date here]
Subject: CN=[Common Name here]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
Exponent: (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
URI:, DNS:
X509v3 Authority Key Identifier:
keyid:
X509v3 Subject Key Identifier:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: critical
TLS Web Client Authentication
-Look at an OTA capture of the authentication attempt. This is a failing example due to the digitalSignature bit being set to false. Otherwise the keyEncipherment bit and clientAuth bit are set correctly:
Frame
Radiotap Header v0, Length
802.11 radio information
IEEE 802.11 QoS Data, Flags: .......T
Logical-Link Control
802.1X Authentication
Extensible Authentication Protocol
Code: Response (2)
Id:
Length:
Type: TLS EAP (EAP-TLS) (13)
EAP-TLS Flags: 0x00
[4 EAP-TLS Fragments (bytes): ...]
Transport Layer Security
TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length:
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
Length:
Certificates Length:
Certificates (bytes)
Certificate Length:
Certificate [truncated]:
signedCertificate
version: v3 (2)
serialNumber:
signature (sha512WithRSAEncryption)
issuer: rdnSequence (0)
validity
subject: rdnSequence (0)
subjectPublicKeyInfo
extensions: 9 items
Extension (id-ce-keyUsage)
Extension Id: 2.5.29.15 (id-ce-keyUsage)
critical: True
Padding: 5
KeyUsage: 20
0... .... = digitalSignature: False
.0.. .... = contentCommitment: False
..1. .... = keyEncipherment: True
...0 .... = dataEncipherment: False
.... 0... = keyAgreement: False
.... .0.. = keyCertSign: False
.... ..0. = cRLSign: False
.... ...0 = encipherOnly: False
0... .... = decipherOnly: False
Extension (id-ce-extKeyUsage)
Extension Id: 2.5.29.37 (id-ce-extKeyUsage)
KeyPurposeIDs: 4 items
KeyPurposeId: 1.3.6.1.5.5.7.3.7 (id-kp-ipsecUser)
KeyPurposeId: 1.3.6.1.5.5.7.3.2 (id-kp-clientAuth)
KeyPurposeId: 1.3.6.1.5.5.7.3.4 (id-kp- emailProtection)
KeyPurposeId: 1.3.6.1.4.1.311.10.3.4 (id-ms-kp-efs)
Ensure your client is using the correct certificate
Unfortunately, you can have everything set correctly with the certificates and still have authentication fail because the client chooses the incorrect certificate. Ensure that your client is configured to pick the correct certificate and not other ones for MDM services. Chances are if you look at the logs or packet capture and see the "CN"(Common Name) does not match the name of your desired certificate, the client probably decided to make your life more difficult.
Verify certificate chains with OpenSSL
The last way to use OpenSSL is using it to verify the whole certificate chain. This requires having a copy of each certificate, but can rule out issues on the certificates themselves. However, this does not rule out issues such as the client selecting the wrong cert or additional vendor validation steps.
To verify the intermediary and root certificates, use this command:
% openssl verify -CAfile [intermediary cert].pem [client certificate].pem
[client certificate].pem: OK
Read the vendor-specific documentation for the 802.1x SSID feature
Each vendor will have difference architecture and therefore, different ways to validate to the certificate. Check your vendor documentation to see if the CN (Common Name) needs to match the username value from the client. For example, Meraki access points require "If certificate-based authentication is used, the MR will additionally check that the provided username matches either the CN or userPrincipalName in the certificate, since the username would otherwise be unauthenticated."
Additionally, vendors may limit the acceptable certificate formats. You may have to convert them from the format they were received. For example, Aruba accepts "X509 PEM unencrypted, X509 PEM encrypted with a key, DER, PKCS7 encrypted, PKCS12 encrypted"
Either with help of my peers or research, I have discovered some of these quirks. Of course, the exact troubleshooting will vary based on the EAP mode, but looking up the RFC for the interior protocol should give clarity on what to look for. If I was using EAP-PEAP instead of EAP-TLS, I would read RFC 8940 (Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP)) instead of RFC 8446 for TLS. I hope this helps some of you all not hate certificate troubleshooting.
Sources:
Title image - SatawatDesign - Flaticon, Gemini AI image generation
RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
Comments