Aruba ClearPass Workshop - Wireless #2 - Installing the ClearPass RADIUS certificate

[@sherlyjue4624]

Excellent Herman. Thanks for this video.

[@dominoc5]

Thx Herman. Very useful vids from you :)

Thanks for your sharing Herman..

[@Leokev123]

If my device is a joined domain, do I still need to install the root CA cert?

[@hermanrobers]

Your client device has to trust the RootCA that issued the RADIUS certificate. If your client is joined to the domain, and you have AD Certificate Services installed/configured, and the RADIUS is issued as well by that CA, then I believe there is a default group policy that installs the Root CA on domain joined computers. Bottom line, group policy is the easiest method to get (additional) root CAs on domain joined computers. It's easy to check, just see if the root is installed on your clients. If not, create a GPO to install (any) root CA.

[@ayoubchabrouk891]

Hello Herman, In my CP environment, I have also 4 servers with VIP running between two servers, In addition, I'm using MGMT and Data port. Question: should I follow the same method you used in this video to sign my Radius certification for domain PC that are using EAP-PEAP ?

[@hermanrobers]

In general, it is recommended to install the same RADIUS server certificate on all your ClearPass nodes, so that the clients will see the same certificate regardless to which ClearPass server they are communicating. You should prevent EAP-PEAP whenever possible, with the only exception where you have full control over the endpoints. Do you have an Aruba partner, or Aruba SE that you can consult? There is more information needed like the type of environment and the level of control/management that you have for your clients to find the right certificate source (internal CA/external CA).

[@julianbunte8578]

My button only says "Download CSR". But I need the Private Key.

[@8802082642]

Just wondering why CA cert is not uploaded to subscriber servers?

[@hermanrobers]

That is because the Trust List is synchronized in the cluster, so you just upload it to the publisher and it will be available on all nodes. The RADIUS and HTTPS server certificate are per-node, as there are few cases where you would like different certificates per subscriber.

[@ricardoraul]

hi, is there any scenario that you can think of where uploading the same radius certiticate to all publisher and subscribers is not a good idea? or is it a best practice to upload the same to all servers? thanks

[@hermanrobers]

To be honest, I think only if external people require you to do so. I have seen some organizations that require the private key to be generated on the device itself and may not be exported. Or a rule that a certificate may only be installed on a single device by policy. In those cases there is no other solution than getting a unique RADIUS certificate on each ClearPass server. One argument that may make sense is that if you have the private key compromised on one of your appliances, you will need to re-install the replacement certificate on all your appliances. Also, there seem to be public CA's that don't allow you (officially) to install a certificate on multiple systems (unless you pay for multiple systems). Taking into consideration that CRL/OCSP checking for RADIUS certificates is non-existing, I'm not convinced that those are valid reasons to go through the additional work for installing unique certificates per appliance, as you multiply that risk. In the practical world, I would say unless you have some of these concerns and cannot convince the organization to accept putting the same RADIUS certificate on all your appliances, go for the single cert for all appliances. It avoids some potential issue like users moving with their authentications across multiple appliances that present different RADIUS certs. One valid application may be when you migrate from one RADIUS certificate CA to another, and clients needs to be touched manually to make that change happen. Or you want to move to a renewed certificate gradually. In those cases you can leave some appliances running the old cert, and others running the new certificate. After the change, it is probably recommended to have the same certificate on all your appliances again. Open for suggestions from others who have found a valid reason to run with different RADIUS certificates in a ClearPass cluster.

[@ricardoraul]

Herman Robers thank you for your quick response, one of the main reasons i am asking is because of "onboard" i have noticed that as part of the certificates that a client download as part of the onboarding process (apart from the intermediate and root CA) is the radius certificate of the server. not completely sure what is the idea of downloading the cert (i think it is to only allow connections from that specific server when selecting the security options in the supplicant) BUT what happens if one of the subscribers with a different certificate that the one my client downloaded is now doing the eap-tls authentication? is my client going to pop-up a message because when i downloaded the certs i downloaded radius01.lab.com but when i am trying to authenticate i am presented with radius02.lab.cpm and my supplicant is configured to only trust radius01.lab.com .... hopefully my question makes sense and thanks again for these videos, they are really helpful

[@hermanrobers]

For Onboard, you can select if you want to do automatic or manual configuration of your RADIUS trust. That is under OnBoard -> Configuration -> -> Trust (tab). It should push the CA, not the RADIUS certificate (unless that is self-signed which makes it like a CA). By default, your Onboard configuration should pick the name from the RADIUS certificate (on your publisher) and will push the CA root that issued that cert (to make it easier). This is why you need to add the root cert in the Trust List (as shown in this video). You can manually set either the name for your cert (*.lab.com) and/or the issuing CAs (which allows move to another CA by trusting multiple CA's during the migration). This is by the way an excellent example why you want to put the same RADIUS cert on all your ClearPass nodes; it avoids a lot of complexity. There will be an Onboard video, which I expect in a few weeks to be ready.

[@ricardoraul]

Again thank you for you answer, it makes sense, i can wait for you onboard video but can you confirm that the only radius certificate that is pushed to the clients is the one from the publisher. I am just wondering what happens if the publisher i down and one of the subscribers is doing the onboarding process, it will still push the radius certificate of the publisher regardless if it is down, right? :).... again i can wait for the onboard video just wondering :)

[@riyaskallayil9017]

Great

[@nikhildabas4697]

Pls help to make me understand the use of the password in this case. Had you also specify same password on AD.

[@hermanrobers]

Do you refer to the private key password? You only use that on the ClearPass. The private key doesn't even need to go to the Certificate Authority, just the CSR. You should set a private key password whenever you export the private key, as when someone can find and grab the file, the password is needed to do something with it. So, you only set the password on key export and enter it on key import. And the key never goes to the CA, just the CSR and it returns the certificate that together with the key is needed on the (in this case ClearPass) server. Does that answer your question?

[@nikhildabas4697]

Appreciate your quick response, but picture is still not clear to me. What is purpose of certnew(2).cer here, it is not clearpass cert and why we also providing private key file also for importing part.

[@hermanrobers]

Ok, I checked the video. There are the following files: CertPrivKey.pkey (the password protected private key downloaded from ClearPass), CertSignRequires.csr (The CSR downloaded from ClearPass which contains the same certificate request data as I copied/pasted into the CA). Then the certnew.cer has the by accident downloaded DER format of the CA root certificate, the certnew (1).cer is the correct PEM/base64 CA root certificate and the certnew (2).cer is the signed certificate for ClearPass that corresponds to the CertPrivKey.pkey. So these two files (certnew (2).cer and CerPrivKey.pkey) are imported into ClearPass. We also import the private key as ClearPass doesn't keep it, and it is also easier for archiving the key in case you need it again.

[@nikhildabas4697]

Ok, certnew(2).cer is actual cert of clearpass server. What exactly happens in importing process when we already have this cert?

[@hermanrobers]

If you question is, how to import if you have a certificate already, and don't go through the certificate request process, then you skip that part and just import it. That procedure is shown in Getting started #5 Installing the HTTPS certificate (kzbin.info/www/bejne/Z3qQoWmVnMZpjKM). If you question is what happens if there is already a certificate, that will be overwritten on import of the new certificate.