Can PSNs in a deployment use different EAP Auth cert/CA chains?

[brdly]

We run a distributed ISE deployment with 2x PANs, 2x MNTs, and 6x PSNs (two spare). 

We want the two spare PSNs to terminate 802.1X/EAP with a legacy server cert/CA chain, while two other PSNs keep the modern cert/chain. NADs/WLANs will be scoped so clients never mix between PSN pairs. Is this supported, and what pitfalls should we watch for?

Reason

We are decommissioning an old pair of ISE nodes that handle AAA for a group of clients, for which we are unable to migrate over to our new SSL certificate at this point in time. We think this might be a solution. 

Details
Platform: Cisco ISE 3.2 (distributed deployment), six Policy Service Nodes (PSNs):

• 2 × Device Access (TACACS+)
• 2 × Session Access & Device Profiling — currently handle 802.1X/EAP for modern wired/wireless clients using our current server certificate + CA chain (“modern-PSNs”).
• 2 × spare — proposed to handle legacy 802.1X/EAP using a legacy server certificate + legacy intermediate/root CAs (“legacy-PSNs”).
• We do not use wildcard certificates.

Plan

• Bind the legacy EAP server certificate to the EAP Authentication role on the two legacy-PSNs.
• Keep the current EAP server certificate on the two modern-PSNs.
• Configure NADs/WLANs to point exclusively to the appropriate PSN pair (separate RADIUS server groups); no load-balancing or VIP mixing between legacy and modern PSNs.
• RADIUS accounting/CoA will also target the same PSN pair to maintain session stickiness.

EAP types in use

• Modern: PEAP-MSCHAPv2 and EAP-TLS.
• Legacy: primarily PEAP-MSCHAPv2 (some older supplicants).

The goal:

Keep modern clients on our modern PKI while allowing a clean path for legacy devices that still require the older CA chain — without any client seeing mixed identities during EAP.

Questions

1. Supportability: Is it fully supported in ISE 3.2 for different PSNs in the same deployment to present different EAP server certs/CA chains?
2. Supplicant trust/pinning: Any caveats with Windows (server name list), iOS/Android (EAP “domain”), or macOS when the EAP server CN/SAN and/or issuing CAs differ between PSN sets?
3. Session behaviour: Any issues with fast re-auth/session resumption or CoA if a client ever roams or reauths and hits the “other” PSN set (we intend to prevent this via NAD scoping)? I assume this will cause issues, but I just thought I would ask anyway.
4. Node groups/state: Any recommendation on node group membership or session state considerations when splitting PSNs by purpose like this?
5. Alternative approach: Should we instead split our spare PSNs from our cluster, and just set them up as a PAN/MNT/PSN pair to manage this instead?

[PSM · Accepted solution]

@brdly we were is same situation and we used exactly the same solution of having separate PSN for different NADs. As long you are aware of which NAD should use which PSN and configured properly there should not be any issue. Also COA should not be a point of concern since certificates are not used in COA action. Even if COA is initiated by other PSNs authentication from the NAD will go to the configured radius/PSN server only and not who initiate COA. We didn't face any issue while running this setup. 

[brdly]

Hey @PSM, just sanity checking - You had PSNs in the same "deployment" with different SSL certificates assigned to the EAP Auth role. And you just carefully pointed NADs at the right PSN with the correct SSL certificate to provide services as required? 

[PSM]

@brdly Yes, that's correct. Just to add more we might be going to that solution again when we start to implement dot1x on Cisco Access Points using certificate from Enterprise PKI.  On ISE PSNs we have public CA signed cert for EAP authentication. On Cisco APs certs will be installed by company CA. Cisco APs has this stupid limitation that they only trust AAA server certificate when it is signed by same CA (need to be company CA in our case). So either we use company CA on ISE PSN which creates problem with other endpoints or we get certificates on all 10K APs from same public CA and go bank corrupt. So we decided to spin additional PSN and save company hehe

[brdly · Accepted solution]

Hey, I raised a case with Cisco TAC regarding this question, and they got back to me with the following: 

ISE 3.2 fully supports having different EAP server certificates (and CA chains) on individual PSNs. You simply bind the desired cert to the EAP Authentication service on each PSN. Cisco’s recommendation is to use a single cert for simplicity, but a mult-cert deployment is supported. 

 Supplicant trust and name validation 

Windows: Ensure your RADIUS server group or SSID profile includes the exact SAN/CN that the legacy cert presents. If you’re using Windows Server Name Lists, add the legacy PSN SAN in your network policy. 

• iOS/Android: Populate the “EAP Domain Name” or “Trusted Server Certificate Name” in your WLAN or network profile to match the legacy cert’s CN/SAN. 
• macOS: Similar to iOS, include the legacy SAN in the trusted server names under the network profile. 

 Session behavior and CoA 

Session state is per-PSN. If by chance a client authenticates on a legacy PSN then later hits a modern PSN (or vice versa), the TLS tunnel resumption will fail, and you’ll force a full reauth. Since you’re scoping NADs and RADIUS server groups to prevent cross-hits, you shouldn’t see any session-resumption issues. 

 Node groups and PSN membership 

You don’t need special ISE node-group changes—just keep all PSNs in your usual “All_PSNS” and use separate RADIUS server groups in your NAD/WLAN configurations (e.g., legacyeap-group vs. moderneap-group). This cleanly isolate traffic without altering the ISE node-group topology. 

Next steps 

• Verify each PSN has the correct certificate and chain installed under Administration → System → Certificates. 
• Configure two RADIUS server groups in your NADs or WLAN controllers—one pointing at the legacy-PSNs, the other at the modern-PSNs.