Level 1

149 points

Cannot access HTTPS urls; Safari hangs blank, crashes

At noon today (11/30) Safari suddenly began refusing to go to https pages to allow me to login to secure websites. (I am using Firefox to enter this topic.)

I have "Reset Safari", tossed Safari cache files, tossed System cache (kext) files and LaunchServices files, and removed Safari's pref folder and plist file out of my Preferences folder. I have installed all system updates (more than a week ago, so they do not appear to be the trigger for today's problem) and installed security update 2006-007 this afternoon after the problem began. I have also reset my cable modem, verified that Network is properly configured with no proxies checked inadvertently. I have turned IPv6 from Automatic to Off. I have used Onyx to clear all caches and perform maintenance routines. I have repaired permissions. Nothing has worked.

Does anyone have a suggestion on how to correct this problem? Firefox, Mail, and other applications that access the net are working fine, so it appears to be a Safari problem, but I suppose it could be a problem with a System file that Safari uses to perform https operations. Any ideas?

Thanks for the help.

Steve

15 AlBookG4-1.25GHz Mdl-A1046 Mac OS X (10.4.8)

Posted on Nov 30, 2006 4:10 PM

28 replies

V3G4

Level 1

0 points

Dec 4, 2006 6:33 PM in response to Steve BC

I would use Firefox at the moment for anything important. Like sites that involve money or something real personal. Turning off certificates does downgrade your security. It can screw up secured email as well.

SPD

Level 3

530 points

Dec 4, 2006 11:07 PM in response to V3G4

Good advice, I'm sure.

But what exactly do these settings do? There is "Best attempt," "Require if," and "Require all."

I just noticed that changing from "require all" to "require if" means that some secure sites are accessible. But what is given up in terms of security?

Does the Help page offer any information?

Thanks.

Petterf

Level 2

399 points

Dec 5, 2006 2:38 AM in response to SPD

Help pages text:

Here is an explanation of the settings available:
Off: No revocation checking will be performed.
Best Attempt: The certificate passes unless an indication of a bad certificate is returned from the server.
Require if Cert Indicates: If the URL to the revocation server is provided in the certificate, this setting requires a successful connection to a revocation server and no indication of a bad certificate.
Require for All Certs: This setting requires successful validation of all certificates. It is most useful in a tightly controlled environment that guarantees the presence of a CRL server or OCSP responder.
Priority: Determines which method (OCSP or CRL) is attempted first. If the first method chosen returns a successful validation, the second method is not attempted."

Dual G5 2.5GHz & x800XT | G4 Cube 800MHz & GF3 Mac OS X (10.4.8)

Dec 5, 2006 3:28 AM in response to Steve BC

This seems to be a WebKit-Problem which Apple introduced with the Nov.30th Security Update. Certificates cannot longer be verified. This affects besides https-Pages in Safari also SSL-Mailboxes (Pop und SMTP) in Mail, .Mac-Backups to iDisk and also iTunes Store-Music-buys!!
The current workaround is two possibilities:
1: Use Firefox instead of Safari und disable SSL in Mail and omit buying ITS-Songs or
2: Turn off certificate validation in Keychain-Access-Preferences. Attention: you are not longer working on the safe side of life!
Both workarounds are not satisfying and I am heavily disappointed that no Apple representative is responding to this issue!

billcole

Level 1

44 points

Dec 5, 2006 6:41 AM in response to Steve BC

From Ronnie the Snowflake (nice name! 🙂 ):
"I experienced not being able to access HTTPS -
Secure Sites this my Solution:
Go to Applications > Utilities: Open Keychain Access
Keychain Access > Preferences: 'Certificates'
Check - 'Online Certificate Status Protocol' (OCSP):
OFF
'Certificate Revocation List' (CRL): OFF
Priority: OCSP (this will be greyed out)
Also check in Keychain Access the keychain
'X509Anchors' for any Certificates with a Red Cross
beside them ...... highlight these and delete them
(they are invalid).
Then Open Safari and access a Secure HTTPS Site."

I found it adequate to simply turn off OCSP. No need to clean out the expired root certs, quit Safari, or turn off CRL.

It appears from a little poking into what's going on with my system that the root cause here is unresponsiveness on the part of ocsp.verisign.net, which is an OCSP server that is used by Apple's OCSP implementation.

I thought about doing something like this, but I
simply don't know enough about protocols and
certificates to understand what I would be doing. It
seems to me that, in turning OFF these protocols, you
are turning off the system's ability to verify
certificates and therefore are eliminating the
system's ability to authenticate your certificates,
in which case your system is no longer able to
recognize when a certificate has expired or for good
reason becomes invalid or otherwise should not be
trusted. It seems to me that this would degrade your
SSL and other security protocols over time. I really
have no clue on this but rather am making an
assumption.

OCSP and CRL are different approaches to checking if a technically valid certificate has been revoked. Turning off one or both opens a narrow window of risk, not a big gaping hole.

Perhaps someone can post a URI for an article that
clearly explains anchors, certificates, protocols,
and so on, in a coherent way, so I would have a
better idea how to handle this kind of problem in the
future.

http://www.openvalidation.org is not a terrible place to start for a non-technical person. Apple's terminology is a little unusual (Anchors instead of roots) but not really wrong.

Also, I might add that my problems with root
certificates, etc., began shortly after I deleted a
red-crossed root certificate for the first time in my
entire life.

Probably not related unless you fat-fingered the deletion.

Deleting expired certs should not cause any trouble, although it might change the way the failure of a dependent cert is noted.

I have no idea whether the issue I
ended up having was related to that, although it
would seem not, on theoretical grounds, yet (magical
thinking) once-bitten, you know...

Further note that I did not apply Security Update
2006-007 until after I began having this problem,
so the problem does not appear to have anything to do
with that update.

This is NOT specifically a problem with that update. It is a problem with OCSP and a particular server.

Petterf

Level 2

399 points

Dec 5, 2006 8:17 AM in response to billcole

Thanks for the great info Bill. 🙂

Steve BC Author

Level 1

149 points

Dec 5, 2006 9:08 AM in response to billcole

From BillCole:

I found it adequate to simply turn off OCSP. No need
to clean out the expired root certs, quit Safari, or
turn off CRL.

It appears from a little poking into what's going on
with my system that the root cause here is
unresponsiveness on the part of ocsp.verisign.net,
which is an OCSP server that is used by Apple's OCSP
implementation.
OCSP and CRL are different approaches to checking if
a technically valid certificate has been revoked.
Turning off one or both opens a narrow window of
risk, not a big gaping hole.

http://www.openvalidation.org is not a terrible place
to start for a non-technical person. Apple's
terminology is a little unusual (Anchors instead of
roots) but not really wrong.

Deleting expired certs should not cause any trouble,
although it might change the way the failure of a
dependent cert is noted.
This is NOT specifically a problem with th[e Security] update.
It is a problem with OCSP and a particular server.

Thank you for an excellent and very informative post, BillCole. I will definitely check out the URI you posted. And I must note that I have very skinny fingers, so perhaps the apparent increase in trouble was related to a dependent certificate problem.

I appreciate the reassurance about turning off OCSP not opening a gaping hole, only a minor one, as well as your description of OCSP, CRL and how things work - or don't.

I do have an observation, though. You state that the problem is not on my Mac but rather due to an unresponsive Verisign server, yet my problem clearly went away completely after I reformatted my hard drive and reinstalled everything. Now it could be that the Verisign server returned to a responsive state during the few hours it took for me to nuke my drive on Friday afternoon, but that seems a somewhat unlikely occurrence. If the Verisign side of this issue was not resolved at that time (which would have resolved the problem for everyone on Friday), then something on my Mac was causing, or at least contributing to, the problem. Obviously, I have no idea what that contribution might have been. Perhaps the information at openvalidation.org will help me figure that out.

Steve

Dec 5, 2006 9:13 AM in response to snowflake

Hi. I started having this problem also after the latest security update. Using your Keychain preference settings did solve the problem but I think there's something more to it:

- This problem only happens when I'm on certain networks.
- It tends to happen more often when I'm on a NAT'ed IP address.

Since turning off the OCSP and CRL checking in Keychain Access appears to solve the problem, could it be that there's a problem accessing the OCSP and CRL servers from certain networks?

I guess one way to find out would be to use the same OCSP and CRL policy in FireFox or another application and see if it breaks as well.

Message was edited by: Neomancer

Steve BC Author

Level 1

149 points

Dec 5, 2006 9:26 AM in response to Steve BC

Here's some useful info from MacFixit. The URI for this article is:
http://www.macfixit.com/article.php?story=20061204233133704

Here is the relevant text from the article, since the article will probably disappear soon. It occurs to me that my problems, which began before installing SecUpd 2006-007, may have sprung from a corrupted com.apple.security.revocation.plist file, which I did not know about at the time and did not try deleting:

Begin article from MacFixit:
"Login to secure sites fails (cont.) -- fixes We continue to report on problems logging into secure (https) Web sites in Safari and other WebKit-based applications after applying Security Update 2006-007. Since this update makes modifications to Webkit, it's logically implicated in the difficulties.
Even more telling than the WebKit changes, however, is the resolution (in this security update) of a vulnerability where "certain revoked certificates may be erroneously honored." It appears Safari is -- instead of erroneously honoring bad certificates -- erroneously rejecting some certificates.
There's one more change in Security Update 2006-007 that could be implicated in this problem: a fix for a vulnerability where it may be possible to create an X.509 certificate containing a public key that "could consume a significant amount of system resources during signature verification. An attacker may cause a system to process such a certificate, leading to a denial of service."
In at least some cases, the issue appears to be tied to certificates issued by VeriSign. Safari is incorrectly interpreting some of these certificates as invalid -- with a mismatch in the certificate-listed host name and host name of the visited URL.
As such, one potential fix involves deleting certificate entries using Keychain Access, as follows:
1. Launch Keychain Access (located in Applications/Utilities)
2. Click on "Certificates" in the left-hand pane
3. Delete any entries from VeriSign, or any certificates with a red cross next to them
4. Re-attempt access to the problematic secure site
The most successful fix, however, involves deleting the file com.apple.security.revocation.plist from the following directory:
• ~/Library/Preferences
You can replicate this workaround to some extent without deleting any files by opening Keychain Access (as mentioned above) then navigating to its Preferences (under the Keychain Access menu), clicking on the "Certificates" tab and making sure that both "Online Certificate Status Protocol (OCSP)" and "Certificate Revocation List (CRL)" are turned off. However, some users have found that only deleting the aforementioned file works.
Unfortunately, in some cases, it may be up to certificate providers to update their certification methods for compliance with Apple's new, more stringent security standards.
End article from MacFixit (349 words).

If you don't already scan MacFixit's daily fix sheet, I highly recommend you sign up for it. I have found it very helpful, and it's free. I don't have an affiliation with them. I am only a reader of their daily sheet.

Steve

dkallan

Level 1

20 points

Dec 5, 2006 9:33 AM in response to CaptainKurt

This issue just hit me as well, but more severely as it has impacted my entire OS/X Server SSL configuration, including Open Directory and Server Admin.

I have OS/X 10.4.8 clients connected to a 10.4.8 server. All of my server certificates -- including Mail, Open Directory, Apache, and iChat -- are verified by a self-signed X.509 CA certificate with an 8192-bit key.

Now, suddenly, Keychain Access and certtool barf all over the 8192-bit key. In my X509Anchors, the certificate data is now listed as invalid ("Unable to display this certificate"):

CSSM CLCertGetAllFields: CSP INVALID_ATTR_KEYLENGTH

OpenSSL 0.9.6 and 0.9.7 find it to be a valid certificate, and other applications (Firefox, Thunderbird, etc) have no problems.

Not only do Mail and Safari fail to function, I can no longer access the OS/X Server Admin. I now receive the error, "There is no server available at the address you entered. All services failed to access the address you provided for <server>. Check the address and try to log on again or contact your network administrator."

Some server certs have 4096- or 2048-bit keys. Certificates with 4096-bit keys or less are not a problem, but they all tie back to the 8192-bit CA cert.

Recreating and distributing new certs and chains to all client machines would be an administrative nightmare, and I'm not sure that I can change the Server certs and keys without access to Server Admin, anyway.

This is a huge problem, and I am stuck in the water. If anyone knows of a solution, or can get a response from Apple, please post it here!

Thanks,
dkallan

G5 Quad, G5 Dual, G4 PowerBook Mac OS X (10.4.8) OS/X Server 10.4.8

Dec 5, 2006 9:36 AM in response to Neomancer

Ok, I just set FireFox 1.5.0.7 on my computer to use OCSP and it, too, fails on HTTPS connections just like Safari does when Keychain Access is set to check OCSP.

The FireFox error is "Error establishing an encrypted connection to <hostname>. Error Code: -5990."

To me, this indicates that the Security Update was not the problem. Perhaps the Security Update improved security and resulted in the problem.

Do firewall settings need to be changed when using OCSP?

Steve BC Author

Level 1

149 points

Dec 5, 2006 10:11 AM in response to Steve BC

I just used openvalidation.org's validation service to check some of the expired (red-x'ed) certificates in my Anchors folder. I wanted to see if it would be ok to delete them. What I found is that the TC Center expired certificates (for example) were not revoked but still considered valid. That was a big surprise. So I figured I would post to let people know that deleting an expired certificate from your Anchors folder may not be a good idea. Since it doesn't appear necessary, I'd leave them alone. Deletion of the certificate itself may or may not be a problem, but any dependent certificates might get hung.

Steve

Steve BC Author

Level 1

149 points

Dec 5, 2006 10:17 AM in response to dkallan

dkallan, sorry to hear you are having such problems. In another post I mentioned a MacFixit article published today (12/5/06) with some ideas for fixing this issue. I'll repost the URI for that article here. I suggest you check it out for ideas that might work for you.

http://www.macfixit.com/article.php?story=20061204233133704

Good luck!

Steve

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Cannot access HTTPS urls; Safari hangs blank, crashes