Security

Hi,
I have 2 Clearpass nodes with pub and sub with L3 connectivity. I want to generate CSR for public HTTPS certificate and also I want to use same certificate for both Clearpass nodes so what I should mention in CN field as I am not going to use VIP. Is it fine to keep CN blank and add pub-sub fqdn and IP addresses in SAN field . Plz give me answer of my query with example.

You need to have a common name in your certificate. The CN is also presented to clients when using tunneled EAP. Use something generic like "clearpass.yourdomain.xyz".

 

Also, there are very few use cases that require IP address in the certificate.

Hi Cappali,

 

I am using Symantec PKI service and tried to generate certificate with CSR configuration as below (reference url https://community.arubanetworks.com/t5/Security/Certificate-Question-Two-CPPM-each-in-different-locations-using/td-p/159604  message no 6 )

 

CN : CPPM1.ABC.COM 

 

SAN:DNS:CPPM1.LOCAL,DNS:CPPM2.LOCAL,DNS:CPPM1.ABC.COM,DNS:CPPM2.ABC.COM,IP:192.168.x.x,IP:192.168.x.x

 

There is no rechability to CPPM Public FQDN as i am using private ip address for this. 

 

While i am generating the certificate with Symantec for above CSR , it gives me below error

 

"cannot process IP addresses nor nonpublic reachable FQDNs.

I attempted removing the IP but getting same error.

 

 

 

A public domain is required for a public CA-signed certificate. That does not mean ClearPass actually needs to be public facing.

Also, in 90% of use cases, you don't need to add the IP address to the cert. What are you planning to use IP for? (as a side note, you can not use RFC1918 space in a public CA-signed certificate).

Actually i am following dannys CPPM-Certificate 101 technote and where i  seen that IP addresses has added in SAN field so i have added in my CSR too.

 

What i should do to resolve this issue and generate the Certificate?

 

 

Remove the IPs and be sure you only have public FQDNs with publicly registered domains in your certificate.

Also, the common name of your cert should either be something generic (clearpass.domain.com) or the name you’ll using for a VIP.

PUB-SUB connected with L3 network so i am not using VIP here.

 

As you mentioned that only have public fqdn with publicly registered domain so shall i remove my CPPM local fqdn entried from SAN field.

 

Which CSR configuration shall i use from below

1) 

CN : CPPM1.ABC.COM 

 

SAN:DNS:CPPM1.LOCAL,DNS:CPPM2.LOCAL,DNS:CPPM1.ABC.COM,DNS:CPPM2.ABC.COM

 

2)

CN : CPPM1.ABC.COM 

 

SAN:DNS:CPPM1.ABC.COM,DNS:CPPM2.ABC.COM

 

 

You’ll have to use option 2

When we installed our CPPM last year we were in a hurry for production and got the PUB running a couple weeks earlier than the SUB, so when we generated our CSR we just did it for the PUB.  When we got to the SUB deployment we did another CSR and installed on the SUB.

 

I have seen an issue where clients that roam between the two authentication servers have to trust the "new" certificate (admittedly haven't done a lot of testing, but it made sense to me).

 

I'm about to renew the certificate and would like to avoid this issue in the future, so I assumed I needed to create a new cert for a generic name (i.e. clearpass.domain.com) with 2 SANs (i.e. cppm1.domain.com and cppm2.domain.com).  However, your answer here makes me think I should be able to just use a cert with clearpass.domain.com and it will work fine regardless of which server presents it...is that right?

 

We are using L3 redundancy only, so no VIP.  If authentication fails to the other server it will necessarily be a different IP/hostname.

Your EAP server certificate should be a single name certificate with a friendly CN/SAN (ex: networklogin.yourdomain.com) installed on all nodes in the cluster. If you're using legacy EAP methods like PEAP with unmanaged supplicants, then this will need to be a publicly signed cert. If not, you should always use a private cert.

 

The HTTPS cert needs to be publicly signed and one of the following:

1) Individual certs for each node with the VIP FQDN as a SAN in each

2) One cert for all nodes with each node and VIP FQDN as SANs

3) A wildcard certificate (generally not recommended)