This discussion is locked
Close
Q: Cannot access HTTPS urls; Safari hangs blank, crashes
Previous
Page
2
-
Dec 4, 2006 11:59 AMby Anders Holm,More info.
Using the "Certificate Assistant" available from the Keychain appl. I attempted to check the certs that the banks with problems present.
And something strange, or curious, turned up: the Assistant tool claims that there is a host name mismatch. This means that Safari (or Mac OS) believes/claims that the domain name that I am retrieving the server cert from does NOT match the domain name in the server cert. But this is not true.
I really do not understand what is happening here, but it sort of reinforces my belief that this is an Apple problem.
/AH -
Dec 4, 2006 11:07 PMby SPD,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. -
Dec 5, 2006 2:38 AMby Petterf,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 AMby CaptainKurt,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! -
Dec 5, 2006 6:41 AMby billcole,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. -
Dec 5, 2006 9:08 AMby Steve BC,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 AMby Neomancer,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 -
Dec 5, 2006 9:26 AMby 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 -
Dec 5, 2006 9:33 AMby dkallan,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"):
CSSMCLCertGetAllFields: CSPINVALID_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 AMby 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? -
Dec 5, 2006 10:11 AMby 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 -
Dec 5, 2006 10:17 AMby Steve BC,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
