2

When attempting to connect to our company wireless while not on the domain, I receive a message saying that our RADIUS server provided a valid certificate issued by our root CA, but that the root CA is not configured as a valid trust anchor (on a windows 7 machine).

The root CA has to be manually checked off under security for the wireless network connection in order to remove this message. What is the point of manually telling the system to trust the Root CA? Isn't that the point of having a trusted root CA? Is there any way around this? It becomes an issue when users think our connection is insecure or certificates are out of date. I can't manually configure every machine that may use the wireless.

It's the same as the issue seen here.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
zach
  • 31
  • 2
  • 3

2 Answers2

1

Think about your question for a second.

The "root CA" is the "root CA" for your domain. So yes, it will be trusted by members of your domain, and not by machines that aren't joined to your domain. In fact, if you could get machines to automatically, arbitrarily trust your CA, that would be a rather big security hole rather than a security feature (and is precisely how Stuxnet and Flame installed themselves - with forged certificates from universally trusted CAs).

You should be distributing certificates and CA trusts through GPO, (auto-enrollment) which means you don't have to manually configure every machine that needs to use the wireless, and you can make your life a lot easier by only allowing domain-joined machines (that have those certificates and trusts pushed out to them) onto the company wireless network, precisely so you don't have to manually issue certs and trusts. Of course, you can decide to allow any device that doesn't have the trusts and certificates to use the wireless... but the symptoms you're seeing is the price you pay for doing so.

You can also set up a secondary wireless SSID, protected with a password and segmented off from the corporate network to allow your users to surf the web with their personal devices (and is what we do), if you can't lay down the law and just say "no" to personal wireless devices at the office.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
  • It seems my understanding of certificate trust is lacking. I should add that I am in tier one support for a large company serving users who cannot join the domain, so we can't push the trust profile via GPO. The certificate is validated by a trusted CA, which from my understanding, is already in most up to date windows computers' certificate store. – zach Aug 24 '12 at 13:54
  • @zach In that case, you may want to look into generating a script that checks for the presence of that CA trust (which is stored as an object in the machine/device certificate store), creates it if not present and then checks for a valid certificate signed by that CA, and pushes one out if not found. A lot easier than dealing with users and manually screwing around with adding certificates and such through the GUI. I'll update my answer with a screenshot of the trusted CAs in one of my default Windows installations (VM) so you can see if your CA is actually trusted by default. – HopelessN00b Aug 24 '12 at 14:33
1

Remember that there are three parts to wireless security.

The first is the network wants to know whether the device is allowed on the network. To do this, it needs to be able to accurately identify devices, and will therefore issue a unique certificate for every device. However, to be able to create new certificates for every device means the network must not only acquire it's own certificate, but is also running a full certificate authority (CA).

The second part is client devices also want to know that access points are legitimate, and not rogues using the same SSID trying to tunnel traffic through some random packet sniffer sending the traffic on to it's destination. This is accomplished by having each legitimate AP on an SSID make use a common certificate that a client device can verify.

Finally, the keys in the certificates are used as the encryption keys for the wireless traffic. A forged certificate on either side of the link implies a device in the middle could decrypt and view the traffic in plain text.

It's the second part we want to focus on here. Certificates are part of a chain, and in order for the client to validate an access point certificate it must validate each certificate in the chain, all the way up to the CA at the top. This check can only succeed if the CA at the top of the chain is already known and trusted by the client before connecting to the wireless network.1 To make this and other certificate scenarios possible, operating systems and some browsers come with a pre-configured list of trusted CAs.

As you indicated, domain-joined Windows computers can also be made to trust a CA designated by their domain controller. However, other devices, such as with BYOD or in the absence of a Windows domain, won't know your domain controller or network CA from the random hacker down the street, because the CA on your network is not in the pre-configured trusted CA list.

This is not a mistake or oversight by the wireless administrators. There are relatively few well-known and trusted root CAs, and this is by design. If just anyone could become a trusted root CA, the whole system would break down, because it would be easy to issue forged certificates that looked real.

Unfortunately, that leaves a gap for wireless networks. Wireless administrators must have a CA in order to properly authenticate devices, but this may not be a trusted root CA in order to protect the integrity of the certificate system. For devices within an enterprise, such as with the original vision for 802.1x, it is easy enough to pre-configure devices to trust the network CA. For BYOD scenarios, there's a bit of a problem here... and what network doesn't need to support BYOD anymore?

There are services that address this issue and make including your CA in a client's trusted list transparent to your users and guests.2 It's called onboarding, and the major players that come to mind are CloudPath XpressConnect, Aruba Clearpass, and SecureW2 JoinNow. Cisco also has ISE, and most wireless vendors will have some kind of play in this area.

1 Most operating systems today will allow the user to ignore an invalid server certificate when connecting to a wireless newtork, and just accept whatever it's given. However, this is not good practice. Aside from leaving the client vulnerable to MitM attacks as discussed above, it can put a scary warning message like you're seeing in front of the user that it would be better to avoid.

2 For what it's worth, this state of affairs does not really satisfy me as the best solution. I don't like the idea of allowing random wifi providers to adjust my computer's trusted certificate authorities list. If I were the NSA, for example, attacking CloudPath apps/scripts would be fairly high up my priority list. Additionally, it's always a cat and mouse game with the service providers to support the latest devices and operating systems, especially in mobile. I envision of a future that includes a new kind of limited certificate authority, that perhaps must be registered with existing well-known/trusted certificate authorities and can only issue limited "wifi" certificates.

Joel Coel
  • 12,932
  • 14
  • 62
  • 100