wireless networking - In the context of using RADIUS for WPA2 enterprise, what does a "client certificate" mean, if anything?

06
2014-04
  • Prateek

    I'm trying to set up a RADIUS server for WPA2 enterprise authentication. I'm new to all this. I understand that the server has a "server certificate", which I assume plays a role similar to that played by HTTPS and SSH server certificates. Does there exist a concept of "client certificates"? Is that a meaningful notion here? If so, how are they used and what purpose do they serve?

  • Answers
  • Spiff

    The Short Version
    Yes, there's a concept of "client certificates" or "user certificates". They actually exist in the TLS (TLS being the modern successor to SSL, the security scheme for HTTPS) world too, but they're not in common use there.

    EAP-TLS is the authentication method within the WPA2 Enterprise/802.1X/EAP/RADIUS world that uses certificates for authentication in both directions. It's the authentication parts of TLS packaged as an EAP authentication method.

    Because of how difficult it is to provision and manage certificates for every user or every client machine, most organizations don't use user certs for authentication. But note that "Smart Card" authentication actually uses user certificates behind the scenes. So if your org already issues Smart Cards to everyone, EAP-TLS is for you. This is why the Windows UI for selecting EAP-TLS (in the Windows Wi-Fi client UI) calls it "Smart Card or other certificate".

    Some sites use TLS client certificates as "machine"/"device"/"system" certificates, so that a machine can get onto the network without user interaction. This is useful if you want the machine to stay on the wireless network for remote management and backups even when no user is logged in.

    The Long Version
    If you know about HTTPS, then you know it implies SSL or TLS, and you probably know that TLS is the modern successor to SSL. You already probably know about how TLS uses X.509 server certs to allow a client browser to authenticate a server, but did you know that TLS can use certificates in both directions? Yep, you could issue X.509 certs to your users and have them install them on their client machines (or in their browsers), and then your web server could authenticate your users via certificate instead of password.

    If you've ever used "Smart Card" authentication, you've actually used X.509 user certs behind the scenes without realizing it. Smart Cards allow user certs—especially the private keys that mate with the public keys in the certificates—to be stored securely within the card.

    So now let's talk about WPA2-Enterprise. WPA2-Enterprise uses a technology called "Extensible Authentication Protocol (EAP) over Local Area Networks (LANs)" or "EAPoL". EAPoL was standardized in IEEE 802.1X, and applied to IEEE 802.11 along with other security fixes and updates in IEEE 802.11i. Then the Wi-Fi Alliance went and created a certification and logo licensing program based on 802.11i, and called it "WPA2", and when you use the optional 802.1X parts of WPA2, it's called WPA2-Enterprise.

    EAP pre-existed EAPoL. EAP was a technology that came from the PPP dial-up days, when the built-in authentication methods in PPP were kind of weak and hard to modify, so the industry came up with a kind of pluggable authentication scheme for PPP and called it EAP. RADIUS was already in use as a way to keep PPP credentials on a central server, so RADIUS servers formed the "authenticator" (server) side of EAP. By the way, since many VPN technologies use PPP inside an encrypted tunnel, EAP has been common in the VPN world as well.

    So when you hook up WPA2 Enterprise to RADIUS, you're really hooking up 802.1X (EAPOL) to RADIUS, and doing an EAP-transported authentication between the Wi-Fi client and the RADIUS server.

    Since EAP is extensible (pluggable), there are many authentication methods (EAP methods) you can plug into EAP. For example, if you like the authentication parts of TLS, you can use those in EAP, and it's called EAP-TLS. Or you can use a EAP method called "Protected EAP" (PEAP) which is really "EAP-within-EAP". As the inner EAP method in PEAP, many people choose to use EAP-MSCHAPv2 or EAP-GTC, but some people use EAP-TLS inside.

    Lots of companies, most notably Microsoft and Cisco, have tried to make it easier to get user or machine certificates onto users' devices, so there are ways to set up your Windows Server environment or your Cisco network environment such that the network tries to push certificates onto your users' machines when they first connect to the network. One such effort is called SCEP, the "Simple Certificate Enrollment Protocol".

    Some sites like to have ways for a laptop to be securely authenticated to the Wi-Fi network even when no user is logged in (for the purpose of system management, unattended overnight backups, etc.). Since no user is logged in, the users' certs (or at least their private keys) are not accessible to the system. So Windows machines, Macs, most smartphones, and other devices have ways to install a "machine/device/system" certificate onto the machine, so that the machine uses its own certificate (not any of its users' certificates) to authenticate to the network when no user is logged in. Some sites even use machine certificates to authenticate the machine to the network even when a user is logged in, because they don't want to bother their users with having to log into the Wi-Fi network themselves.


  • Related Question

    networking - What is a Valid Trust Anchor in Windows 7 relating to Wifi?
  • WiredPrairie

    The error below just started happening at work with a personal laptop running Windows 7 Ultimate. I'm unable to use installed, non-expired certificates to connect to a private wireless network. No recent changes were made by IT that would explain the issue. It worked fine several weeks ago and happens on two laptops I own.

    The details and some screen shots are here: http://www.wiredprairie.us/blog/index.php/archives/906

    The error we don't understand is this:

    The credentials provided by the server could not be validated. We recommend that you terminate the connection and contact your administrator with the information provided in the details. You may still connect but doing so exposes you to the security risk by a possible rogue server.

    The server XYZ presented a valid certificate issued by Company Name Certificate Authority but Company Name Certificate Authority is not configured as a valid trust anchor for this profile.

    We don't know to to resolve the issue without ignoring the error (nor what's changed that could explain this new error).

    Update: The new information is that we have our own Root CA, and that the certificates were not updated recently, nor have any expired.


  • Related Answers
  • Windows7User

    I ran across the same issue. Found the answer.

    1. Go to Control Panel > Network and Internet > Manage Wireless Networks.

    2. Open the wireless network. Or, click the "Add" button to create a new network, then open it.

    3. The Wireless Network Properties window appears. Click the Security tab.

    4. Under "Choose a network authentication method", select "Microsoft: Smart Card or other certificate". I assume this is already selected.

    5. Click the "Settings" button.

    6. The "Smart Card or other Certificate Properties" window appears.

    7. Here is the answer. Under the "Trusted Root Certification Authorities" list, you have to manually select the Root CA of your company. By default, these are all blank. That is why the warning message appears the first time if you do not select your company's Root CA. If you connect despite the warning, then your company's Root CA is now selected, and you no longer get the warning on subsequent connections. So, to avoid the warning, just select this box when you set up the network, before you connect for the first time.

    8. If you do not see your company's Root CA here, that is likely due to the fact that by default, double clicking your certificate to install it probably puts it under the "Intermediate Certification Authorities" tab. You need to select the "Trusted Root Certification Authorities" tab instead. You can see where certificates go under: Internet Explorer > Internet Options > Content > Certificates

  • MDMarra

    The way an SSL certificate is authenticated as valid is by following a chain of trust. Whatever cert that your company is using to secure wifi is then validated against (at least) one intermediate certificate that verifies that it is legit. That intermediate certificate is, in turn, authenticated against a root certificate from a verified and trusted company.

    The way the root certificates are validated as authentic and can be trusted is that Microsoft builds trust into Windows for certain certs, but these roots are usually outdated and don't have some major players in the SSL cert game. Verisign and Thawt usually have no problems, but Digicert (Entrust.net) is a huge SSL cert company that isn't natively trusted by Windows for 802.1x (which I'm assuming your wifi is using to authenticate based on the screen shots provided). This means that the cert is probably valid, but your computer doesn't know to trust it. You can certainly import that root cert as a trusted cert so that you aren't prompted with this any more. I would contact your system administrator about how to do that.

    This could be caused by either the expiration of an intermediate or root cert if your company uses their own CA, or by them issuing a new root cert and not deploying it to you.

  • studiohack

    I got to exactly the same point. If I accept the certificate warning, a userid / password prompt appears. If I enter my userid (the common name of the client cert - I shouldn't have to enter it), and leave the password blank, I successfully connect. Pretty weird and not how it was before.

    Edit. All sorted. I had manually entered a wireless network profile, and used a lower case name whereas the corporate wireless starts with an uppercase letter. My successful connection mentioned earlier was not using my manually created profile at all. Once I defined a correclty named profile, it all worked as it used to.