111.68 KB, image/png
52.21 KB, image/png
61.92 KB, image/png
179.37 KB, patch
|Details | Diff | Splinter Review|
141.80 KB, patch
|Details | Diff | Splinter Review|
As reported in bug 1042889 comment 169/170, Firefox 36 displays error code sec_error_ca_cert_invalid for some https site with untrusted certificates, and doesn't offer the user to override and connect anyway. The bug can be reproduced using this test site: https://kuix.de:9451/ In this specific test case, the site's certificate was issued by a known CA (sent by the server) which misses the basic constraints extensions. As argued previously in bug 1042889, users might be stuck with devices that use incorrect embedded certificates, and it should be possible to override. (I don't know if other scenarios have regressed, too, most test links from bug 1042889 are still overridable.)
(In reply to David Keeler [:keeler] (use needinfo?) from bug 1042889 comment #167) > (In reply to will69 from comment #166) > > Thanks for fixing this in Firefox Beta. We can use HP ILO again with Firefox > > Beta, which we prefer to FF ESR or MS IE. > > > > It doesn't work in Firefox Nightly, though. Is this expected or are there > > more problems down the road? > > Bug 1091778 is a more general solution to this problem, and will hopefully > be fixed this cycle. We should land bug 1042889 on all branches given that bug 1091778 is neglected.
It's any workaroud for firefox 36? I have to log in some company site everyday. I have to install and use chrome now. But my favor is firefox and its bookmark manage, Hope fix it soon.
+1 to solve this bug
Can you post a copy of the certificate chain the server is sending? It seems likely that this is a x509v3 certificate without the basic constraints extension signing another certificate, but it would be good to know for sure.
David, we got another bug report in bug 1140090, with an example cert, the server sends a CA cert, and the CA lacks the basic constraints extension.
I think this problem is basically the same one that I am seeing. I can no longer logged into my Cisco 5505 VPN hardware box because Firefox 36 will no longer accept its self-signed certificate. I am currently using Firefox 35 to login and establish my VPN connection from my home office to the corporate office.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #5) > Can you post a copy of the certificate chain the server is sending? It seems > likely that this is a x509v3 certificate without the basic constraints > extension signing another certificate, but it would be good to know for sure. sorry,this CA for the company internal site, I may not private offer it .
I would like to request to fix this prior to the Firefox 38 enterprise release. Thanks.
Setting tracking flags. Enterprise customers require Firefox to be able to connect to their hardware, or they will use a different browser. As discussed and argued in other bugs, the initial error is sufficient, but it must be possible to override certificate errors.
Tracking as this impacts a user's ability to override sec errors. For an ex, see comment 10. Keeler - You're assigned but I don't see any comments from you in the bug. If you are going to work on this, we'll need a fix in the next week, preferably by Monday for Beta 6, if we're going to be able to consider a change for 37.
Created attachment 8576214 [details] [diff] [review] 1138332-ca_cert_invalid-override.diff
Comment on attachment 8576214 [details] [diff] [review] 1138332-ca_cert_invalid-override.diff Review of attachment 8576214 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for including the unittest changes!
Thanks for the review! https://treeherder.mozilla.org/#/jobs?repo=try&revision=c219dd745af2
I am available to test a proposed fix for this problem.
Apparently the OS X failures in that try run are from bug 1142006, so: https://hg.mozilla.org/integration/mozilla-inbound/rev/f31e275b498c
Dick, if you could test tomorrow's Nightly, that would be great: https://nightly.mozilla.org/
David, I will give it a try.
David, I tried accessing my Cisco 5505 VPN box with Firefox nightly build 39.0a1 dated 3/13/2015, but Firefox still hangs after being told to accept the self-signed certificate.
> I tried accessing my Cisco 5505 VPN box with Firefox nightly build 39.0a1 > dated 3/13/2015, but Firefox still hangs after being told to accept the > self-signed certificate. Could you please describe in more detail how exactly it behaves? What do you mean when you say "Firefox hangs"? In addition, could you please try to access https://kuix.de:9451 ?
By Firefox hanging I mean that after instructing Firefox to accept the suspect certificate, there is a continuously rotating error in the tab. And there is a blank white page displayed. What should happen is that Firefox should display the Cisco 5505 VPN hardware box's login page where I can provide a user ID and password to establish a VPN connection.
Can you try to add a "permanent exception", and when it hangs, restart firefox, then try to access the page again (which shouldn't require an override this time). Does it hang after a restart, too?
Firefox nightly build still hangs, even after a restart. Here are the steps I executed: 1) Tried to connect to the Cisco 5505 VPN box to login 2) Got Firefox message "This Connection is Untrusted" 3) Clicked "I Understand the Risks" 4) Clicked "Add Exception" 5) Got the Firefox window "Certificate Status" 6) Checked "Permanently store this exception" 7) Clicked "Confirm Security Exception" 8) Firefox hangs with a blank white page 9) Restarted Firefox and it still hangs, this time with my default home page displayed (via a local file) Note that for years I have instructed Firefox to "Permanently store this exception", yet for years Firefox always goes through the same certificate dance detailed above.
It's strange that it hangs after you restart Firefox, even more so, that it hangs with your local file home page. It sounds like Firefox wasn't restarted correctly, maybe you were able to close the firefox window, but it's still running in the background, in a semi-stuck state? Are you on Windows? Are you able to terminate the firefox process prior to starting Firefox again? If that doesn't help, and if Firefox hangs on your non https local file homepage, then something else is wrong (very likely unrelated to this bug). In addition, you seem to report that adding a permanent exception doesn't help, but you had to add an exception every time you restarted Firefox in the past? For the same server you're visiting? That's strange.
I don't think I was clear. My default home page loaded just fine with no hang. It was when I tried to access my VPN box login page after restarting Firefox that it hung, but continued to display my default home page. I just wanted to point out that it did not blank-out the page as part of this hang. Note that the login works fine, and has worked fine for years, with Firefox 35 and earlier. The only oddity is that it never seems to permanently store the certificate exception.
(In reply to kaka5mail from comment #11) > > sorry,this CA for the company internal site, I may not private offer it . kaka5mail: Are you able to help us? Can you please test a firefox from http://nightly.mozilla.org ? Are you able to add an override and connect to your internal site, and please tell us if it works or not? Thanks
I just tested the nightly build, and I noticed: My test case from https://kuix.de:9451 is no longer reporting the intended error, firefox no longer reports ca_cert_invalid, but invalid signature algorithm. That's because the cert on my test site uses SHA-1, which the nightly build now appears to reject by default. In order to make the test case work as intended, I will have to update the site with a cert that uses SHA-256. I hope I can get that done soon.
I am running Firefox on a Mac OS X 10.8.5 system.
Dick, I just looked at your screenshots. I notice that your problem may not be related to this bug at all. This bug is specifically about not being able to override error code sec_error_ca_cert_invalid, but your screenshots show a different error message. I'm confused, because that error should have been overridable with Firefox 36. It sounds like your bug is something unrelated. Yes, we should try to investigate and fix, but it might be a separate issue. Maybe we should file a separate, new bug against Firefox 36 for your specific issue.
Ok, that is why I originally reported that my problem *may* be the same as the one opened in this bug. I think that there is some commonality between the certificate errors reported in this bug, even though that relationship may not be exact. It can't be coincidence that all these certificate problems started with Firefox 36. If we do open a new bug, is there a way to transfer all the effort made by the contributors for my problem to a new bug so that we don't have to start over documenting my problem? Can you help with that? Thanks.
(In reply to Kai Engert (:kaie) from comment #31) > > kaka5mail: Are you able to help us? Can you please test a firefox from > http://nightly.mozilla.org ? Are you able to add an override and connect to > your internal site, and please tell us if it works or not? Thanks Just tested with Nightly on the website with the certificate mentioned on bug 1140090. It's working for me. I was able to add the exception and visit the website without issue. It's working with accepting the untrusted certification for the current session only. It's also working when I permanently add the certificate. Regards.
keeler - If this is ready, I'd prefer to take the change in Beta 6 (gtb Monday). Can you please request uplift by then if you'd had the confirmation you need that the feature is good?
I've updated the test case at https://kuix.de:9451 Nightly reports, again, sec_error_ca_cert_invalid, and nightly is able to override it, so it appears to me, on nightly this bug is fixed for the desired scenario.
Julien, did you experience sec_error_ca_cert_invalid, or another error message? Are you able to confirm that the issue is fixed for you using a nightly build?
Created attachment 8577505 [details] [diff] [review] patch for beta Approval Request Comment [Feature/regressing bug #]: mozilla::pkix (bug 991177, sort-of) [User impact if declined]: some sites will be inaccessible for some users [Describe test coverage new/current, TreeHerder]: has tests [Risks and why]: low [String/UUID change made/needed]: none Had to rebase for beta, but otherwise this is ready to go.
Comment on attachment 8576214 [details] [diff] [review] 1138332-ca_cert_invalid-override.diff Approval Request Comment see comment 40
(In reply to Dick Riegner from comment #35) > If we do open a new bug, is there a way to transfer all the effort made by > the contributors for my problem to a new bug so that we don't have to start > over documenting my problem? Can you help with that? I've filed bug 1143217, let's continue the discussion of your issue over there.
Comment on attachment 8577505 [details] [diff] [review] patch for beta The in product code change associated with this patch is 3 lines. The fix has been verified by an affected user. Let's get this into Beta 6. Beta+
Comment on attachment 8576214 [details] [diff] [review] 1138332-ca_cert_invalid-override.diff Aurora+
(In reply to Kai Engert (:kaie) from comment #39) > Julien, did you experience sec_error_ca_cert_invalid, or another error > message? Are you able to confirm that the issue is fixed for you using a > nightly build? I'm getting now a sec_error_bad_der
(In reply to Julien from comment #45) > > I'm getting now a sec_error_bad_der Thanks. Your issue is different from this bug report. I've recently heard about a similar bug where a sec_error_bad_der had been reported. In your case, most like, the certificate contained malformed data, which doesn't conform to the x509 asn.1 encoding specifications. In the example that I had seen, the certificate had contained an empty subject alt name extension. Try to save the certificate that your server sends to you (e.g. using openssl s_client -showcerts -connect host:port), and save the cert data to a file.pem. Then convert it to binary (e.g. using openssl x509 -in yourfile.pem -out yourfile.der). Then feed the yourfile.der to the dumpasn1 utility. It seems that Firefox 36 is less tolerant for bad encodings of certificates (bad encodings have been attack vectors in the past to attempt exploits in the browser). So, if you're getting sec_error_bad_der, then you should convince your server admin to install a better, more correct certificate. Do you know who produced the server certificate that results in sec_error_bad_der? Is it a certificate embedded in a device, or is it a software server? If you are able to provide us with a copy of the certificate your server uses, I can have a look at the certificate for you. Please file a separate bug report and cc me (or just send me the bad certificate by email). Thanks.
I filed bug 1143085 to handle the subject alt name issue.
(In reply to Kai Engert (:kaie) from comment #31) > (In reply to kaka5mail from comment #11) > > > > sorry,this CA for the company internal site, I may not private offer it . > > > kaka5mail: Are you able to help us? Can you please test a firefox from > http://nightly.mozilla.org ? Are you able to add an override and connect to > your internal site, and please tell us if it works or not? Thanks Yes, I try use firefox-39.0a1.en-US.mac.dmg , it works fine. Thank u. Hope it release soon.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #47) > I filed bug 1143085 to handle the subject alt name issue. I think my problem is related this one as in my server certificate i have this entry : X509v3 Subject Alternative Name: <EMPTY> and i seen this entry Netscape Comment: TinyCA Generated Certificate