Security

 View Only

  • 1.  RADIUS Private Certificate Authority Justification

    Posted Sep 06, 2023 12:46 AM

    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):

    1. Server certs issued by a private CA can be valid for longer than 12 months, therefore, there is no need to replace the certificate each year. This obviously isn't relevant to the HTTPS cert.
    2. A public CA might change or retire the root CA it is using, forcing a config update to clients. Using a private CA gives you the flexibility and control to change or retire a root CA if you wish to.

    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?



  • 2.  RE: RADIUS Private Certificate Authority Justification

    Posted Sep 06, 2023 01:41 AM

    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.




  • 3.  RE: RADIUS Private Certificate Authority Justification

    Posted Sep 07, 2023 07:42 AM

    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.



    ------------------------------
    Bruce Osborne ACCP ACMP
    Liberty University

    The views expressed here are my personal views and not those of my employer
    ------------------------------

    Original Message


  • 4.  RE: RADIUS Private Certificate Authority Justification

    Posted Sep 06, 2023 06:52 PM

    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:

    1. Clearpass used to require that RADIUS certificates have the id-kp-EAPoverLAN OID in the Extended Key Usage (EKU) section of the certificate, and would generate an error on import otherwise.  My guess is this was for Windows 8.1 compatibility.  Clearpass does not seem to require this anymore, and I have not observed any downside to not having it.  This removes an obstacle to using public certs.
    2. I have heard that wildcard certificates do not work properly on Windows supplicants.  This is something I should probably test again.  Nearly all of our customers who have public certs use wildcards for cost reasons, and will try to use them if not warned about this.



  • 5.  RE: RADIUS Private Certificate Authority Justification

    Posted Sep 07, 2023 07:40 AM

    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.



    ------------------------------
    Bruce Osborne ACCP ACMP
    Liberty University

    The views expressed here are my personal views and not those of my employer
    ------------------------------



  • 6.  RE: RADIUS Private Certificate Authority Justification

    Posted Sep 07, 2023 08:10 AM
    I don't see this as a security justification. 

    If users are trusting the RADUIS cert themselves, then the root CA is irrelevant. Most users will trust whatever is thrown their way, regardless of what the cert actually says. 



    Original Message


  • 7.  RE: RADIUS Private Certificate Authority Justification

    Posted Sep 07, 2023 08:32 AM

    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.



    ------------------------------
    Bruce Osborne ACCP ACMP
    Liberty University

    The views expressed here are my personal views and not those of my employer
    ------------------------------

    Original Message


  • 8.  RE: RADIUS Private Certificate Authority Justification

    Posted Sep 07, 2023 08:38 AM
    Obviously but don't you push out the names of your RADIUS server as part of your config? This would stop someone generating certs from the same root CA, regardless of them being public or private.



    Original Message


  • 9.  RE: RADIUS Private Certificate Authority Justification

    Posted Sep 07, 2023 10:18 AM

    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.



    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------

    Original Message


Related Content