New ISE node not trusted

[millhouse64]

I have stood up a new ISE node (3.1 p9) at a backup site.  While testing wired radius (eap-tls)  it looks like the client is not trusting that node. The same client works with the current nodes at the main site. 

The new node does have a system certificate signed by a different root and intermediary CA, but both of those are in the devices trusted certificate stores.

I'm going to test unchecking "Verify the server’s identity by validating the certificate" to see if it will successfully authenticate like that, but I'm not permitted to have the clients set up like that.

Has anyone run into this issue and has a solution or can point me in a direction to look into?

[Arne Bier]

Every ISE node has its own, independent EAP Server certificate.  The new ISE node that you have stood up must have an EAP System Certificate that is generated by the CA chain that your clients trust.  The new ISE node is probably still running off the default self-signed cert, or it was not generated correctly.

[millhouse64]

I know I'm not using the delf signed certificate--It's possible it wasn't generated correctly since I have to send the CSR to a different office to be signed 

[Aref Alsouqi]

Probably the issue is caused by the supplicant profiles configuration on the clients that do not have the new issuer CA certificate selected.

[millhouse64]

I have been leaning towards this being a supplicant issue.  The certificates path is in the trusted stores of the client.  Is that different from what you are saying about selecting the new issuer?  

[Aref Alsouqi]

If you have the root CA and/or intermediate CA certificates available in the clients trusted store it doesn't necessarily mean that the client will use them during the dot1x authentication because if the supplicant dot1x profile is not configured with the trusted certificates required the client won't use them. So I would recommend reviewing the supplicant configuration and ensure that you have all the trusted certificates selected from the trusted certificates list.

[ahollifield]

Curious why you are still deploying 3.1?  Why is a different CA being used for this node?

[millhouse64]

I am looking into going to 3.2 since I've heard that's less 'buggy' just have had too many projects going on to put any real time into that. 

I have to go through a different office to get the certificates signed.  I did ask if they were able to choose what root signs the cert and they said no.   I have been thinking I'll get another cert signed for all the nodes from the new CA, but I'm a bit reluctant since it isn't working on with the new node

[ahollifield]

From who?  3.3 and 3.4 contain very large performance optimizations as compared to 3.2 and before.

[millhouse64]

One of our vendors I was working on a project with.  Like I said I haven't put much time into looking at an upgrade yet;  I'm also government so I'll have to see what's approved before upgrading (and we tend to be horrible about staying 'current' with tech)

[ahollifield]

If it takes you a while to keep/stay updated then I would not deploy on 3.2 then.  3.4 will give you the longest life-time until the next major upgrade is needed.  It also contains the most performance improvements with related to service start time.