I regularly hear in Aruba circles that it is recommended to use a private certificate authority for ClearPass RADIUS, for example, in Herman's "Aruba ClearPass Workshop (2021) - Wireless Access #2 RADIUS - Basic part 2" (1:04), and then a public certificate authority for ClearPass Guest/Captive Portals, etc.
I've spoken with a few security professionals (who don't have any specific Aruba ClearPass experience) and they have all said that a public CA should be used on a RADIUS server and think it is unusual for Aruba to not recommend this. They have suggested maybe ClearPass has a particular reason/function/feature unique to ClearPass and maybe this is why it is recommended.
I've read through the "ClearPass Certificates 101" document but I couldn't see any justification for this, other than "Not for deep discussion at this juncture but discussed in a lot more depth later in my TechNote, we support the ability to privately sign a certificate (typically done for the RADIUS certificate)". Maybe I've missed the section where it is discussed in a lot more depth.
I've seen Herman post here the following reasons (this is my understanding of the post):
I don't see these as security reasons to use a private CA, they are management/maintenance reasons.
Is anyone aware of security reasons why ClearPass should be using a private CA for its RADIUS cert?
One slight security reason to use a private CA is that if you use a public CA and your clients are configured to trust that CA, but aren't limited to a set of trusted hostnames for your RADIUS servers, then an attacker could get a valid certificate signed by that CA and then spoof your SSID and capture credentials from clients (if using MSCHAPv2) and generally intercept traffic. Whereas with a private CA you can be sure (unless someone steals your root CA's key) that attackers can't issue their own certificates under it. This is a fairly specific misconfiguration though.
One reason to use a public CA is if you need to support Android BYOD, as getting a private CA cert on there is a real pain without an onboarding tool (and ClearPass OnBoard is very expensive). Eduroam users can use geteduroam to help, but others would have to develop their own solution.
There are solutions other than ClearPass Onboard. Several years ago, when we were looking for a new onboarding vendor (before we decided to use eduroam) we decides to use SecureW2. They have a cloud PKI and no custom solution is needed. At that time, when ClearPass Onboard was priced per certificate, they were over ten times the cost of our eventual choice.
I am dealing with this same debate right now. Customers are experiencing a lot of pain with captive portal detection failure in recent OS builds on Android and iOS. I have one that wants to switch back to plain RADIUS. This is not the received wisdom, due to Android's recent changes regarding RADIUS certificate trust as others have mentioned. I am in the middle of attempting a test of the new CAPPORT features in 6.11 to see if that's the solution, but it would be enormously helpful if someone on the engineering side could update their guidance regarding public certs on RADIUS. A couple of things:
We used to use a public CA certificate with users just trusting the certificate CA chain so we could update the RADIUS server certificate without needing to re-onboard users.
A few years ago, within 1 day of a scheduled certificate replacement, I found out our vendor had changed their certificate chain. We narrowly averted a network outage. Since our onboarding vendor SecureW2 has a clous PPKI we were planning on using for EAP-TLS, we set up private CAs and a 15 year RADIUS certificate. We encourage our users to re-onboard to get the added new trust before deploying.
Using a private CA chain closes the hole of somebody getting a certificate from the same CA chain and our users trusting that. We also do not need to worry about RADIUS server certificate expiry.
Since we were already paying for the PKI, there was no additional expense for us.
With our EAP-TLS SSID users cannot choose to trust the RADIUS certificate. Having them do that is an insecure practice that should be discouraged anyway.
Let me jump in as I have mentioned some point around this in the past.
What you mention is exactly the point. End users should not be in the position to accept certificates, which more or less results in the conclusion that you should have some automation/tooling to get the client configured which would be AD GPO, Intune, MDM, for managed computers and an onboarding tool like ClearPass Onboard, Eduroam CAT/geteduroam, SecureW2 or others. There make sure root, server trust and no allowing users to accept rogue certs is enforced.
Then if you need tooling anyway, there is no benefit of using public certificates and those being pre-deployed in the device in advance. If you trust on trusted certificates in the device, you mean that you want end users to trust that certificate, and indeed they will trust whatever you throw at them. As there are some known limitations with public certs, like short validity times and CAs changing roots over time outside of your control, but with big impact, I would use private certificates.
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.