Smooth migration of ISE EAP certificate to new intermediate CA?

[MrNet]

Our intermediate CA is expiring in a year and we have created a new intermediate CA. Windows laptops have begun to receive user certificates based on the new intermediate CA. We use ISE-based EAP authentication for our wireless connections. Laptops with the new certificates are, as expected, failing authentication.

We can update the EAP certificate in ISE with one issued by the new intermediate CA, but won't this break all laptops with old certificates? We've consulted with TAC and we've been told you can't authenticate against two EAP certificates during a transition period (e.g. if one fails, authenticate against the other). Only one EAP certificate can be active. Nothing in the the cert renewal guide seems to address this scenario and while I've found a couple related threads in the forums, I'm still not sure how to proceed.

There is no way to push out new certificates to all laptops overnight, so it feels like whatever we do, we'll break wireless authentication for a large number of users without a simple way to resolve (because they can no longer authenticate). Replacing an intermediate CA isn't uncommon, so I feel like there's something obvious we're missing. Any help would be greatly appreciated!

[Arne Bier · Accepted solution]

Clients that have the new intermediate CA pushed to them via Group Policy should then also have their supplicant configured to trust ISE using the new intermediate CA. That is step 1. The client certs themselves can be re issued over time and there is no problem having intermediate ca 1 and intermediate ca 2 in ISE trusted cert store. That will allow ISE to trust both scenarios 

[thomas]

I cannot tell if the problem is with a supplicant configuration that is too restrictive (only trust this one single intermediate CA) or with the ISE Authorization Profile being too restrictive (only trust this one single intermediate CA). 

Since TAC says you cannot use two EAP certs (you cannot... ISE only allows you to use one for EAP authentications) then it sounds like the issue is the supplicant configuration.

For the supplicant, you have a lot of flexibility of trusting 1) any public CA or 2) only specific CAs or 3) specific CA(s) and specific servers:

Verify the Server's identity by validating the certificate

If you allow one or more public CAs, it doesn't matter which Intermediate you used - assuming they are both in the trusted list because the endpoint trusts the chain of certs signed by the public CA.

Unless you're not signing your intermediate(s) with a public CA. (!!!) Then that's your real problem creating more work for yourself because now you need to double the provisioning of your self-signed intermediate CAs to your endpoints. This is why public CAs exist.