Cisco ISE EAP and Admin Cert Renewal

[OJ_Magellan]

Hi

I am renewing the EAP and Admin Cert for an ISE Cluster that consist of 6 Nodes ( 2 PAN, 2 Mnt and 2 PSN). How should I proceed with CSR binding (6 CSRs, Multi-usage CSR per Node)? should I Bind PAN (Pri) first? or should I start with PSNs and Mnt and leave the PAN (Pri) Till the end? would'nt updating the cluster members one by one break the communication between the nodes? Since they all need to have the same Admin Cert to communicate?

Any Suggestion on how to renew the Certs?

Regards,

OJ

[Marcelo Morais]

Hi @OJ_Magellan 

 start with PAN, MnT and PSN, for more info:

Certificate Renewal on Cisco Identity Services Engine Configuration Guide

Cisco Identity Services Engine Administrator Guide

 Remember that:

"... If you install a server certificate on the ISE via a Certificate Signing Request (CSR) and change the certificate for the HTTPS or EAP protocol, the self-signed server certificate is still present but is no longer used.

Caution: For HTTPS protocol changes, a restart of the ISE services is required, which creates a few minutes of downtime. EAP protocol changes do not trigger a restart of the ISE services and do not cause downtime..."

Hope this helps !!!

[OJ_Magellan]

Hi Marcelo,

Thnaks for the reply, but wouldn't that cause the PAN to relaod and then lose connection to Mnt and PSN, since the PAN has a new Admin and EAP Cert? My idea was to bind first on the other nodes and lastly on the PAN (Primary) since they're all gonna reload.

I've read that document, they don't mention much about the Distributed deployment with an External CA.

Regards,

OJ

[thomas · Accepted solution]

You will be fine because the nodes can rely on the public CA or enterprise CA certificate chain to trust the new cert, whichever node you apply it to.

The other nodes (and endpoints) will trust the new cert(s)  because they can validate the signatures of (at least one of ) the signers which they trust.

Unless you are using self-signed certs then it will definitely break which is exactly why we say never to use self-signed certificates for a production deployment!