Stale certs in 3.2, unusable? They work perfectly in 2.7

[Gioacchino]

My question is similar to

https://community.cisco.com/t5/network-access-control/ise-certificate-stale-status/td-p/4653889

I have read the link mentioned by @ahollifield 

https://www.cisco.com/c/en/us/td/docs/security/ise/3-1/admin_guide/b_ise_admin_3_1/b_ISE_admin_31_basic_setup.html#concept_a1f_v2t_msb

Indeed our certs are marked as stale. I guess that a stale certs cannot used for anything, right? (***)

```A bit of background: I upgraded a node to 3.2 and fully restored config and ops backups.
When it came to uploading certs and assigning to groups tag, there were no portal group tags (just the default one). I then imported the cert by creating a new portal group tag.

(some questions aside)
1) Is it normal that I didn't see any portal group tags after restoring the backups
2) By creating new portal group tags (with the exact names), will ISE use them correctly? (I guess this piece of information is used internal but I wonder if the connection is indeed the name)```

Now, back to the main topic: such certificate, marked as stale in 3.2, work perfectly in 2.7.

I wonder why I cannot use them in 3.2. The portal web page works, but (***) presents the self-signed cert of the new mode.c

What's the way to fix this issue?

One might think to change the hostname to reflect one of the names in either the CN or the SANs, but this might have even much worse side effects than benefits.

Otherwise, is the only laternate solution to buy new certificates?

Thx, Gio

[Arne Bier]

Hello @Gioacchino 

I have to admit that it's only since ISE 3.2 that I noticed this "Stale" (blue icon) cert status as well. And I built a fresh ISE 3.2 patch 4 Guest Deployment, with brand new DigiCert certs for the Guest Portal. ISE displays them as Stale. Don't ask me why. I patched to patch 5 recently and it's still the same.

The good news is that the Guest Portal works and the correct certificate is used. And when you tick the certificate and click on View, ISE tells me "Certificate status is good".  The valid from and to dates are all good.

Therefore I have not pursued the issue. But it's still a bit puzzling. My personal theory is that ISE is confused. Because the FQDN of the guest portal (e.g. guest.mycomany.com) is not the same as the ISE node's FQDN (e.g. ise01.network.local) - but this is usually the case with any ISE node that is presenting a public DNS domain name in its portal. But since ISE 3.2, ISE seems confused. I don't know how else to explain it.

The Sponsor Portal does not have this issue because I am using the Admin cert for the Sponsor Portal (where the SAN contains the additional DNS entry for the sponsor FQDN).

If you have any further insights into this, or have a TAC case, I would like to know what they say.

[Gioacchino]

Indeed in terms of FQDN, visitors may see the portal in a different way than ISE itself.
I opened a TAC case to clarify the situation.
What really puzzles me is the fact that in the ISE 3.2 I didn't find any portal group tag, therefore when I created a new one I wondered, again, if I created a totally new object completely detached from the internal data structure or the name I gave it could make a link with a non displayed object.

Since after its definition, the portal still continues to show the from-the-node-itself-self-signed certificate, I guess I created a new object completely detached.

Now TAC asked to reimage again (!) the node because they fear the import of the backup didn't go well.

I'll keep you posted. However it's good news that even though certs are marked as stale they can be used, though here Cisco completely misses the goal of marking certs that might be removed because non-relevant, some they are!

Thanks, Gio

[Arne Bier]

Good luck with the re-image. I can tell you for a fact that I built a clean 3.2p4 system and the problem was there from the start - no backup restore done. And I have built quite a few ISE nodes in my lifetime - never seen this before.

[Gioacchino]

---

What really puzzles me is the fact that in the ISE 3.2 I didn't find any portal group tag, therefore when I created a new one I wondered, again, if I created a totally new object completely detached from the internal data structure or the name I gave it could make a link with a non displayed object.

---

With this regard, I managed to understand a bit more on how things are supposed to work.

It seems certificates are not included at all in the backups, the newly re-imaged node create a chain 4 level-deep

I managed to import the public certificates, associate them to portal group tags whose names I could decide on the spot, then I could associate those portal group tags to each portal (sponsor or captive).

By directing the browser to each of sockets configured, I got confirmation that ISE used the imported certificates indeed the way I configured, it didn't seem the same before.

Now, a comment/question on the Internal CA exporting/importing.
I misunderstood the meaning of Internal CA: that's the internally-signed-by-the-node cert chain and not the internal-to-the-company PKI. Not being familiar with ISE, it was my mistake. I see it's used for "ISE messaging" and possibly for pxGrid.

I wonder, though, why would you make a copy of it. I think, the only use case is when you want to build again from scratch a node that behaves weirdly, not in case of full upgrade of a cluster. Therefore, since the other nodes got certificates from that CA, in order to avoid they distrust the new ones and start from scratch the whole certificate-related system, it's better the new node uses the old CA infrastructure.

Am I correct?

TIA, Gio

[Arne Bier]

yes @Gioacchino - the original/old internal CA can be re-imported into a newly built node (which always builds its own internal CA during install) so that your BYOD stuff (if you use ISE BYOD) works like before. 

[Gioacchino]

Why, @Arne Bier , specifically to BYOD?

[adamscottmaster2013]

I am also seeing "stale" certificate on my ISE 3.2 patch 5.  This certificate is an entrust certificate and it is working.  In version 3.0 patch-7, it was a green check status.  I am able to confirm this on multiple ISE 3.2 patch-5 systems.

[Arne Bier]

If your ISE is used to onboard/provision BYOD devices with certificates, then the internal CA is (or primarily used) to create those client certificates. You will see the "Issued certificates" in the ISE GUI. The Root/Node/Endpoint Sub CA structure is what most folks use. You can also make ISE an intermediate CA etc. 

But the internal CA is also used for creating pxGrid certs, and for the Messaging Services etc. In my experience, I don't care about those because I can regenerate the internal CA if the Messaging Service has issues (e.g. Queue Link Alarms) and if I have DNAC integrated via pxGrid, and my ISE CA has issues, then I just re-integrate ISE with DNAC and that fixes it.

But with BYOD you have to pay close attention to ensure that the existing BYOD clients can still be trusted by ISE, if that ISE has had its internal CA regenerated (or is a rebuilt ISE node). This is when importing the previous CA structure is helpful.

[Gioacchino]

As far as I can see for registering own devices through a portal, it's required a license. That we don't have, hence BYOD concern is gone.

Thanks, Gio