Re: ISE Admin certificate is not updated

asdf6 · ‎08-21-2023

Hello community,

I'm currently building a new ISE-deployment and the Admin-Portal certificates are giving me headaches. Hopefully someone also had this issue and was able to resolve it.

The new setup is based on 3.2 Patch3. Somehow I'm not able to set any other certificate then the self-signed one which is generated right after first-time setup of the server. Tried deleting the cert, creating a new self-signed, rebooting the server, start/stop of the application, import of a new one from an external CA. No matter what, the self-signed one is still there.

Any ideas? or logfile locations where to maybe find a clue?

Best regards
Stefan

ahollifield · ‎08-21-2023

So you did a CSR already? Or imported a certificate (including private key)? And you are just trying to delete the self-signed certificate?

Arne Bier · ‎08-21-2023

You can have a bunch of certs lying around in ISE - the crucial part is whether or not a cert is assigned to a task/role - e.g. you must assign a cert to Admin role. After creating a CSR and binding it, you must select to which role you want to bind it. And likewise with importing a cert+key - you can either just import it, but then it's not automatically bound to a role, unless you tell ISE which role you want it to be. System Certs can be left lying around in ISE and if they don't have a role assigned to them the cert will be marked as "Not in use". You can choose to delete those certs if you know you'll never use them again.

The best way to assign a cert to the Admin role is to create a CSR in ISE, because then the private key never leaves ISE. Get the CSR signed by your PKI, and then bind the cert back to the CSR in ISE. And at that point tick the "Admin" role. Remember that ISE will restart its processes when the Admin cert is changed.

asdf6 · ‎08-21-2023

Sorry, I didn't mention this. I've created a CSR, which was signed and imported with "Admin" role. A message appears which states that the application server will be restarted, but I believe it does not restart on it's own. On my old/productive environment I've never had this kind of issue.

Arne Bier · ‎08-22-2023

Well the restarting of the services should be monitored on the CLI. If you installed an Admin cert for a node that is NOT the Primary Admin Node (e.g. a PSN) then you must go onto the CLI to check the services. Or have a look in Deployment screen - the icon will eventually go from green to red.

If services are not restarting due to a change in Admin cert, then you have a genuine issue. TAC case.

bergonzoni · ‎08-23-2023

I have the same issue, do you have any news?

asdf6 · ‎08-23-2023

Hi, not yet…. I’ll update as soon as there is something helpful

asdf6 · ‎08-24-2023

Update: I've taken apart the deployment, seems that neighter ISE3.2.0 (no Patch), Patch2 or Patch3 is able to exchange the Admin-certificate?? .... Realy looking forward to this TAC case.
ISE is running on SNS-3755-K9

thomas · ‎08-24-2023

https://cs.co/ise-guides#PKI

How To Implement Digital Certificates in ISE - includes wildcard certificates
Configuration Guide to Certificate Renewal on ISE

asdf6 · ‎08-25-2023

ISE3.2.0 (no Patch), Patch2 and Patch3 does not update the certificate in role "Admin"
ISE3.3 does not have this issue. Most likely I'll be going with 3.3 then

bergonzoni · ‎08-25-2023

Hi,

Next week I will open a TAC request for workaround:

https://bst.cisco.com/bugsearch/bug/CSCwh32290

sbookmeyer · ‎08-31-2023

We are having the same issue which is reported in CSCwh32290 in 3.2p3. Importing admin cert will result in message that the server is staring, but it is not.

One workaround for us is to de-register the node from deployment, then the admin cert is working. Then we will register the node again. We know this is not the funnierst workaround...

We might found the root cause, because if we have configured bound0, we are running into this issue. If we remove bound0, we are not hitting this bug.

Cheers,

Sven

Capn_Awesome · ‎09-21-2023

I have had a TAC case open since May on this issue and we finally figured it out. The issue, for me at least, is a single line of config I habitually apply in the CLI when I first build any physical node to designate gi1 as the backup interface for gi0: backup interface GigabitEthernet 1

Apparently that single line of config breaks certificate management at the OS layer. I have tested removing the line on 3595 and 3795 boxes and my new nodes now work as expected. TAC have assured me that this will be resolved in patch 4 due mid-October.

Defect for this issue: CSCwh46669 : Bug Search Tool (cisco.com)

Arne Bier · ‎09-21-2023

@Capn_Awesome - just to confirm, was your intention to use interface bonding or not? Because I have customers with SNS servers and I mostly always get them to agree to using two interfaces (Gig0 and Gig1) to form a Bond0. Hopefully by the time they are ready for ISE 3.2, patch 4 will be out and we have dodged another bullet.

Thanks for sharing your experience.

Capn_Awesome · ‎09-21-2023

That is correct - 2 interfaces per SNS to provide redundancy.
I will not be taking 3.2 into production until this is resolved in p4, but at least now I can proceed with the build and begin testing the thousands of other things I need to test before we upgrade. Hope this helps you!