cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

2441
Views
5
Helpful
3
Replies
Chemist2k
Beginner

Client devices lose connectivity after changing EAP certificate on ISE

We're planning to implement BYOD in our wireless network but have several issues during pilot testing. Specifically we were testing client device behaviour, which already had successfully issued user's certificate, after changing EAP certificate (in this case we're emulating eap certificate's expiration). During our tests the client device wouldn't be able to connect to the same wireless network after EAP cert renewal on cisco ISE. Once we switch to the old EAP certificate, client would connect to wireless network without any problems. So the question, is that an expecting behaviour of ISE, or there is a way to make it work?

In a nut shell:

1. Clients can issue a certificate and work in wireless network with no issues;

2. Changing EAP certificate on ISE;

3. Old clients lose connectivity, new clients can successfully issue a new cert on ISE and work in wireless network.

 

Suppose it's a normal behaviour of ISE, but how do people usually deal with that?

1 ACCEPTED SOLUTION

Accepted Solutions
Arne Bier
VIP Advisor

Hello @Chemist2k 

 

How does the old ISE EAP server certificate differ from the new one? Were they issued by the same CA? I suspect that the client WLAN profile is configured by ISE BYOD onboarding to trust a RADIUS server using a Root CA cert of the RADIUS server - if the new ISE EAP server cert is issued by a different CA chain, then it all falls apart. That's just how it's meant to work, because the client is enforcing server checking - this is good security. If people relax the rules and ignore the server cert (baaaaaaad!) then things just seem "to work" like magic. But it's not good security because you could be talking to a hacker's RADIUS server.

 

Sadly ISE only supports a single certificate for the entire EAP service. Other RADIUS servers like Aruba Clearpass support multiple certificates for EAP, which can be very handy to handle devices that expect to see a different EAP certificate in some circumstances (e.g. company mergers).

 

View solution in original post

3 REPLIES 3
Arne Bier
VIP Advisor

Hello @Chemist2k 

 

How does the old ISE EAP server certificate differ from the new one? Were they issued by the same CA? I suspect that the client WLAN profile is configured by ISE BYOD onboarding to trust a RADIUS server using a Root CA cert of the RADIUS server - if the new ISE EAP server cert is issued by a different CA chain, then it all falls apart. That's just how it's meant to work, because the client is enforcing server checking - this is good security. If people relax the rules and ignore the server cert (baaaaaaad!) then things just seem "to work" like magic. But it's not good security because you could be talking to a hacker's RADIUS server.

 

Sadly ISE only supports a single certificate for the entire EAP service. Other RADIUS servers like Aruba Clearpass support multiple certificates for EAP, which can be very handy to handle devices that expect to see a different EAP certificate in some circumstances (e.g. company mergers).

 

View solution in original post

You're right as long as the new EAP cert issued by the same subCA and Root CA we have no issues, but at some point in the future those certs are gonna be reissued too (subCA and Root CA), thats where we begin to have a problem: ISE doesn't allow to have two certificates with the same common name in Trusted certificates list. So we have to change it right? Delete the old one and install the new one.

@Chemist2k - sorry for delay - festive season break ... if the CA hierarchy changes (e.g. Root CA expiration) then everything below that certificate hierarchy will be invalidated - and will need to be re-issued. I have seen that CA providers will create a new Subject that includes a numeric in the name to distinguish from previous names - e.g. Digicert Root CA 1, etc. - you probably won't have a situation where the new Root structure has the same Subject Common Name as the expiring certificate.

Content for Community-Ad