-
All replies
-
Helpful answers
-
-
May 29, 2012 3:00 PM in response to KevinMSDby caj001,KevinMSD, I noticed that one also. There are many sites that I visit that have nothing to do with Facebook, but I will got several messages popping up regarding the Facebook security certificate.
I scanned my system with Symantec Endpoint Protection just to make sure there is no trojan or virus activity. If so, the latest SEP and virus definitions can't find it.
-
May 29, 2012 4:09 PM in response to caj001by jbixler,You guys are getting the message about Facebook because many sites allow you to either use Facebook's authentication system to create an account on that site, or they've got social sharing features on the site which allow you to post stuff directly to your Facebook wall.
-
May 29, 2012 8:08 PM in response to jbixlerby sfdiego,I noticed that my system wasn't trusting any certificates signed by Verisign. I downloaded this certificate from Verisign and imported it into Keychain Access, it solved the problem for me:
http://www.verisign.com/repository/roots/root-certificates/PCA-3G5.pem
[ from here: http://www.verisign.com/support/roots.html ]
-
May 30, 2012 8:47 AM in response to sébastienfromquebecby Mardovar,With the latest updates, Safari is requesting the CRL (certificate revocation list) from the issuer of the certificate to validate the certificate. However, the request is made to without authentication and therefore the proxy rejects the request. The request is not reissued with credentials and the keychain process assumes the certificate is invalid because it cannot verity that the certificate is no on the revocation list. We have decided to add many of the certificate authorities to our list of sites that may be accessed via our proxy server without authentication and now Safari says that the certificates are valid. So far we have whitelisted verisign.com, thawte.com, godaddy.com, digigert.com and geotrust.com. For a US site, this seems to cover the majority of certificates we see.
Apple should fix this problem and use the credentials in the keychaing for the crl web requests.
-
Jun 5, 2012 1:29 AM in response to Mardovarby Basti756,Add me (and my colleagues) to the list.
Using a whitelist is a good idea but actually Apple should come up with a bugfix to solve this.
-
Jun 8, 2012 12:57 AM in response to sébastienfromquebecby KTor,I have the same issue with Google certificate on Safari, Chrome and Mail. Firefox is the only one that works right probably because it doesn't use the system certificates.
Few weeks ago I had the same issue with Verisign certificates but it soved out by deleting the certificates from Keychain Access. I can't do the same with Google certificates because I can't find any Google certificate in Keychain.
Does anyone has a solution for this?
-
Jun 9, 2012 2:47 PM in response to Linc Davisby AtlantaPam,Thank you for your suggestion. I deleted the files crlcache.db and ocspache.db and I kept the window open. I just watched them reappear under private/var/db/crls/
-
Jun 9, 2012 4:40 PM in response to quickStiby antonyoung,Thank you quickSti! This finally solved the problem for me.
quickSti wrote:
I solved this on my wife's computer by resetting the security certificate settings. This might help others:
Close all windows.
Keychain Access -> click on System Roots on the left, and then click on Certifcates on the bottom left.
Check to see if any of the certificates on the right have the blue "+" symbol - this means they have custom trust settings.
There is a bug in changing the policies, so you'll have to change them via the method below. Changing them just by changing the access to "system defaults" doesn't seem to save. The method below worked for me.
Double-click on each certificate with the custom setting (blue "+"), expand the section labled "trust". Change the "Secure Sockets Layer (SSL)" setting to "no value specified". Close window - you should be prompted for the password. Double-click on the certificate again, expand trust, change the "When using this certificate" setting to "Use System Defaults". Close window, and re-enter password.
If you didn't re-enter your password upon closing the window, the setting didn't take. The blue "+" should disappear after a few seconds when it's set back to default. Once all of the certificates are changed back to default, restart Safari.
This solved all of the problems for my wife's computer with these issues and OSX 10.7.4
-
Jun 9, 2012 5:47 PM in response to quickStiby marc from white river junction,Just got around to trying this, worked perfectly - thank you!
-
Jun 9, 2012 5:50 PM in response to antonyoungby frazzm737,Thank you, anton young! I just tried your tip. I merely made the change to the verisign certificate that showed the blue+ sign and now I can finally access my credit card sites. Most of the others in foreign languages I didn't mess with. I have printed out your instructions in case I need to change any other certificates. Thanks again--yours was the first suggestion that seemed to solve the problem easily.
-
Jun 9, 2012 5:51 PM in response to sébastienfromquebecby dean23,check to see if the date and time is correct as that can flag issues with certifcates.
-
Jun 9, 2012 6:31 PM in response to dean23by frazzm737,Date and time are correct--I can now access secure sites with Chrome and Safari, but not FF. that must be due to some security setting within the browser.
-
Jun 9, 2012 10:03 PM in response to frazzm737by frazzm737,I see that I erred when giving thanks for the solution which solved the problem. My thanks go to quickSti! I was so excited to find a solution that I overlooked the name of the original poster. Thanks again-- this problem was driving me crazy.
-
Jun 10, 2012 5:29 PM in response to sébastienfromquebecby edfromarvada,Thank you quickSti, you solved my problem as well. Apple senior tech finally got back with me and reported apple engineers had no answers as of yet so I gave him your thread that solved the problem. He was going to pass it on up to apple engineers in hopes that they could now solve the problem for everyone else with an update.