The best type of issue to observe is the type with
- Random and conflicting symptoms,
- Tied to a "feature" introduced in some basic piece of infrastructure that everyone either ignores or just does not know about.
- The failures can be bypassed but cause ongoing annoyance and concern.
Apple OSX is currently struggling with one such issue handling web site security certificates. I have seen this one myself on an up to date MacBook Pro laptop. Websites that need to be trusted (banking, paypal etc) barf certificate error messages and the AppStore gives "Connection error" when trying to update software even though iTunes store logs in correctly with the same AppleID.
Some background information on Website certificates
Website certificates are part of the trust mechanism that tries to ensure that the website your talking to is the actual website and when talking to that secure website, no one snooping can see what your talking about. Without going too deep on this, trust certificates are built into programs and websites which are then used to set up and validate secure end to end connections. Most peoples experience of these infrastructure operations extends to seeing the "S" in a secure web address such as httpS://www.xyz.com. See this for yourself go to www.ebay.com and click login. The webpage address at the top of the page changes to https://signin.ebay.com/... In the background an encrypted secure SSL connection is set up and used to pass the login details and password to the website using encryption. Anyone listening into your data conversations would see the connection to the websites being made but are not be able to read the user names and password as they are passed to the website.The SSL connection and website certificates mechanisms are based on a public/private key crypto system. This system works on the basis that if you encrypt information using a publicly available key, that information cannot then be decoded unless you have the private key. The public keys are distributed freely to programs that need to send information but the private "Decode" keys are held safe at the receiving organisation. Anyone intercepting the message may know the public key and the encoding mechanism but will not be able to read the message without the companies private key. Think of a special padlock with two keys. One key can only lock the padlock and the other can unlock. The padlock and the locking key is freely distributed but the unlock key is held securely. Using this special padlock, goods can be secured in transit. The trust certificates ensure that your are getting the public key from the correct organisation and not another pretending to be the receiving organisation.
Part of the trust certificate system is a mechanism to revoke and cancel certificates that have been stolen or broken. Amazingly this revocation system was not implemented in some operating systems certificate handling code until recently. Full use of both certificates and the revocation mechanism has long been a requirement of even mildly secure internet security protocols. Recent break-ins to organisations that really should know better has reenforced the need for both secure certificates and a revocation mechanism. Read more about CRLs and OCSP to get a view on how some of this technology works.
Apple's certificate problem
When browsing and trying to login to sites that use the above httpS mechanism would sometimes get an error message similar to "This certificate was signed by an untrusted user." Looking at the Safari activity window a similar message is seen. In this example the site certificate https://www.paypalobjects.com/ that was issued by Verisign does not work correctly. The web page behind showed with the correct details from Paypal but the graphics from www.paypalobjects.com missing.
This problem also shows up when using the Appstore to get software updates. After selecting an update, an Apple_ID login box appears. Logging in using the same credentials that work correctly for iTunes gives the cryptic error message "Connection failed." The problem seems to have first shown up in the recent OSX 10.7.4 update.
This is a type insidious error that causes a loss of trust in both the platform being used and the apparent "security" of the internet for Mac users. Having to bypass bogus certificate errors on a regular basis trains users to ignore the unusual and vastly increases the chances of accepting a hostile or correctly revoked certificate.
Looking at the Apple forum entries on this issue, amongst the normal forum noise and confusion, the following suggestions can be seen:
This is a system clock issue: True, if set a long way out, can cause certificate to appear as expired when they are not. This does not cover the "invalid issuer" messages that are at the heart of the issue.
This is an ocspd issue: Kind of in the right area, it is a certificates problem. However the suggestion that followed to change the preferences in Keychain application to switch off the certificate revocation mechanisms CRL and OCSP. This is madness do not do this. This is the sort of Doh! advice that goes alongside "Never forget where your car keys are by leaving them in the car."
The normal setting for the above items are "Best Attempt".
What fixed it for me
Looking down the posts the following entries by Apple forum user quickStifixed it for me and others. It did take about 10 minutes poking into the unfamilier Keychain application but has fixed the web site certificate ( invalid issuer ) error and I can now login to the AppStore.
Good Job quickSti.
