cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7350
Views
10
Helpful
35
Replies

Apple clients & 802.1x / WPA2-Enterprise

Y C
Level 1
Level 1

Not sure if this is the right place to start on this. We have our WLC's integrated with ISE and AD. Our production ssid uses dot1x. We have roughly 15k windows domain devices and other various personal devices users bring in that seem to work fine. An issue started cropping up with Apple devices specifically. I want to say this started once IOS12 was released late last year but can't be 100% positive.

 

ISE passes the EAP cert through the controller to the client. Once you select the ssid and enter in the domain id and password the client prompts you to accept the certificate all as expected for the initial connection. 

 

Two issues -

 

1. The cert prompt shows it has expired. If you tap the details to view the cert you can clearly see that the current date is passed the "valid after" date and is years before the "expires on" date, so the cert should not be considered expired. Once you trust the cert you connect and pass traffic as normal. This behavior is repeatable and consistent - if you forget and re-connect to the network the same thing happens.

 

I found an old apple ipad running ios 9 and it does the same thing described in #1.  Android devices don't do this but they ignore the cert all together. Windows (both domain and non-domain) devices don't do this.

 

Once you trust the device and continue on, you will randomly get prompted to re-trust the cert. Sometimes it shows it's expired as described in #1, sometimes it doesn't... but you will eventually get prompted. It may be a day, or a week, but eventually the prompt to re-trust the previously trusted cert does come up.

 

I'm leaning towards it being an apple issue - it should never mark a valid cert expired and shouldn't prompt to re-trust something that already was. Just looking for any ideas or others experiences.

35 Replies 35

Yes, internal CA. One of our servers in the AD cluster acts as a CA for everything internally. I don't control that part of it, other coworkers do.

 

Problem with a new cert... this means I have to update all the policy nodes... which means it will affect our production domain clients. The last time we did this it became a big mess - the clients that are live and connected got the new cert pushed to them because they were already online. The clients that were disconnected and reconnected after the policy nodes were updated failed wifi auth because ise had the new cert and clients had the old (clients have a gpo on them that tells them to connect to this ssid using this cert). They all had to be wired, updated, then wifi would work.

I am talking about a lab test. Create a VM and restore the ISE production configuration but use a chained cert. I read the link that patoberli sent you but I tested on my side iOS 12 on iphone and the chained certificate I have on ISE PSN that used SHA-1 hash algorithm worked fine.

Can you test an "unchained" cert to see if it breaks?

 

Assuming I could get a new VM up and joined to the cluster (VM resources are running thin as it is) I'd have to create a separate SSID to point to that server so I can ensure I hit that one and not another from the cluster.

 

I guess it doesn't have to be joined to the cluster, I could just do one standalone node and enable admin/monitor/policy personas all at once.

 

You would hope that if part of the cert was missing the device would give you a more intelligent error then it's expired.

Y C
Level 1
Level 1

Just had a bit of an a-ha moment. Ran packet capture on one of our policy nodes and watched the cert exchange.

 

It's sending the new eap cert, but the old root cert even though it's been deleted through the gui interface. Apparently to get the new eap cert "bound" to the new root cert one must re-issue the self signed certs as well.

After another TAC session it was suggested that the self signed certs aren't tied to this. Apparently ISE is supposed to prompt you to restart the application (or entire VM?) when certs are changed and this didn't happen months back when we updated the certs. After manually doing an "application stop ise" and "application start ise" on each policy node this seems to have taken care of issue #1, where the initial prompt to trust shows it's expired. It will be a "wait and see" to find out if the random prompts to re-trust come back or not.

You haven't installed security updates in months?!?
Check all the known issues here and I suggest you immediately upgrade (and thus reboot the ISE):
https://tools.cisco.com/security/center/publicationListing.x?resourceIDs=111903&apply=1,0&totalbox=2&pt0=Cisco&cp0=111903#~FilterByProduct
Review Cisco Networking for a $25 gift card