Not sure if it's a valid bug in Firefox (maybe it's an issue with the website), but some users reported here: http://forums.mozfr.org/viewtopic.php?f=5&t=119230 STR: Go to https://www.fanfiction.net/ Result: An error occurred during a connection to www.fanfiction.net. Invalid OCSP signing certificate in OCSP response. (Error code: sec_error_ocsp_invalid_signing_cert) Regression range: good=2014-03-31 bad=2014-04-01 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=382f676d0ed9&tochange=1417d180a1d8 Maybe one of these bugs: David Keeler — bug 990248 - enable mozilla::pkix by default in Firefox Nightly r=briansmith r=cviecco David Keeler — bug 989516 - mozilla::pkix: temporarily allow improper basicConstraint:cA encodings r=cviecco David Keeler — bug 987295 - mozilla::pkix: test ocsp extension decoding r=cviecco David Keeler — bug 987295 - mozilla::pkix: fix decoding OCSP response extensions r=cviecco
The OCSP responder certificate included in the stapled OCSP response has expired. It should be replaced. (In other words, this is a problem with the website.)
Ok, thanks for the fast reply. I have contacted them.
Assignee: nobody → english-us
Component: Security: PSM → English US
OS: Windows 7 → All
Product: Core → Tech Evangelism
Hardware: x86_64 → All
Version: 31 Branch → Trunk
We're actually having this exact same issue on a website that we run ourselves can you explain how you were able to figure out that the OCSP responder certificate was expired?
I am also experiencing this problem sec_error_ocsp_invalid_signing_cert it has occurred on globalsign.com i.emlfiles.com and various others intermittently, all they seem to have in common is the are globalsign certificate.
Hi, so the address work well enough with others navigators, we have this bug only with firefox since the last update (this morning European time), so I know I'm not a developer, but how can it be fanfiction.net fault? and even when we try to disable OCSP certificate in firefox options, it's not working...
(In reply to aweaver614 from comment #3) > We're actually having this exact same issue on a website that we run > ourselves can you explain how you were able to figure out that the OCSP > responder certificate was expired? I used wireshark ( http://www.wireshark.org/ ) to capture packets while connecting to the website. Filtering on ssl.handshake.cert_status showed packets involved in OCSP stapling. Going through those packets I was able to inspect the certificate that signed the response.
we host two sites on our webserver both with SSLS that were issued at different times and they are both failing with same error sec_error_ocsp_invalid_signing_cert similar to martin lees comment4 - they are both globalsign.com certs in the office we have a windows 7 - v30 firefox working fine windows 7 - v31 failing windows 8 - v31 failing
to follow up I've installed v30.0b9 from http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/30.0b9/ and the SSLS for our sites are valid again?
Why does Firefox 30 not report an error in this case? Is mozilla::pkix being more strict than necessary, or plain wrong, in some check?
site work with: older version of firefox => check others navigators (even the mobile versions) => check so yes, there is a problem with the site. Not. (sorry but after the day I had, my answer is sarcasm, I can't help myself)
This site works perfectly on my IPad and Nook but not on my computer with Firefox. I am not a happy camper. How can I return to the previous version because this one sucks.
From what I can tell, NSS verifies OCSP responder certificates at the time the response was generated (i.e. 'producedAt'), not the current time (which is what I believe mozilla::pkix does) : http://hg.mozilla.org/mozilla-central/file/005424a764da/security/nss/lib/certhigh/ocsp.c#l4164 4164 /* 4165 * The function will also verify the signer certificate; we 4166 * need to tell it *when* that certificate must be valid -- for our 4167 * purposes we expect it to be valid when the response was signed. 4168 * The value of "producedAt" is the signing time. 4169 */ 4170 rv = DER_GeneralizedTimeToTime(&producedAt, &tbsData->producedAt); ... 4187 rv = cert_VerifyCertWithFlags(handle, signerCert, PR_TRUE, certUsage, 4188 producedAt, CERT_VERIFYCERT_SKIP_OCSP, 4189 pwArg, NULL);
this morning i've tried one of our sites and its working? in v31 with no changes to our server nor our certificates https://www.fanfiction.net is also working with out the issue? our other site is still failing with Error code: sec_error_ocsp_invalid_signing_cert it would seem something is changing somewhere its just taking time replicate?
Hi the problem is than that in OCSP the certificate is validation comes from the server from which the site is being hosted (IIS in our case), which has been cached from the CA. We had confirmation from globalsign that one of their OCSP servers was not working properly and was issuing out of date certificates. These then got cached and stored on the server for a period of time (a restart of our servers fixed the issue by clearing the cache which usually lasts 18 hours). However firefox when receiving the out of date certificate should have fallen back to verifying this was correct with the CA (which it doesn't do in v31).
Not an issue anymore.
Assignee: english-us → nobody
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Component: English US → Desktop
Resolution: --- → WORKSFORME
An issue again, per https://support.mozilla.org/en-US/questions/1036573 ?
This appears to be the same issue. If you change the pref security.ssl.enable_ocsp_stapling to false then the web site works again. The OCSP responder itself appears OK because it still works if you set security.OCSP.require to true. Either the stapled value comes from a different server or it's simply stale. I haven't captured the packets to investigate the difference, but it would be important to do so when trying to assign blame to GlobalSign or FanFiction (that is, GlobalSign might be handing out bad stapled values, or FanFiction may be failing to update them regularly).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I'm wondering does Chrome handle this behavior differently because the site loads fine in Chrome's latest. I would hate for us to shed users even if the behavior in Firefox is intended but users try it in Chrome and it just works.
FWIW it was fixed again it seem, see http://blog.fictionpress.com/2014/12/15/firefox-compatibility-fix/
Thanks Alex. Let's close it as fixed again :)
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → FIXED
Component: Desktop → Desktop
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.