iOS wireless Certificate expiration

Hi Chris,

Are you deploying the original Wi-Fi connection using a profile? That would normally have the certificate associated with it for its trust settings so would need to be updated with the new cert.

Hi David,
Our users connect themselves to the wifi, using their own credentials so we are not connecting them using a profile. However, once they are connected and enrolled in Casper, we deploy a Wifi configuration profile for that same SSID, which sets own proxy wpad configuration. This was the only way I could think to allow them to connect their iOS device to the wifi, but to allow us to slip our wpad config into it.

I replicated this scenario in a test config profile, then adding the new certificates into the configuration profile, and scoping a device to this new profile. The profile pushes out with the certs, but it just sits there trying to connect to the SSID, and then times out.

Normally, when users connect to the SSID for the first time, they are prompted to accept the wireless certificate, which is okay, but it seems that iOS doesnt like it when that certificate changes. It doesnt even give you the option to accept a new certificate.

Cheers

Ah ok. I haven't tried it that way, I'm normally using a guest wifi of some sort for the enrollment which switches them onto the proper network.

In the wifi profile, are you selecting the certificate in the wireless trust settings? And are you using PEAP? Are you filling in any credentials in the profile or using directory authentication? (just thinking through the process out loud really :)

We used to have an open SSID which users could use to enrol their device which directed them to the JSS enrolment page, however with iOS we didnt have a way of getting rid of that SSID from their iPad/iPhone so they kept connecting to it and it caused us grief. On OSX, we just ran an script to remove that SSID on any enrolled machine.

On the wifi profile, we are using PEAP, but we are not filling in any of the user credentials as the user has already done this by this stage when they connect themselves to the wifi, therefore the only thing we are applying using the profile, is the proxy config. I am just going to try putting the trusted certs into my test profile and see if i can force it using those certificates.

I have found that even when not using a wifi configuration profile, if the wifi certificate changes, it still doesnt give you the opportunity to accept a new one. You have to remove the wifi and re-connect it. Unfortunately because we have applied a profile, we cant remove it, you basically have to unenrol.

Ill let you know what I find from doing this

Chris

I've tried what you are doing, Chris, but the profile seems to error. An option I have tried is to connect the device to the open wifi portal to start as you have said, then send the WiFi configuration profile but here is my trick:

Populate the username field in the profile with $USERNAME and leave the password blank (since it's unknown) Put a checkmark beside AUTO-JOIN network
Next, hit the + in the top/right to add a second, lower priority wi-fi payload and populate it with the open portal you used to connect. make sure that AUTO-JOIN is NOT enabled on this one.

For me, this has forced the priority after configuration load to default always to the PEAP authenticated network and will ONLY connect to the open portal if the authenticated is down for some reason.

Rod