Security

We currently authenticate our wireless users via EAP-TLS using the built-in PKI on Clearpass, with a certificate chain that looks like the following:

 

Clearpass Local Root --> Clearpass Local Root (signing) --> client certificates and RADIUS server certificate

 

This works just fine, however as we look to expand this we're looking to introduce a windows CA to issue certs to managed clients so as not to consume thousands of onboard licenses. To keep the existing clients working without reconfiguration we can't change the root or the server certificate.

 

What I've been trying to do is create a new Windows CA that is a Subordinate CA from the certificate chain above, so I create the new subordinate CA, generate the CSR, sign the CSR as a "certificate authority" certificate in Clearpass and install the resulting intermediate into the Windows CA. This all works, and the windows CA can happily sign user certs with a trust chain that looks like the following:

 

Clearpass Local Root --> Clearpass Local Root (signing) --> Windows Intermediate CA ---> client certificate

 

I've cut a couple of test client certificates via the Windows CA and am running into a SSL Handshake failure when trying to auth using them, with the following error:

EAP-TLS: warning alert by client - close_notify
eap-tls: Error in establishing TLS session

 

I was hoping, maybe naievely, that because the RADIUS server cert and the client certs chain to the same root (even though they're signed by different intermediates) they would verify okay.

 

Is this a configuration that should work? Or is it fundamentally flawed and should I look to structure the CA heirachy another way (preferably without breaking existing clients and requiring me to change SSID/roll out a new set of profiles/etc)

 

 

The radius server cert doesn't have to be signed by the same CA but it does have to be installed on the client and configured in the trust list. 

Sent from Nine

Besides that the RADIUS server cert and the client certs can originate from a different Root CA, your client certs can as well originate from different root CAs.

 

So there was no need of signing your Windows CA by the ClearPass CA; just adding the Windows CA in the ClearPass Trust list would be enough.

 

You then have 2 situations:

- Onboarded clients: The client has the RootCA for the RADIUS Server certificate (which is the ClearPass Onboarding CA as you configured it) pushed to validate the server certificate; the ClearPass server has the Onboard root CA (and the siging CA) in the Trust list to validate the client certificates.

- Windows PKI enrolled clients: You will need to push the ClearPass Onboarding CA (as the root for your RADIUS certificate) to your clients and make sure that the server certificate is checked by the client; the WIndows PKI root (and signing/intermediates if used) need to be imported into the ClearPass Trust List for ClearPass to validate the client certificates that were issued by your Windows PKI. 

 

So there is no need that all client certificates are issued by the same PKI.

And there is no need that the RADIUS server certificate is issued by the same PKI.

 

Having said that, what you built, Windows PKI as intermediate under the ClearPass built-in PKI Root, should work in my opionion. You still need to import and enable the Windows PKI in the ClearPass Trust List.

 

Personally I would split CAs as much as possible to make it easier and to reduce unintended trust relations that may be introduced by linking multiple CAs.

 

If you want to read more on this topic, I would advise you to read the ClearPass Certificates 101 Technote as available on the Aruba Support Website under documentation; Software Documentation; ClearPass; Technotes. (https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/EntryId/7961/Default.aspx).

Thanks! Super informative and cleared up a couple of misconceptions on my part.

 

So the client needs the Radius Server cert itself + the chain to the Radius server cert's root installed locally and trusted - is this in the user's keychain or the system keychain (on OSX)? In the past here JAMF/SCEP has done this so it's been pretty opaque and I'm now trying to get my head around the mechanics of it and make sure that we're pushing the correct thing before moving on.

 

 

 

 

Just the root CA for the ClearPass RADIUS certificate in the client should be enough. You can double-check, but it should be that the intermediate certificates are with the RADIUS server certifcate in ClearPass and it will send the intermediate(s) out with its server certificate. This makes is possible for the client to just have the root CA as the intermediate(s) are sent by the server.

 

I'm not sure about the different certificate stores, it might make sense to put the root in both stores. It might depend on the type of authentication (user or computer), but it might also be that for a user authentication both user and system store are checked. For machine authentication, it should be in the system store as you don't have a user store. But again, I don't have the experience on OSX. Pushing the cert to both stores should not hurt and might be a safe bet.