topic Re: Replacing ISE Admin cert on multi-node deployment in Network Access Control

Replacing ISE Admin cert on multi-node deployment

Arne Bier — Mon, 07 Jan 2019 04:20:30 GMT

Hello

I don't have the time to test this myself, but has anyone got real world advice when replacing the Admin cert of a multi-node deployment?

The customer is running ISE 2.4 in a 6 node deployment on SNS appliances.

Currently the Admin cert is a self-signed wildcard cert. This cert was installed on all secondary nodes prior to the nodes being registered to the PAN.

Customer now wishes to apply a different cert (e.g. public CA cert) to all the nodes used for Admin and possibly also EAP.

I have some concerns with this.

The node host name domains will need to match the new Admin cert (at least in the SAN field, right?) - if customer has some internal domain like net.local, then there will be no Public CA that can issue a cert that has this in the SAN field. I suspect we'd have to re-configure all the "ip domain-name" commands in each node prior to even trying to import a public CA cert?
Let's say we have all the domain stuff out of the way, which node do we start with? If we start with the PSN's, will it isolate the PSN from the PAN when installing the new Admin cert? Is there an order in which this should be done?

I am pretty sure that changing the System cert for Admin will cause the application services to restart. The outage is not an issue. The main concern I have is that the ISE cube (cluster) will someone get messed up because of the changing of domains and the importing of certs.

any advice appreciated

Re: Replacing ISE Admin cert on multi-node deployment

Francesco Molino — Mon, 07 Jan 2019 05:08:51 GMT

For the EAP, you could have the possibility to create a new interface and an alias then your public cert will work.

However for the admin, it'll only be on the default interface and you have no choice to change the domain name.

Then you can import them node by node, i start myself from PSN and finish with PAN. Customers like simplicity and most of them generate 1 cert with multiple SAN and then import the same one on all node. Never had issues here.

Issues i had, were mostly after changing domain name. There were weird issues like AD sync/join not working as expected and needed to unlink and link it back sometimes. Also issues with internal CA, the biggest weird issues was that i had to disable, generate new certs for internal ca and re-enable it back (impact on all my byod users).

Sometimes i also had to deregister the node from the cluster and register it back after domain-name changed.

This doesn't mean it never work (most of the time it works good), after an automatic application restart, everything is back to normal.

Anyway when you will do the command ip domain-name, a message will appear to tell you to de register your node from AD before proceeding. I'm not doing it everytime i do these changes because AD people aren't available/communicating with network guys 🙂

When i do the domain name changes, i always start by PSN.

Re: Replacing ISE Admin cert on multi-node deployment

Arne Bier — Mon, 07 Jan 2019 05:17:03 GMT

thanks @Francesco Molino - very useful advice for sure.

I will see whether I can convince them to keep the Admin system cert as is (there is no benefit to assigning that to a public CA cert!!). The EAP cert can then be changed to use a public CA cert without rocking the boat.

thanks

Re: Replacing ISE Admin cert on multi-node deployment

Francesco Molino — Tue, 08 Jan 2019 04:02:11 GMT

Yes and you can mention that admin will be accessed from internal guy only that will have the internal root cert in their laptop trusted certificate store which means no need to change it 🙂
Are these ise servers vm or appliances?
If VM, you can take a snapshot before proceeding.
What I did which ended smoothly and without issues is to have a maintenance window and alert that ISE will down during this maintenance. Then remove every node from the cluster, do all domain changes and build up the cluster. Obviously, this can be done in a non critical environment where downtime is acceptable.

Re: Replacing ISE Admin cert on multi-node deployment

Arne Bier — Tue, 08 Jan 2019 06:01:27 GMT

These are SNS servers. I will fight to not have to change the Admin cert 😉

Re: Replacing ISE Admin cert on multi-node deployment

Nadav — Tue, 08 Jan 2019 18:15:10 GMT

VM snapshots aren't supported though. Perhaps you mean shutdown the server and clone the VM (unsure if this works either)?

Re: Replacing ISE Admin cert on multi-node deployment

Francesco Molino — Tue, 08 Jan 2019 18:17:51 GMT

Yep not supported but it works, I did it several times to keep a fresh install.
Now yes, the safest way would be to shutdown it and backup the vm files.

Re: Replacing ISE Admin cert on multi-node deployment

Parag Mahajan — Tue, 08 Jan 2019 20:49:41 GMT

Assuming that you have sorted out domain issues means got the cert from publicCA. You can assig new cert in any order as long as Root, Intermediate and Issuing CA cert has been imported in PAN trusted store. It will propogate to all other ISE nodes trusted store. Now even if you take any node and assign this cert for admin and EAP .This node will restart it service but will join the cluster.

Re: Replacing ISE Admin cert on multi-node deployment

mmintz001 — Fri, 15 Feb 2019 14:56:36 GMT

Are there any issues with using the system certificate for both Admin and EAP authentication? We do not practice this policy but wondered if it is done by others.

Re: Replacing ISE Admin cert on multi-node deployment

Nadav — Fri, 15 Feb 2019 15:00:53 GMT

It's not best practice, but it's possible and supported. Notice when you add a system cert that you can choose which roles it has per node.

Re: Replacing ISE Admin cert on multi-node deployment

MatthewShaw4644 — Thu, 10 Feb 2022 18:39:57 GMT

the trick with changing the domain name of the cluster node is to deregister it from the domain - then DELETE the machine account in the domain - wait for replication to occur in AD (15 mins max) - THEN change the node domain-name and reregister the node to the domain. It's that machine account in the domain that gets wonky - so just smoke the old machine account and create a new one with the proper domain.