top of page

🔐Troubleshooting WiFi Certs with Certainty

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.


computer network on fire
AI generated picture of "computer network on fire".

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:

Comments


Comments

अपने विचार साझा करेंटिप्पणी करने वाले पहले व्यक्ति बनें।

Send a unicast message here.

Thank You For Reaching Out!

© 2021 Wifrizzy. All rights reserved.

bottom of page