Closed Bug 972304 Opened 6 years ago Closed 5 years ago
_error _ocsp _invalid _signing _cert prevents user from adding certificate exception when OCSP stapling is enabled
I have the problem here that users of my webserver can't access https pages any more with an invalid cert. I.e. they can't add an exception. This only happens in firefox 27 and not in firefox 26. The error they get is: Invalid OCSP signing certificate in OCSP response. (Error code: sec_error_ocsp_invalid_signing_cert) The server has a default wildcard certificate from cacert.org. So users surfing with default firefox should usually get a "Untrusted Connection"-warning and the option to add an exception. However, that doesn't happen. I don't know if I understand everything that happens here correct, but to me it seems Firefox is trying to ocsp-verify the cert before it gives the user the opportunity to add an exception. Obviously, the ocsp response is not accepted, as the root cert is not in firefox. So this means if a cert has an ocsp responder, the possibility to add an exception for an untrusted certificate is no longer usable. Test: Go with plain firefox 27 to https://www.schokoeks.org/ - will show sec_error_ocsp_invalid_signing_cert error. What should happen: Go with plain firefox 26 to https://www.schokoeks.org/ - warning about untrusted connection and exception can be added.
The URL was misspelled. It is https://www.schokokeks.org/ (note the missing "k").
Thanks freddyb, sorry for the misspelling. Okay, I found out one more thing: Our server has OCSP stapling enabled. If I disable that then the error doesn't occur.
Summary: sec_error_ocsp_invalid_signing_cert prevents user from adding certificate exception → sec_error_ocsp_invalid_signing_cert prevents user from adding certificate exception when OCSP stapling is enabled
One more thing: As this is a severe problem for some of our customers, as a workaround I have disabled OCSP stapling, so the above testcase doesn't work any more. You can still test the behaviour with this URL: https://backup1.schokokeks.org/
Seems to be the same as mine : 971750 Duplicate ?
I have the same symptom (sec_error_ocsp_invalid_signing_cert) in Fx28 on our internal network - despite OCSP validation being deactivated. However, I cannot reproduce the problem reported here on https://backup1.schokokeks.org/ - neither with OCSP validation enabled nor disabled. Is there anything I could do to diagnose what's going on here? Apologies if I'm actually reporting a different issue.
(In reply to Stefan Moebius from comment #5) > I have the same symptom (sec_error_ocsp_invalid_signing_cert) in Fx28 on our > internal network - despite OCSP validation being deactivated. However, I > cannot reproduce the problem reported here on > https://backup1.schokokeks.org/ - neither with OCSP validation enabled nor > disabled. > > Is there anything I could do to diagnose what's going on here? > > Apologies if I'm actually reporting a different issue. As I understand it, the pref "security.OCSP.enabled" controls OCSP fetching. The pref "security.ssl.enable_ocsp_stapling" acts independently of that setting. So, if you want to disable all OCSP checking, you'll have to also set "security.ssl.enable_ocsp_stapling" to false.
Thanks David, that solved my issue. Given that apparently our company intranet allows to reproduce various OCSP issues, let me know if I can help in any way. Building and running software is possible, development is not (for time restrictions).
Will be fixed when we enable mozilla::pkix by default, because mozilla::pkix processes stapled OCSP responses only after building a valid cert chain. If no valid cert chain can be built, then mozilla::pkix won't process the stapled OCSP response.
Depends on: mozilla::pkix-beta
Target Milestone: --- → mozilla31
Is this working the way you expect, with OCSP stapling enabled?
I think this is fixed with the new PKIX code. Can't reproduce it any more with current firefox.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Hanno, may I ask you to please test your setup with Firefox 31, which is an enterprise support branch? We'd like to avoid regressions on that branch, so it would be interesting to know if adding an exception in your scenario works or not. I'd be interested in test results, for both PKIX and non-PKIX code path, which can be switched using this preference: security.use_mozillapkix_verification (about:config) The most recent Firefox 31 ESR release can be found here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/31.1.1esr/ Thanks in advance!
You need to log in before you can comment on or make changes to this bug.