At my client, there is a small smattering of Special Egg Mac users. Unfortunately, they are reporting that the App Store for updates is ... not working through the MWG's.
Any tips or experiences appreciated.
I'm seeing some barking about swscan.apple.com and its SSL cert not matching. Which is odd because from another IP address/computer/version of curl, curl claims the altname of the cert matches swscan.apple.com ... but from my proxy command line, curl -visk https://swscan.apple.com/ only sees a CN of *.isu.apple.com which of course... doesn't match. openssl s_client -connect:swscan.apple.com | openssl x509 -txt seems to be consistent across all the ip's and OS's I tested from, and all seem to be quite sure that the SSL cert is CN's and alt subject'd for *.isu.apple.com and not swscan.apple.com.
Curious if others see issues with swscan.apple.com 's ssl cert, and/or know how if at all it figures in with this issue preventing Mountain Lion machines from pulling OS updates. Does apple have this goofed up and is MWG 126.96.36.199 doing the right thing with it? Is it safe/necessary to pull this one into the cert whitelist?
Thanks in advance for any shared fun wtih Apple OS X.
on 2/27/13 12:42:08 AM CST
This is still unresolved (help from other people with Macs updating behind an MWG and strong egress rules still being solicited!), but I did learn several things:
1) MWG 188.8.131.52 doesn't appear to grok sites that use SSL SNI (server name identification). http://en.wikipedia.org/wiki/Server_Name_Indication
If you have access to a linux box or cygwin with a recent openssl ( > 1.0 ) have a look at
openssl s_client -showcerts -servername swscan.apple.com -connect swscan.apple.com:443
(which gives the appropriate swscan.apple.com certificate)
openssl s_client -showcerts -connect swscan.apple.com:443
(which coughs up the *.isu.apple.com wildcard certificate)
This difference is telling. MWG 184.108.40.206 appears to ship with openssl 0.9.8.x ... which doesn't grok SNI and its s_client lacks the -servername support. So methinks a lot of people who have a certificate verification rule in their policy will have to manually add a cert whitelist entry for swscan.apple.com to work through the difference between *.isu.apple.com and swscan.apple.com.
2) In addition to having to manually import swscan.apple.com's SSL cert, if you're controlling POST uploads in an environment, apparently Apple wants to upload things to:
[update: this may be a red herring -- the user with whom I was working admitting to having registered it with his personal Apple account which may have caused this communication to happen and may be unrelated to updates]
3) And if you're blocking personal storage networks, even if icloud isn't configured mountain lion appears to want to download from
But I still don't have this football in the endzone. For some reason I'm still getting blocks from keyvalueservice.icloud.com that I'm trying to clear.
Message was edited by: Regis on 3/5/13 5:18:53 PM CST
It also appears that the app store Mountain Lion doesn't play well with chunk encoding. Have you tried adding the proxy control to your whitelists?