cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1114
Views
6
Helpful
12
Replies

ciaco ISE 2.7 to 3.1 but it's using internal CA for authentication

vivarock12
Level 1
Level 1

hello people I have a Cisco ISE 2.7 and want to upgraded to 3.1 and then to the recommended release, but the thing is it's using its own CA for the authentication so doy you have any recommendations for this procedure?

I wanted to do a full upgrade, just like that from 2.7 to 3.1 but I'm concerned of any problem with the CA.

How can I backup al the CA part and all the generated certs from the ISE and regenerate then in case that is necessary.

2 Accepted Solutions

Accepted Solutions

Your procedure would emulate the upgrade procedure in the lab - step 1 is useful because it includes the internal CA certs.

After your upgrade, if you have any Queue Link Errors (wait some time ...) then you will have to resolve those. Either by regenerating the Messaging CA, or worst case, regenerating the Internal CA. If you have to regen the Internal CA, then your endpoints that relied on this CA hierarchy might fail. I say "might" because the CA certs are still there in ISE but are no longer used. If endpoints are failing I would try to import those old ISE Internal CA certs into the ISE Trusted Certs page and tick the first two boxes. 

View solution in original post

vivarock12
Level 1
Level 1

@ahollifield @Arne Bier just to give you guy a head up and an update on the matter, if you want to upgrade without lossing you internal CA, there are to way.

method 1

Getting a Backup from the internal CA (@Arne Bier like you told me with the application configure ISE).

then do the upgrade split method and after it ends import the CA certs an the CA cert Authority cert to the ise deployment to let everything as it was before:

vivarock12_0-1761600683427.png

Method 2

do a Full upgrade process, if you do the full upgrade process, theres no need to do the CA Cert Regeneration.

vivarock12_1-1761600764504.png

https://www.cisco.com/c/en/us/td/docs/security/ise/3-2/upgrade_guide/Upgrade_Journey/Cisco_ISE_3-2_Upgrade_Journey.html#id_125864

So thats the easier way to do it any case, but there are some considerations with the VM time and downtime.

!
!

THE LAB
so for the lab i got an erro when i had the version 2.7 patch 5, y had to pacth that to the last one patch 10, to be able to do the full upgrade as expected and i dindt get any trouble. for the upgrade the only thing as you guys know the timing and the down time of this method migth not be the best option for some cases. 

screenshot of the lab after the upgrade to 3.2 and patch 7:

vivarock12_3-1761601006472.png

!
!

NOW lets upgrade to version 3.4 Patch 4

So now to upgrade to the 3.4 patch 4 im getting this trouble:

vivarock12_4-1761601141549.png

If im not wrong this is a bug with the code: CSCwh08387

have you guys ever had this trouble before?

https://quickview.cloudapps.cisco.com/quickview/bug/CSCwh08387

 

thanks fot the help to the both of you guy.
@ahollifield @Arne Bier 

 

 

View solution in original post

12 Replies 12

Arne Bier
VIP
VIP

I am keen to see what other have to say on this question - I have not been in the situation where I needed to maintain internal CA generated certs.

The Internal CA certs are backed and/or restored up via the PAN CLI

ArneBier_0-1760906117885.png

You export them to an ISE repository. I don't know what format this file is in - it appears however that it contains all the internal CA certs - but it does not include the issued certs. You don't need to backup the issued certs, because those will live on end devices.

The following 5 CA key pairs were exported to repository 'FTP' at 'ise_ca_key_pairs_of_labise01':
        Subject:CN=Certificate Services Root CA - labise01
        Issuer:CN=Certificate Services Root CA - labise01
        Serial#:0x575d9256-28aa4e6e-8c3ea840-b1034219

        Subject:CN=Certificate Services Node CA - labise01
        Issuer:CN=Certificate Services Root CA - labise01
        Serial#:0x196a6b9a-0db3461b-a453685a-899e0fb9

        Subject:CN=Certificate Services Endpoint Sub CA - labise01
        Issuer:CN=Certificate Services Node CA - labise01
        Serial#:0x00fc7c80-599e4362-ad1a2fe2-592a73f7

        Subject:CN=Certificate Services Endpoint RA - labise01
        Issuer:CN=Certificate Services Endpoint Sub CA - labise01
        Serial#:0x1310c9a7-cc8c4f1c-b268babb-7f5ae2a7

        Subject:CN=Certificate Services OCSP Responder - labise01
        Issuer:CN=Certificate Services Endpoint Sub CA - labise01
        Serial#:0x513f9203-4f20425a-863460db-f0dacc39

ISE CA keys export completed successfully 

So far so good. 

The problem I always face after an upgrade is that ISE will complain about Queue Link Errors. Every time I try to fix that by Regenerating the ISE Messaging CA, it doesn't resolve the issue. Perhaps I have been too impatient. But that in theory should fix it.

I tend to regenerate the internal CA which 100% fixes the issue. In your case however, that will destroy your internal CA.

I would therefore NOT regenerate the internal CA. Try the ISE Messaging CA renew first. And if Queue Link Errors still persist, then contact TAC, or disable ISE Messaging Service.

ArneBier_1-1760907071610.png

 

 

 

thanks for the help ill keep this in mind for the procedure but ill have a TAC Person during the upgrade.

one question @Arne Bier in just created a lab with the same idea pan,san and 2 psn i have the backups for the config, operational and the internal CA cert.

 

so to emulated the upgrade should i:

1 - Import the CA internal certs

2 - Then upload the backup of the config (i dont care about the operational, at least for the lab).

3 - Test the upgrade to the new version using full upgrade method.

What do you think about the plan does it make any sense? just want to have your opinion.

Your procedure would emulate the upgrade procedure in the lab - step 1 is useful because it includes the internal CA certs.

After your upgrade, if you have any Queue Link Errors (wait some time ...) then you will have to resolve those. Either by regenerating the Messaging CA, or worst case, regenerating the Internal CA. If you have to regen the Internal CA, then your endpoints that relied on this CA hierarchy might fail. I say "might" because the CA certs are still there in ISE but are no longer used. If endpoints are failing I would try to import those old ISE Internal CA certs into the ISE Trusted Certs page and tick the first two boxes. 

ok so i just restore the config and the CA internal cert, but only the PAN certs are getting on the CA certs:

vivarock12_1-1761254649916.png

so now i have a client Cert and added on a windows sandsbox just to double check the cert

vivarock12_2-1761254708772.png

the cert that i see on the root Trusted Certs is one of the certs restored to the ISE Deployment but on the Client cert:

vivarock12_4-1761254956418.png- The root seems fine (one of the restored ones)

vivarock12_5-1761255044846.png - the node CA seems fine (one of the restored ones)

vivarock12_7-1761255183071.png - the endpoint one is refering to the 3 ise (psn node) so migth that be a trouble? or should i just export the cert from al the ISE nodes and import to the lab nodes? and idea on that?

!

after that ill test a conection and then proceed with the upgrade from 2.7 patch 5 to 3.2 a 3 node full upgrade, and then discard the problems with the ISE Messaging Cert.

 

 

 

 

 

The endpoint certs are always issued by the Endpoint Sub CA - and each PSN will be its own Sub CA, which is tied to the Services Node CA - for a nice diagram, check out this Cisco link. - the boxes I highlighted in yellow are the PSNs.

 

ArneBier_1-1761270581767.png

 

It was a Cisco Services implementation that why its like that basicacly. 

Wow, I’m shocked. Do you not have an internal PKI/CA? You should 100% move off of the ISE PKI. Are you using BYOD in 2025?

sorry for the late reply no only VPN cert authentication. at the moment i dont have any choise but ill told them to change de ROOT CA, with a Linux and start the migration for all the users cert in this case, but that will take time so it will have to be done after the upgrade, because of the amount of users to deploy de cert(users and CA).

vivarock12
Level 1
Level 1

@ahollifield @Arne Bier just to give you guy a head up and an update on the matter, if you want to upgrade without lossing you internal CA, there are to way.

method 1

Getting a Backup from the internal CA (@Arne Bier like you told me with the application configure ISE).

then do the upgrade split method and after it ends import the CA certs an the CA cert Authority cert to the ise deployment to let everything as it was before:

vivarock12_0-1761600683427.png

Method 2

do a Full upgrade process, if you do the full upgrade process, theres no need to do the CA Cert Regeneration.

vivarock12_1-1761600764504.png

https://www.cisco.com/c/en/us/td/docs/security/ise/3-2/upgrade_guide/Upgrade_Journey/Cisco_ISE_3-2_Upgrade_Journey.html#id_125864

So thats the easier way to do it any case, but there are some considerations with the VM time and downtime.

!
!

THE LAB
so for the lab i got an erro when i had the version 2.7 patch 5, y had to pacth that to the last one patch 10, to be able to do the full upgrade as expected and i dindt get any trouble. for the upgrade the only thing as you guys know the timing and the down time of this method migth not be the best option for some cases. 

screenshot of the lab after the upgrade to 3.2 and patch 7:

vivarock12_3-1761601006472.png

!
!

NOW lets upgrade to version 3.4 Patch 4

So now to upgrade to the 3.4 patch 4 im getting this trouble:

vivarock12_4-1761601141549.png

If im not wrong this is a bug with the code: CSCwh08387

have you guys ever had this trouble before?

https://quickview.cloudapps.cisco.com/quickview/bug/CSCwh08387

 

thanks fot the help to the both of you guy.
@ahollifield @Arne Bier 

 

 

thanks for the update on your upgrade story. I have not run into that specific bug - I hope you could work around it.