Sierra 10.12.5 Upgrade breaking Corp Wifi

nwiseman
Contributor

With the release of 10.12.5 today, I immediately upgraded one of my test systems. Everything was working fine on said system before the upgrade. After the upgrade Wifi fails to connect. Have attempted to re-configure wifi in order to see if it just corrupted, but no dice.

I've opened a support ticket with Apple, but I'm curious if anyone else is seeing something similar.

87 REPLIES 87

chisox1
New Contributor

I have had the same issue..

isradame
Contributor

Having the same issue on some of my test Macs.

chisox1
New Contributor

Let us know what Apple responds... debating on opening a ticket myself

Sdwick
New Contributor II

Same issues here... You guys using WPA2 enterprise I am guessing?

kquan
Contributor

What model computers are you guys trying on?

So far I've tried a 15" late 2013, 13" late 16 non touchbar, and a 13" late 16 touchbar all updated to 10.12.5 and was able to sucessfully connect

https://support.apple.com/en-us/HT207797

802.1X Available for: macOS Sierra 10.12.4 Impact: A malicious network with 802.1X authentication may be able to capture user network credentials Description: A certificate validation issue existed in EAP-TLS when a certificate changed. This issue was addressed through improved certificate validation. CVE-2017-6988: Tim Cappalli of Aruba, a Hewlett Packard Enterprise company

I did get a "Verify Certificate" before continuing to connect to my internal network here. Once I confirmed, I was on our internal network without any issues

nwiseman
Contributor

Well...that makes me both happy I'm not the only one and extremely sad that it seem's like a bigger problem.

So far Apple has asked me to send it Wifi logs and SysDiagnostics. While they're looking at them, i've been doing some looking at logs as well. What I've found is that when it attempts to do a matchAndJoinSSID: it says it's "temporarily disabled, next"

Will report back anything I hear from Apple.

nwiseman
Contributor

So...I found our issue before Apple did. Maybe it will be the same for all of you.

Our root and chain certs were not be accepted even though they showed up as validated. I had to go in and set the EAP Trust setting to "Always Trust". Once I did that and restarted wifi everything kicked in immediately.

Now to go back and figure out configuring that trust setting.

bbot
Contributor

How is your wifi authentication configured? Ours requires a root + intermediate cert to request a machine cert, then uses the machine cert to authenticate to wifi.

We deploy root + intermediate certs, AD cert request, and wifi config all through a configuration profile. On one machine, I was prompted for my login password to allow a change to the keychain.
On another test machine, my machine was kicked off the wifi. In the keychain, I found the com.apple.network.eap.user.identity.wlan.ssid.WIFINAMEHERE had a red X and that the preferred certificate was set to None.

apizz
Valued Contributor

No issues here. We have profile-based Wifi logon to accomplish a machine-auth type deal on our Macs, so nothing with certs (we're an AD shop).

Upgraded from 10.12.4 to 10.12.5 on test machine

alexjdale
Valued Contributor III

I was working with nwiseman on this and to clarify, it appeared to only be an issue when the root/chain certs were imported using a configuration profile. At my company we import them directly to the keychain using the security command with appropriate trust options. Other than that our environments were the same, but his wasn't working and mine was.

AVmcclint
Honored Contributor

It has broken both our 802.1x Wifi and Ethernet connections. This is really really really bad. I EVENTUALLY got a prompt to validate a cert, but it requires Admin credentials to do so. There is absolutely no way this is going to work.

Retrac
Contributor

Same for me. Updated to 10.12.5 from 10.12.4 or built from scratch with an AutoDMG restore and Our 802.1X Wifi now does't connect.

dprakash
New Contributor III

802.1x Machine based Wifi here and working fine on 10.12.5

CasperSally
Valued Contributor II
Notes or Updates Since Initial Image Was Released

We're good here, too.

AVmcclint
Honored Contributor

After I got back on the network, I restarted the computer and found that reconnecting to the network is all wonky now. WiFi won't even try to connect until after completely logged in and at the desktop (which means any Login triggers won't happen), Ethernet gets stuck in an infinite loop and never connects on its own. It gets a self assigned IP for a few seconds then falls back to "not connected" and then gets a self assigned IP... wash, rinse, repeat. The only way I can connect via Ethernet now is to click on Disconnect, wait a few seconds then click Connect. Then I get a valid IP.

NowAllTheTime
Contributor III

Same problem for us. Just submitted an enterprise case (100194327871). Only workaround that works for us is to manually go into the system keychain and set issuing and wireless certs to "always trust" (the root is already set to always trust). Doesn't seem to be a good way to script this since the certs are deployed via config profile and already in the system keychain (so we can't really leverage a security add-trusted-cert command)

Anyone having any luck setting the update to be ignored? I can't get sudo softwareupdate --ignore "macOS Sierra Update-10.12.5" to actually ignore the update. I've also tried "macOSSierraUpdate-10.12.5" "Mac OS Sierra Update (10.12.5)" "10.12.5" and "macOS Sierra Update" to no avail.

We have update scheduled to push to clients this weekend but looks like I'm going to have to reschedule until this is fixed cause this is BAD.

seann
Contributor

@jasonaswell Not an immediate solution, but I'd suggest setting up reposado or another SUS so that you can control distribution

NowAllTheTime
Contributor III

We recently moved away from using a SUS to instead lean on caching server since Apple is sunsetting their SUS - this also makes it easier for users not on site to keep up to date. We've got a blacklist script that we run to ignore problematic updates, but unfortunately I can't find a phrasing for this update to successfully ignore it. This is the direction Apple has been moving in, so we were trying to skate to where the puck was heading, but unfortunately between the directory auth lockout issue in 10.12.2 and earlier, and now this - it's clear that we need to rethink that since Apple is failing to consistently test critical enterprise level functionality.

StoneMagnet
Contributor III

FYI, my test machines running El Capitan 10.11.6 experience the same issue after installing Security Update 2017-002 Ignore that comment. Further investigation revealed AD binding issues with test machines were the actual problem, and Security Update 2017-002 has not impeded the ability of our 10.11.6 systems to authenticate via 802.1x for WiFi.

NowAllTheTime
Contributor III

FYI, ignoring "macOS Sierra Update" does actually work for anyone who is managing updates via the software update command.

kendalljjohnson
Contributor II

To second @jasonaswell, I had to sudo the ignore command to get the update to be ignored (wouldn't need to do so from a JAMF script).

Here's my output from terminal in testing to see how it can be done:

bash-3.2$ softwareupdate -l Software Update Tool Finding available software Software Update found the following new or updated software: macOS Sierra Update-10.12.5 macOS Sierra Update (10.12.5), 873261K [recommended] [restart] iTunesXPatch-12.6.1 iTunes (12.6.1), 191180K [recommended] bash-3.2$ sudo softwareupdate --ignore "macOS Sierra Update" Ignored updates: ( "macOS Sierra Update" ) bash-3.2$ softwareupdate -l Software Update Tool Finding available software Software Update found the following new or updated software: * iTunesXPatch-12.6.1 iTunes (12.6.1), 191180K [recommended]

tdurdan
New Contributor

Same issue here. Intermediate Certs are deployed via config profile and configured with Use System Defaults. Roots are set to always trust.

perrycj
Contributor III

No issues here on 10.12.5 and a fresh 10.11.6 Mac with the latest Security update from yesterday. Full 802.1x on wired and wireless.

For those have issues, in the trust section of your configuration profiles delivering your payloads are you trusting by common name or by exact certificate name?

966aa083d9b842258e20809b31adf1c4

If you're trusting by common name, that's probably what the issue is. Make sure that box is unchecked and check to trust exact certificate and see if it's resolved.

bbot
Contributor

@perrycj Our trust section in the config profile is blank. For the trust section, would this be the certificate required to connect to wifi? In our case, we use machine certificates requested from AD. How do I specify the exact certificate name in a configuration profile when all the certificate names are different?

mbezzo
Contributor III

dumb question? Where's the "Trust" section? It must be right in front of me, but I can't find it!

Thanks!

bbot
Contributor

@mbezzo It's in the wifi payload of the configuration profile. Scroll to the bottom and click the Trust tab.

mbezzo
Contributor III

@bbot - ahhhh, thank you. :)

NowAllTheTime
Contributor III

@perrycj are you including all of your certs in the cert chain in that same configuration profile and then selecting those? We deploy the root and intermediary certs in a separate profile, so I'm attempting to use their common name (and leaving the exceptions box unchecked) but it's not making a difference. I'm waiting on the engineer working our case to send us further suggestions - but I was just curious about whether or not you have your certs all within the same profile or split apart multiple profiles like we do.

chisox1
New Contributor

Adding our intermediate cert as a trusted certificate seemed to fix it for our organization.

bbot
Contributor

@chisox1 just to confirm, you checked the box for the intermediate cert under Trusted Certificates Certificates trusted/expected for authentication

then redeployed the configuration profile, updated to 10.12.5 and confirmed the wifi stayed connected?

chisox1
New Contributor

Correct! How I will deploy it to everyone without breaking them is a different story.

bbot
Contributor

@chisox1 Are you using AD certificates for wifi? How are you currently deploying the profile?

perrycj
Contributor III

@jasonaswell All the certs we use are deployed with our wifi payload and in that trust section, I check off our Root CA as the trusted cert. You can check whichever cert is appropriate for your environment. Our ethernet profile has no certs in it at all because the trust is established with the certs from the wifi profile.

I think if you just avoid using the common name at all and just check off the cert name as the trusted cert, you should be good.

perrycj
Contributor III

@bbot its just the trust that gets redeployed.. meaning you don't have to worry about having to generate another machine cert from AD (although it will happen automatically when you redeploy the configuration profile anyway). if you select to use either your intermediate or root CA as the trusted cert, not use the common name and redeploy that profile, it should work fine. Does that make sense?

bbot
Contributor

@perrycj Makes sense. The part where I'm stuck is that I have a separate config profile that has the root + intermediate certificates. We deployed the certificates before we rolled out 802.1x wifi. (this is still active)

Now we have a separate profile that includes both root + intermediate certs, AD cert request and wifi config. I'll need to do some testing, but I think making the trust setting in this wifi config and re-deploying should resolve it.

perrycj
Contributor III

@bbot sure that's fine too. In that certs profile, just make sure to check off the box for the cert you want to trust and uncheck the box from common name trust and you should be fine.

bbot
Contributor

@perrycj In the certs profile, I don't think there's an option to check the box to trust. It'll have to be in the wifi configuration profile. The cert profile I have only deploys the root and intermediate certificates

perrycj
Contributor III

@bbot Yes sorry.. I meant on the connection having the issues with 10.12.5.. so if it's wifi, then in the trust section there. It has to be defined somewhere so it should be in your wifi profile under trust.

scheb
New Contributor III

So it appears the change is that we must explicitly tell the supplicant (via network payload trust tab) what radius server(s) it is authorized to provide the cert to (either by trusting the radius server's CA or inputting server names). Before it worked without this. You will probably have to add that cert to your certificate payload if the radius server's cert is signed by a different CA than your client cert.