08-21-2023 09:03 AM
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
08-21-2023 11:32 AM
So you did a CSR already? Or imported a certificate (including private key)? And you are just trying to delete the self-signed certificate?
08-21-2023 03:15 PM
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.
08-21-2023 11:25 PM
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.
08-22-2023 12:14 AM
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.
08-23-2023 07:51 AM
I have the same issue, do you have any news?
08-23-2023 08:30 AM
08-24-2023 05:24 AM - edited 08-24-2023 05:30 AM
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
08-24-2023 10:24 AM - edited 08-24-2023 10:24 AM
08-25-2023 01:17 AM
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
08-25-2023 05:10 AM
Hi,
Next week I will open a TAC request for workaround:
https://bst.cisco.com/bugsearch/bug/CSCwh32290
08-31-2023 07:00 AM
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
09-21-2023 04:18 PM
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)
09-21-2023 04:37 PM
@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.
09-21-2023 04:44 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide