Security

Just upgraded our building (dev) servers to cppm 6.8.1. I'm running a 2 node cluster

 

While everythnig seems to work, I've noticed that whenever I try and access Access-Tracker records for the slave publisher I get a db connection error. See attached file

 

Everything worked in 6.8.0 and does work in 6.8.0 as thats what our production cluster is using

 

During the . upgrade I did notice some warning/error messages about ensuring tht the clearpass cert contained server IP addresses in the SAN field... we don't have these. Might this affect the master publisher extracting info from a cluster member ? 

 

 

We tried to reproduce the issue in internal testbeds. But we are not seeing the issue you mentioned  . Did you follow any specific steps to see this issue?

Nope, 

 

just logged onto the master publisher, went to access tracker and clicked on entry from non master publisher cluster member. Still doing it now if you want to remote session to it

 

Everything else is working ... 

Happening here too. Investigating for more details.

I just fixed this by regenerating new DB Server Certificates with all the IP addresses of every Policy Manager node in my cluster, and rebooted. Everything works fine now. 

o.k. thought everyrthing was o.k. here because of the following in the release notes

 

When ClearPass is updated from 6.8.0 to 6.8.x, the default self-signed database server certificate is automatically regenerated and will be valid for five years instead of one year. Similarly, in future when a 6.8.x system is upgraded to a major version, a new default self-signed database server certificate with a five-year validity will be generated. This change only affects the default database server certificate; any Certificate Authority (CA) signed database certificate you might have created is not replaced. (CP‑33732)

But obviously not, so how do I recreate the db server cert? is  that the same as the https cert ?

o.k. found it, so this can just be a locally generated certificate then ?

Yes

one final ( probably silly)  question, each self generated cert only has the IP addresss associated with that server in the SAN and not all the ip addresses in a cluster ?

A

I’m not positive but I would include the IP to be safe. I know the IP needs to be in the San field of HTTPS cert for DUR

o.k. so I'll put all the IP addresses of cluster members in the san field.

 

>

>I know the IP needs to be in the San field of radius cert for DUR

>

 

Really? is there a manual entry for that?

 

Note:- Yes found that entry, hence the questipn about all the IP addresses in a cluster or just the IP addresses associated with a single member of the cluster

 

I'm doing downloadable user profiles at the moment and they don't need the SAN to have IP addresses in the HTTPS cert.

 

The reason I ask i that DUR are next on the list to try out and

We  run 2 clearpass clusters both with the same HTTPS cert ( production and building(dev)). The prodn one has 6 nodes some of which have 2 ip addresses. If I need to specify all IP addresses associated with all clearpass cluster members the cet is going to be ijnstalled on ... that's a lot of SAN entries for a HTTPS cert if you;re adding cluster node names as well

 

I typed radius instead of https. I just updated my post just before you posted...lol. Did some testing the other day and on self signed and I needed to put IP in the SAN. I might be wrong on the requirement but since I was not using FDQN I put the ip in San. It’s late here but I can test in the morning

:-)

Database cert is the important one at the moment. DUR is for another day but any tests you could do would be much appreciated

Rgds

Alex

 

o.k. Finally got things working.

Firstly I tried  generating a cert with SAN entries of the form IP:<cppm1>,IP:<cppm2>.... etc.  did this over the whole cluster and rebooted them all.

 

This worked from the point of view that in Access Tracker I could view all entries from every cluster member ( 2 in this case). The problem was that although this bit did. work, replication didn't  so so I started seeing replication errors in the event log. If left unchecked I guess my cluster members would have dropped out of the cluster

 

I then changed the SAN entry to be of the form DNS:<cppm1>,DNS:<cppm 2> ...... and rebooted them all

And this time not only did Access-Tracker work but so did replication.

 

Final tidy up increasing the cert lifetime to 5 years and that's it sorted.

 

At some point I'll do our production cluster , but that'll require a SAN statement with 10 IP addresses

 

Thanks to jpearcy00 for his comments

Yeah sorry for lack of details before. I was mobile. Same for me IP:<IP Address> fixed Access Tracker but cluster replication was still hosed. DNS:<IP Address> was the key for me as well.

Not a problem, got there in the end :-)

 

 

Just found this in the help

Enter the alternative name for the specified Common Name. This field is optional. Enter the Subject Alternate Name in one of the following formats:
email: email_address
URI: URI
IP: IP_address
dns: DNS_name or IP_address
rid: ID
NOTE: When configuring a Database Server Certificate, either the Common Name or the Subject Alternate Name (SAN) DNS name must be set to the IP address (also, both fields can be set to the IP address if desired).