Skip to main content

W have an authenticated internet (Cisco SCE) system and found some issues with latest 10.7.4 upgrade.



If you are not authenticated, it gives invalid certificate issues on some application installs and Configuration profile registration with APN servers.



Installing Office 2011 with SP2 Installer.pkg...

       Installation failed. The installer reported: installer: Package name is Microsoft Office for Mac 2011

installer: Certificate used to sign package is not trusted. Use -allowUntrusted to override.


15/05/12 11:15:39.992 AM applepushserviced: Got connection error Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “albert.apple.com” which could put your confidential information at risk." UserInfo=0x100b52760 {NSURLErrorFailingURLPeerTrustErrorKey=<SecTrust 0x7f884051c8f0 80x7fff73701fa0]>, NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, NSUnderlyingError=0x100b39720 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “albert.apple.com” which could put your confidential information at risk.", NSErrorPeerCertificateChainKey=(

    "<SecCertificate 0x7f8840547ec0 00x7fff73701fa0]>",

    "<SecCertificate 0x7f8840535200 00x7fff73701fa0]>",

    "<SecCertificate 0x7f884052c9f0 00x7fff73701fa0]>"

), NSLocalizedDescription=The certificate for this server is invalid. You might be connecting to a server that is pretending to be “albert.apple.com” which could put your confidential information at risk., NSErrorFailingURLKey=https://albert.apple.com/WebObjects/ALUnbrick.woa/wa/deviceActivation?device=MacOS, NSErrorFailingURLStringKey=https://albert.apple.com/WebObjects/ALUnbrick.woa/wa/deviceActivation?device=MacOS, NSErrorClientCertificateStateKey=0}


Also seen a post in Apple Support Community regarding "Invalid Certificate on every secured website"
https://discussions.apple.com/message/18353267#18353267

Signed installations and configuration profiles are highly sensitive to the certificates working properly. If by not being authenticated you don't get a connection back to the CRL listed on the cert, you're going to fail the certificate validation (and thus the install).

We implemented the following updates to the keyhain preferences to resolve (or workaround) the issue:
defaults write com.apple.security.revocation OCSPStyle -string None
defaults write com.apple.security.revocation RevocationFirst -string CRL

@Jared



It happens only with 10.7.4 and it was validating those certs with 10.7.3 without any issues. It's definitely an issue with OS X 10.7.4. Not to do anything with our Cisco CSE.

FYI we have this same issue using an authenticated proxy on Bluecoat proxies. Hope Apple solves this soon as it breaks AD functionality in certain cases as well as most corporate apps that we have set to completely disallow untrusted certs.

@johnsaxon- are you setting those as user or computer level mcx's?

I think jarednichols is correct. It seems 10.7.4 comes with new certificates which need to be validated. We had to allow these cert validation sites to get it working.



We have been able to get it working by allowing these sites exempted over HTTP.



crl3.digicert.com
crl4.digicert.com
crl.geotrust.com
crl.entrust.net
crl.verisign.com
ocsp.verisign.com
crl.apple.com
ocsp.apple.com
ocsp.entrust.net

Reply


Terms & ConditionsCookie settings