Hi As soon as I upgraded from FF32 to FF33, I got this error (translated from french) Secure connection failure An error happened during connection to www.xxx.yyy.zzz. The key does not manage the requested operation. (Error code : sec_error_invalid_key)... Until this error I dayly used these web sites (they are https GUIs of routers) who use self-signed certificates for which I have security exceptions stored for years. I checked the certs with a FF32 and the revocation date is 2020). Unfortunately I can't see a way to workaround but reverting back to FF32. Maybe this is related to this bug "mozilla::pkix, cannot override sec_error..." : https://bugzilla.mozilla.org/show_bug.cgi?id=1042889

Did you try to test with a fresh profile? https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles If it's bug 1042889, it should be fixed in the next Nightly, so you can install it and test it tomorrow.

Yes I tested with a new fresh profile: same behaviour.

This might be due to the key size checking added in Bug 360126. Could you try using Firefox 34 or above? If it is due to the key size, you should see the error code MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE. (Yes, the re-use of SEC_ERROR_INVALID_KEY is confusing, I probably should have at least nominated the patch to update the error code for Firefox 33 as well.)

f0rhum, it would be helpful to have a copy of the certificates the device you're trying to connect to sends. Can you post the output of the following command: openssl s_client -connect host:port -showcerts < /dev/null Thanks.

Not a blocker.

openssl s_client -connect 192.168.22.253:443 -showcerts < /dev/null CONNECTED(00000003) 139944457442976:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 305 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- NewMedia-NET GmbH Identity: NewMedia-NET GmbH Checked by: NewMedia-NET GmbH Expires on: 03/08/2020 Subject name C (Pays): DE ST (État): Saxon L (Localité): Dresden O (Organisation): NewMedia-NET GmbH OU (Unité d'organisation): DD-WRT CN (Nom courant): NewMedia-NET GmbH EMAIL (Adresse électronique): info@dd-wrt.com Issuer name C (Pays): DE ST (État): Saxon L (Localité): Dresden O (Organisation): NewMedia-NET GmbH OU (Unité d'organisation): DD-WRT CN (Nom courant): NewMedia-NET GmbH EMAIL (Adresse électronique): info@dd-wrt.com Issued certificate Version: 1 serial number: 00 89 6F 5D 48 6E DC 19 B9 Non valid before: 2010-08-06 Non valid after: 2020-08-03 Certificate checksum SHA1: 49 CC 60 20 D5 9B 7A 5D AE AA 11 DD 95 16 03 F1 EF 53 69 1F MD5: 68 F9 6C 7E D6 2E 81 45 56 18 EA 7C AC 9A E2 9D Pub key info Key algorithm: RSA Key parameters: 05 00 Key size: 512 Key SHA1 checksum: 9B 8E D0 85 10 34 D8 AC C7 53 75 8A 47 A4 A0 D8 8D C9 E1 78 Public Key: 30 48 02 41 00 BE 93 73 40 42 48 67 FA 46 0F E6 6F 70 A1 23 39 EA C2 22 D0 07 63 B9 4F 0F 46 03 CE BB 1F AB E4 80 64 E1 57 5D 34 D6 AF 90 71 54 94 CB 82 A0 6B 19 F9 F8 04 A7 AE 04 5F E7 FF 4B E6 6C 17 3B 17 02 03 01 00 01 Signature Signature algorithm: SHA+ with RSA Signature parameters: 05 00 Signature: BC B7 B7 B5 9D 28 40 2A E2 CA C6 9E 4F 19 37 60 06 3F 03 F8 DD 2E 51 E9 AE 6F FD 7A 35 CA D7 A5 9F 38 06 5C F0 33 07 09 D6 51 42 E1 E8 2D 6E E6 B4 76 96 C8 4F 35 7F 97 7E D4 CF FB 2D 77 66 24

With FF34.0b1 : "Error happend when connecting to 192.168.22.253. Server shew a certificate whose key size is too little to establish a secure connection. (Error code: mozilla_pkix_error_inadequate_key_size)." Will we have an warning+override for this?

Same with 34.0 (update channel: beta)

I'm also looking for an override for this. I've had exceptions for all my servers forever. Now when I attempt to access a page I get "Secure Connection failed (Error code: sec_error_invalid_key)". When I attempt to re-add my exception through Preferences->Advanced->Certificates->View Certificates->Add Exception I get "Unable to obtain identification status for the given site". Re-importing the certificate from a file creates a line with a wildcard for server, but has no effect on my ability to access the site. In the meantime, I'm using Chrome which does not currently have this problem.

I confirm that this happens on 33 while trying to connect to a Tomato router.

Tomato by default generates 512 bit RSA key. I generated 2048 bit key manually and the problem is over.

The HIGHLY INTELLIGENT developers at Mozilla et. al. SHOULD refrain for arbitrarily imposing such restrictions on it's users. Instead Mozilla et. al. SHOULD notify users SEVERAL VERSION in advance - at least 2 - when security that they're using is going to become invalid. That way anyone using "embedded" where performance is an issue SHOULD be able to address their security issues IN A TIMELY MANNER rather than on a Monday after everyone upgraded their Firefox browser. IE When I log into my Linksys with DD-WRT for version of Firefox 31 and 32, I SHOULD have been notified that my RSA KEY LENGTH was too small and would be unsupported in future version, and possible offered some Ron Jeremy pills to compensate for my inadequate length. Decisions like this are why I get questions from management such as: "Why aren't we using Chrome if it works?" While I understand the technical reason for imposing these limits - at least I like to think I do - I do not agree in the manner in which Mozilla informed me of such limits. Some security is better than none. This router, and my home router - Linksys WRT-54G r2, which is running Open-WRT - have https only access. At some point the limits will be raised that force me to either A) Buy a new router because the SoC in my current router isn't fast enough for the imposed limits or B) Download a new browser because it supports my poor security choices. The appropriate method to solve this is to notify the users of the deprecation of their security configuration at least version in advance - probably 2 with Firefox's update schedule. Increase the DEFAULT limits in the next version or two. Allow the choices to be overridden by the user. NIST has increased the limits from 256 to 2048 in the span of 5 years. Chances are, these limits will be raised again. Stop breaking networks with use your product. Inform the user, change the default, allow the limits to be manually lowered.

Same problem with WRT54GL with the firmware linksys 04/08/2013 Ver.4.30.16 (Build 6). I am stuck...

I wrote a tutorial describing how to generate a longer (than 512 bit) key on Tomato routers: http://stackoverflow.com/a/26520093/2178047 Maybe it will be helpful to some.

I posed the question of what to do about this bug on #security over IRC: > 1:16:00 PM - keeler: Cykesiopka: I think that might be fixed by the plan in > bug 1042889 (i.e. heuristically determine if a certificate isn't in the "real" > pki and allow overrides in more cases if so)

With the latest FF34beta windowsXP, I now have no more specific error message on error: instead I get some generic message: "Connection was broken (La connexion a été interrompue) The connection to 192.168.xx.xx:8080 was broken when loading page The site may be temporarily unvailable or overloaded. Retry later ; If you can't browse any web site, check network connection of your computer ; If your pc/netwrk is firewall/proxy protected, make sure Firefox is allowed to Web" from linux: openssl s_client -connect 192.168.xx.xx:8080 -showcerts < /dev/null CONNECTED(00000003) 140465755293344:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 305 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE I posted attachments in the FF34 thread : https://bugzilla.mozilla.org/show_bug.cgi?id=1089179

After reading s_client man, "-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1, -no_tls1_1, -no_tls1_2 these options disable the use of certain SSL or TLS protocols. By default the initial handshake uses a method which should be compatible with all servers and permit them to use SSL v3, SSL v2 or TLS as appropriate. Unfortunately there are still ancient and broken servers in use which cannot handle this technique and will fail to connect. Some servers only work if TLS is turned off." I tried and this time got info: openssl s_client -connect 192.168.xx.xx:8080 -showcerts -no_tls1 < /dev/null CONNECTED(00000003) depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify error:num=18:self signed certificate verify return:1 depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify return:1 --- Certificate chain 0 s:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com i:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com -----BEGIN CERTIFICATE----- MIIDrjCCApYCCQC7QY1XOk0Y6TANBgkqhkiG9w0BAQUFADCBmDELMAkGA1UEBhMC REUxDjAMBgNVBAgTBVNheG9uMRAwDgYDVQQHEwdEcmVzZGVuMRowGAYDVQQKExFO ZXdNZWRpYS1ORVQgR21iSDEPMA0GA1UECxMGREQtV1JUMRowGAYDVQQDExFOZXdN ZWRpYS1ORVQgR21iSDEeMBwGCSqGSIb3DQEJARYPaW5mb0BkZC13cnQuY29tMB4X DTE0MTAyNzAwMTExMFoXDTI0MTAyNDAwMTExMFowgZgxCzAJBgNVBAYTAkRFMQ4w DAYDVQQIEwVTYXhvbjEQMA4GA1UEBxMHRHJlc2RlbjEaMBgGA1UEChMRTmV3TWVk aWEtTkVUIEdtYkgxDzANBgNVBAsTBkRELVdSVDEaMBgGA1UEAxMRTmV3TWVkaWEt TkVUIEdtYkgxHjAcBgkqhkiG9w0BCQEWD2luZm9AZGQtd3J0LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMUU9GNFU4pN7Yif8osjEGQQiJMh5T9g wFzswoeztwxbJSETf/idydF4J0ZMTFRJfE/KARnsgawv/Rp/NR6TTOLXtMXxkM+W S6EluooEgyIkI+2VE7TfgC8WAs5BzVJEiJxv2w0YKkJfmws2UctL1BtNKtJjRiby qaBR/GlzuYrVKOgsaHCmq20SoUf9GWi8oIu7a3Qi/ZkKuRZRA0b9urGwHMdXyXHZ 2L0NQhBYZAYRyXeOyaVuKrv4kPlrnGyaW8x7TRZtNNLsw0QpUoD/IzSAxCuciIlm 8GstzjSX6OH98Xhv5cTIHQF86JIjcGYMpKFuEzFKS4LVG9gqKmVsu3ECAwEAATAN BgkqhkiG9w0BAQUFAAOCAQEAmnzZvPhGBxWTadWqRuZZy2bBdkg9/nNZGyGqSbPS p8Ol2ceKCtYFHA8t08cDFjb90HPswbEvkV/jRlZoTwnyxPmWnJg0oJ+oaNVCx+g0 Ngk9f76pXRBurEi0A9ANchacyG3F8W3I5jxttahH5qCxkYvy7mf2DLugAcS/N4kn fIDTMhoqj0iaA+LCIOmySP5dhm8GkD7Ms3ji1xYoltopK2ONnZm84226EZEa+UKs 1ZNPK/o8h6SWNjDSQFk1xjveVroIimgtpqFFCPmDd2Ye6toG7ZEwRwWv2wi0N4QJ iUbmS2bthPJlx+WC5YZNKEUTONLyP/MfhFXKwulkUyvL2g== -----END CERTIFICATE----- --- Server certificate subject=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com issuer=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com --- No client certificate CA names sent --- SSL handshake has read 1124 bytes and written 478 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : DES-CBC3-SHA Session-ID: 04000000EBDDC6A29A0CB93C27DCA970EF08B1F1D99664D758BAF3CFBA70BC95 Session-ID-ctx: Master-Key: 4AE6837D7F3A482022525A5C43AA77E04F3A21C1F401ED944C481135BD921BCC9D83FA8FA2EE217A6E1A513C617AA81E Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1414522797 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- DONE Hope this helps

PS: After I reached to upgrade 2 out of all my routers to a recent firmware, I could also have a try with FF33 on a linux machine: With new cert/firmware FF33 can connect. Although, FF34+Aurora35 in Windows fail to connect to these new certs and only issue a generic error message with no code.

(In reply to f0rhum from comment #20) > PS: After I reached to upgrade 2 out of all my routers to a recent firmware, > I could also have a try with FF33 on a linux machine: > With new cert/firmware FF33 can connect. > Although, FF34+Aurora35 in Windows fail to connect to these new certs and > only issue a generic error message with no code. Based on Comment 19 and 20, this might be related to Bug 1076983 disabling SSL3 to mitigate POODLE. f0rhum: Let's move this to Bug 1089179 since it's a separate issue.

Well OK, so it can be set as a duplicate of Bug 1089179 ? Should I set it myself? Thank you for support Cykesiopka

(In reply to f0rhum from comment #22) > Well OK, so it can be set as a duplicate of Bug 1089179 ? Should I set it > myself? > Thank you for support Cykesiopka No problem. I don't think this bug is a duplicate of Bug 1089179 (or Bug 1090765).

Developers, this isn't the first time Firefox has locked us out of systems with a certificate that did not meet new security guidelines. I totally understand that this is a good security measure for end users but Mozilla needs to make certain that developers, engineers, IT support, etc. have an easy way to override this. Just as Ben says above I have some older systems that are only accessible internally with self-signed certificates on them that we can no not access. There should be an easy way for us to put exceptions in for this. There is no need for us to regenerate the certificates as these systems are not high security but are used regularly. I guess I have to install Chrome, which I've been trying to avoid.

(In reply to Slim Shady from comment #12) > The HIGHLY INTELLIGENT developers at Mozilla et. al. SHOULD refrain for > arbitrarily imposing such restrictions on it's users. Instead Mozilla et. > al. SHOULD notify users SEVERAL VERSION in advance - at least 2 - when > security that they're using is going to become invalid. > > That way anyone using "embedded" where performance is an issue SHOULD be > able to address their security issues IN A TIMELY MANNER rather than on a > Monday after everyone upgraded their Firefox browser. > > IE When I log into my Linksys with DD-WRT for version of Firefox 31 and 32, > I SHOULD have been notified that my RSA KEY LENGTH was too small and would > be unsupported in future version, and possible offered some Ron Jeremy pills > to compensate for my inadequate length. > > Decisions like this are why I get questions from management such as: "Why > aren't we using Chrome if it works?" > > While I understand the technical reason for imposing these limits - at least > I like to think I do - I do not agree in the manner in which Mozilla > informed me of such limits. > > Some security is better than none. This router, and my home router - > Linksys WRT-54G r2, which is running Open-WRT - have https only access. At > some point the limits will be raised that force me to either A) Buy a new > router because the SoC in my current router isn't fast enough for the > imposed limits or B) Download a new browser because it supports my poor > security choices. > > The appropriate method to solve this is to notify the users of the > deprecation of their security configuration at least version in advance - > probably 2 with Firefox's update schedule. Increase the DEFAULT limits in > the next version or two. Allow the choices to be overridden by the user. > > NIST has increased the limits from 256 to 2048 in the span of 5 years. > Chances are, these limits will be raised again. Stop breaking networks with > use your product. Inform the user, change the default, allow the limits to > be manually lowered. Please be mindful of the Bugzilla Etiquette this is not a forum but a place for tracking bugs and while we understand your frustration there is no need to ridicule https://bugzilla.mozilla.org/page.cgi?id=etiquette.html We are looking into this.

Benjamin Kerensa: I figured this bug was a double header, including issues relating to: "Devs not using usage statistics when implementing potentially damaging changes". Could you please report a bug to that effect if this is not the place to make such observations pertaining to this bug. I'm sure there were many usage statistics sent to Mozilla that could have been narrowed down to keys of a certain size, which would then be blocked by this change. Sure it would have seemed to be a trivial number of servers. Oddly enough, though, I would expect to see that of this trivial ratio of request, they are all of the same nature. Private network gateways. I'm certain there must have been enough information to tell the devs, or the reviewers, that the biggest impact of this change was to people who were accessing network infrastructure - which generally isn't updated unless it needs to be. This infrastructure might be low powered devices not capable of performing optimally with larger keys, or infrastructure which is secured better than default no-key settings. The exact reasoning into implementing such a change is the exact same reasoning that is used why NOT to make such a change. So obviously there was some thought process regarding computer power vs key length. Just single minded focused attention and lack of vision to details. A simple question could have easily been asked and answered: "How many people will this affect, and how?" Oh look, everyone's SoC router is going to be inaccessible via https, and completely inaccessible if http is disabled. Every aspect of this issue is ridiculous. Have you ever seen a router which did not allow the disabling of http and enabling of https which has been released in the past 10 years. What study was done to say the hardware being affected by this should easily handle the change of a key 4 times longer. I'm providing a solution to avoid these types of bugs. I am appalled at the oversight and the detrimental effect. I find making people feel stupid for doing stupid things helps teach them to think twice: IE Is this stupid? Should I just turn off usage statistics and stop using nightly because it's pointless and disregarded anyway? Is that what you're telling me? No, Ben, that would be ridiculous and I would expect to be ridiculed for not helping the community. Ridicule IS required when people do ridiculous things. This is Bananas. B-A-N-A-N-A-S.

After talking with :keeler, it looks like Bug 1091778 won't be uplifted. So in the mean time, we'll just make this error overridable. I'll try and get the change uplifted to Firefox 34 and 35 if I can as well.

Just asking for feedback for now - In particular, I'm not sure if it's necessary to test chains with inadequately sized intermediates and roots as well. https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=376a3d5b7d89

Comment on attachment 8520471 [details] [diff] [review] bug1084606_v0.patch Review of attachment 8520471 [details] [diff] [review]: ----------------------------------------------------------------- Looks great, but I think you're going to have to modify nsUsageArrayHelper as well: http://hg.mozilla.org/mozilla-central/annotate/a926116946f8/security/manager/ssl/src/nsUsageArrayHelper.cpp#l145 Also, for any branch where bug 1057497 hasn't landed, you'll have to modify dom/browser-element/BrowserElementChildPreload.js similarly. I think we don't actually need to test intermediates/roots because we already have xpcshell tests that ensure the correct error is returned in those cases, right? This is basically just an integration test that ensures that if that error is encountered, it'll be overridable.

(In reply to David Keeler (:keeler) [use needinfo?] from comment #32) > but I think you're going to have to modify nsUsageArrayHelper > as well: > http://hg.mozilla.org/mozilla-central/annotate/a926116946f8/security/manager/ > ssl/src/nsUsageArrayHelper.cpp#l145 The MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE case is already handled there (unless you meant I should change what should be returned for this case?) > I think we don't actually need to test intermediates/roots because we > already have xpcshell tests that ensure the correct error is returned in > those cases, right? This is basically just an integration test that ensures > that if that error is encountered, it'll be overridable. Yes, we have xpcshell tests to ensure this. Thanks for the confirmation!

(In reply to Cykesiopka from comment #33) > (In reply to David Keeler (:keeler) [use needinfo?] from comment #32) > > but I think you're going to have to modify nsUsageArrayHelper > > as well: > > http://hg.mozilla.org/mozilla-central/annotate/a926116946f8/security/manager/ > > ssl/src/nsUsageArrayHelper.cpp#l145 > > The MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE case is already handled there Right - I don't know what I was talking about, there.

Thanks for the review. https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=d8b0a55845b4

Approval Request Comment [Feature/regressing bug #]: Bug 360126, which added key size checking, but didn't allow overrides [User impact if declined]: Users with old/broken equipment that can't or won't be updated will continue to be unable to access them until Firefox 36 [Describe test coverage new/current, TBPL]: New test case to existing xpcshell test [Risks and why]: Low - typical patch to allow an override [String/UUID change made/needed]: None (I'm aware this is very late for beta, but I did say I would at least try). Aurora 35: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=c454b841a289 Beta 34: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=00d0819f269b (I assume win64 doesn't work in 34 at all)

Comment on attachment 8524104 [details] [diff] [review] bug1084606_aurora35_beta34_v1.patch It's late but we've caused pain with this type of sec issue that requires an override recently and this patch looks simple enough that it's worth the risk. Let's take this in beta10. Beta+ Aurora+

https://hg.mozilla.org/releases/mozilla-aurora/rev/c55df95bdf6d https://hg.mozilla.org/releases/mozilla-beta/rev/3030e4f0d729

f0rhum@free.fr, can you confirm this fixes your issues with the latest 34 Beta 10 build from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b10-candidates/build1/? Note that the Windows build should be available ~1-2 hours from now.

Thanks! That fixed my issues.

Florin, I have a mitigated answer (FF34b10): With old routers/firmware like this one: openssl s_client -connect spiq:8800 -showcerts < /dev/null CONNECTED(00000003) depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify error:num=18:self signed certificate verify return:1 depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify return:1 --- Certificate chain 0 s:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com i:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com -----BEGIN CERTIFICATE----- MIICJDCCAc4CCQCvlxpYBqKdzDANBgkqhkiG9w0BAQUFADCBmDELMAkGA1UEBhMC REUxDjAMBgNVBAgTBVNheG9uMRAwDgYDVQQHEwdEcmVzZGVuMRowGAYDVQQKExFO ZXdNZWRpYS1ORVQgR21iSDEPMA0GA1UECxMGREQtV1JUMRowGAYDVQQDExFOZXdN ZWRpYS1ORVQgR21iSDEeMBwGCSqGSIb3DQEJARYPaW5mb0BkZC13cnQuY29tMB4X DTA5MDcyMDIzNTg1NloXDTE5MDcxODIzNTg1NlowgZgxCzAJBgNVBAYTAkRFMQ4w DAYDVQQIEwVTYXhvbjEQMA4GA1UEBxMHRHJlc2RlbjEaMBgGA1UEChMRTmV3TWVk aWEtTkVUIEdtYkgxDzANBgNVBAsTBkRELVdSVDEaMBgGA1UEAxMRTmV3TWVkaWEt TkVUIEdtYkgxHjAcBgkqhkiG9w0BCQEWD2luZm9AZGQtd3J0LmNvbTBcMA0GCSqG SIb3DQEBAQUAA0sAMEgCQQC5S+wsJXpd3JomYK2N9sfX5p4IvFBJ+8KWd/EAEf0m Mxlb/AshJpoP+taZvbRWGTEwDBtH06EEq8XnG8nJggihAgMBAAEwDQYJKoZIhvcN AQEFBQADQQCj7weXosMmgwI60YC8NYSeLyzUrhXbxJ9d04t1fqIDQRn2H9Ru9oid zFDSPnx/HeyxY2PvBBCtmmvY6a6PUQ+H -----END CERTIFICATE----- --- Server certificate subject=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com issuer=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com --- No client certificate CA names sent --- SSL handshake has read 730 bytes and written 453 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 512 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : DES-CBC3-SHA Session-ID: 04000000A7E8E7FC791055C851D2025C879A0E869E81524A7D274C8038F17A7A Session-ID-ctx: Master-Key: 69F5EE5ED9466F253613AD216EB55C1D6969ECA2DDFCD077118D83FFB6CFC2D11CE3D5B0741DAA936617BACEAC9719AF Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1416567287 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- DONE I get the message: ssl_error_no_cypher_overlap Only with SSL Control Version plugin set to SSLv3 I can now connect fine (both with the previously stored exception and once deleted I can create a new one after a while). Cool job, even if I'd rather like I don't need a plugin. With a more recent router/firmware, no way to connect : openssl s_client -connect spiq:8098 -showcerts < /dev/null CONNECTED(00000003) 139842649704096:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 305 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- openssl s_client -connect spiq:8098 -showcerts -no_tls1 < /dev/null CONNECTED(00000003) depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify error:num=18:self signed certificate verify return:1 depth=0 C = DE, ST = Saxon, L = Dresden, O = NewMedia-NET GmbH, OU = DD-WRT, CN = NewMedia-NET GmbH, emailAddress = info@dd-wrt.com verify return:1 --- Certificate chain 0 s:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com i:/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com -----BEGIN CERTIFICATE----- MIICJDCCAc4CCQCJb11IbtwZuTANBgkqhkiG9w0BAQUFADCBmDELMAkGA1UEBhMC REUxDjAMBgNVBAgTBVNheG9uMRAwDgYDVQQHEwdEcmVzZGVuMRowGAYDVQQKExFO ZXdNZWRpYS1ORVQgR21iSDEPMA0GA1UECxMGREQtV1JUMRowGAYDVQQDExFOZXdN ZWRpYS1ORVQgR21iSDEeMBwGCSqGSIb3DQEJARYPaW5mb0BkZC13cnQuY29tMB4X DTEwMDgwNjIyNDkyN1oXDTIwMDgwMzIyNDkyN1owgZgxCzAJBgNVBAYTAkRFMQ4w DAYDVQQIEwVTYXhvbjEQMA4GA1UEBxMHRHJlc2RlbjEaMBgGA1UEChMRTmV3TWVk aWEtTkVUIEdtYkgxDzANBgNVBAsTBkRELVdSVDEaMBgGA1UEAxMRTmV3TWVkaWEt TkVUIEdtYkgxHjAcBgkqhkiG9w0BCQEWD2luZm9AZGQtd3J0LmNvbTBcMA0GCSqG SIb3DQEBAQUAA0sAMEgCQQC+k3NAQkhn+kYP5m9woSM56sIi0AdjuU8PRgPOux+r 5IBk4VddNNavkHFUlMuCoGsZ+fgEp64EX+f/S+ZsFzsXAgMBAAEwDQYJKoZIhvcN AQEFBQADQQC8t7e1nShAKuLKxp5PGTdgBj8D+N0uUemub/16NcrXpZ84BlzwMwcJ 1lFC4egtbua0dpbITzV/l37Uz/std2Yk -----END CERTIFICATE----- --- Server certificate subject=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com issuer=/C=DE/ST=Saxon/L=Dresden/O=NewMedia-NET GmbH/OU=DD-WRT/CN=NewMedia-NET GmbH/emailAddress=info@dd-wrt.com --- No client certificate CA names sent --- SSL handshake has read 730 bytes and written 286 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 512 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : DES-CBC3-SHA Session-ID: 01000000D8D59C43F2230B8F52A38E838950164A13D0043E76BCC5380226B7B4 Session-ID-ctx: Master-Key: A0E645690ED8B485F628089BF6E3D2854715BA5ACD9A64AB7481418E2459C0FA331E9E3AC3EC2AB59626792757A73543 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1416568308 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- DONE

Note that there are MANY devices out there that cannot update their certificates and are stuck in the past. Notably, I'm now locked out of all my Dell PowerEdge C6100 IPMI consoles until I configure a Windows VM, since they don't play nice with Chrome for different reasons. So, there are plenty of valid use cases for allowing the user to override this I'm using firefox 34.0~b7+build1-0ubuntu0.12.04.1. (And if you discover a way to change the SSL cert on the BMC of a Dell PowerEdge C-series IPMI controller, please let me know.)

(In reply to athompso from comment #44) > Note that there are MANY devices out there that cannot update their > certificates and are stuck in the past. Notably, I'm now locked out of all > my Dell PowerEdge C6100 IPMI consoles until I configure a Windows VM, since > they don't play nice with Chrome for different reasons. > So, there are plenty of valid use cases for allowing the user to override > this > I'm using firefox 34.0~b7+build1-0ubuntu0.12.04.1. > (And if you discover a way to change the SSL cert on the BMC of a Dell > PowerEdge C-series IPMI controller, please let me know.) The override has already been added for Firefox 34 and above. Note that it landed in Beta *10*, so you'll need to update to be able to add an override.

Oops. Confirming that yes, beta 11 does let me back in.