Security

Hello,

While deploying 802.1x wired to our network we determined that the default certificate the ClearPass Policy Manager is using is a self-signed certificate.  We could certainly push this out to devices and make the self-signed setup work, but ideally we would not do so for a couple reasons:

 

• OpEx of managing a new certificate store
• De-centralization of certificate management

We have an internal PKI that I am tempted to use by generating a CSR from each of our publisher/subscriber servers, signing, then importing.  These certificates would then have to be all loaded onto each laptop in the company.  We'd also have to do some manual work to ensure that the internal PKI is in the Trusted Root store of all company laptops.

Another option is to use a public CA, something like a DigiCert, and follow the same process.  In this case the DigiCert CA would likely already be in the laptop's Trusted Root store, so we may have a little less work to do.

 

I'd like to see what Aruba/ClearPass suggests as an overall architecture recommendation for RADIUS certificates as a best practice.  Is it recommended to use a public CA for your RADIUS certificates?

If you’re using EAP-TLS exclusively (recommended), a private/internal/Onboard EAP server certificate with an extended lifetime is recommended.

 

If you’re using legacy EAP methods like PEAP and EAP-TTLS, the answer varies:

 

If all of your client devices are managed in some way, shape or form, a private/internal EAP server certificate can be used.

 

If there is a mix of managed and unmanaged devices, a public CA-signed EAP server certificate can be used which will remove the requirement to manually install a CA on the device. However, the client still needs to be properly configured for server trust. This is why these legacy protocols should no longer be used. Another caveat is the max certificate lifetime of a public CA-issued certificate is now 2 years and is expected to drop to 1 year in near future. This futher emphasizes the recommendation to move to a modern method like EAP-TLS where an internal trust can be used/built.

 

Thanks Tim! That pretty much answers my question, so I guess we'll verify the method we're using and likely go with an internal PKI.

Man you're full of good information :)

to say it again like it is said above. If you are using TLS for auth of clients I would suggest you use an internal CA.

 

If using EAP-PEAP use a public wildcard. 

 

In both situations make sure you are setting up your trust of the radius cert within the wireless profile on the computer. Otherwise no matter what cert you use the user will have to at least accept it for the first time. Windows and Apple have move to a method of not using the trusted CA on the computer for wireless auth but setting the trust server settings over rides the prompting.

Never use a wildcard for an EAP server certificate.

Also, users should never be just accepting the certificate themselves. The supplicant should be properly configured or their credentials are at risk.

...

There are many OS version combinations that will reject a wildcard certificate. They should never be used for an EAP server certificate.

sorry mis-spoke. The Guest Portal is setup with a public wildcard. For Radius we are using 1 cert for 3 boxes by popularing the SAN field with the name of all 3 servers. Again if you don't have an internal CA use a public cert and tie the client to the name and cert of the clearpass servers. 

 

Just an FYI (it will save you a bunch of money), the EAP server certificate only needs a single, generic name for the common name (and is automatically populated to the SAN). Ex: secure-login.yourdomain.com

So let's say my publisher server sends in a CSR to my internal PKI.  The CA signs it, then I import it to the publisher server.  I can then use that for 802.1x EAP-TLS authentication if I also import the certificate onto my corporate laptop (we trust the internal CA already).

 

Question - do I have to do the same for all my other subscriber servers, or can I use a SAN alternate name for each of the other subscribers, then import that same CSR that was signed?

The EAP server cert should be the same across the entire cluster. No SANs are required for each node (outside of the common name being a SAN). The common name can be generic, ex: secure-login.yourdomain.com.

And just for my own clarification (certificate novice here), when you say EAP server cert you mean the RADIUS certificate for each CPPM server in the cluster?

Thanks again for all your help.

Yes, there's really no such thing as a RADIUS server certificate. Just a technicality.

 

@apkeene the individual servers do not need to be SANs in the EAP server certificate.

I'll try it next time we swap the cert out. The box was setup this way by partner engineer.

Cool, thanks guys! Hopefully I can get this pushed through by next week.  If I have great success, I'll try to update this thread so it can serve as a reference to any other certificate novice who stumbles across it in the future.

Create a CSR on the Public and add all nodes FQDN in the SAN field. Then load that one cert to all the boxes as the Radius cert. If your clients trust your CA no need to add the cert to the client. In the Wireless profile on the client it needs to be tied to the server names and only the one CA authority. In windows you are looking for the screen similiar to above.

 

 

 

---

@cappalli wrote:
Just an FYI (it will save you a bunch of money), the EAP server certificate only needs a single, generic name for the common name (and is automatically populated to the SAN). Ex: secure-login.yourdomain.com

---

 

A quick question on this.. I'm researching certificates to help carry a customer through their CPPM upgrade.

 

If we're referring to the EAP certificate, wouldn't public certificate validation fail without the use of SAN entries?

 

For example:

clearpass.domain.com -> Not resolvable

Server 1 -> server1.domain.com -> 10.0.0.1

Server 2 -> server2.domain.com -> 10.0.0.2

Server 3-> server3.domain.com -> 10.0.0.3

 

I would think the SAN entries would be needed for validation to pass.

 

My original thought was to have something more akin to the following:

 

server1.domain.com -> 10.0.0.1

DNS: server2.domain.com, DNS: server3.domain.com

 

server2.domain.com -> 10.0.0.2

DNS: server1.domain.com, DNS: server3.domain.com

 

server3.domain.com -> 10.0.0.3

DNS: server1.domain.com, DNS: server2.domain.com

As an aside, all officially published information on this is contradictory at best and at worse contains inaccuracies. I've seen multiple official publications that make different recommendations and even the certs white paper seems out of date.

Honestly, EAP Certs (for 802.1x) do NOT have to resolve to anything.  only captive portal certs needs to have a SAN that could resolve to the ip address(es) of the Captive Portal Servers.

 

Again, certificates solely for 802.1x do not need to have a hostname that resolves to anything.

Even if a customer is using a public certificate for 802.1x, the hostname is not validated against any name resolution during the 802.1x conversation and SANs do not need to be defined, as a result.  SANs would possibly need to be defined for Certificates that are on a Captive Portal Server (there is more explanation about Captive Portal Certificates, but in this conversation we are only talking about certificates used for the 802.1x process).

The customer is using EAP-PEAP exclusively in their environment and frequently gets pop-ups when they change which ClearPass node they are authenticating against, for example.

 

I would think at the very least a SAN cert would eliminate this issue? They will move to PKI soon but aren't quite ready for the change.

The popup has more to do with Trust settings on the client side more than anything else. The client must be configured to trust all of the EAP certificates, otherwise they will get a popup when they authenticate to the same SSID with a different server certificate.

Hi Tim,

 

I dont understand how our selfcertificate from clearpass and getting sign with internal CA (AD) is working.

 

I am generating the CSR from CPPM and getting signed with CA.

 

Here i belive already AD having CA with root certifcate that need to be install in the user device and singned CSR cerficate need to upload in the CPPM. Post that how user identity certificate is working and which is the user identity certificate here... 

We ended up using our internal PKI to sign a Service Certificate and applying that to our 802.1x service policy.  Since our corporate assets by default trust the internal PKI root CA, when presented with the Service Certificate it knows to trust that. The Service Certificate is presented under the Configuration->Services->(Your Service name)->Authentication->Service Certificate section.  It needs to be uploaded to the Administration->Certificates->Certificate Store->Service Certificates tab beforehand, though.  

 

I don't think a SAN or common name at this point of the auth process matters much, as the client still can't perform a DNS query when the port is unauthenticated?

Ah, that makes sense and is the end should have been rather obvious. Ha