User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141011015303 Steps to reproduce: https://192.168.1.1 Actual results: Secure Connection Failed An error occurred during a connection to 10.0.8.1:8888. The key does not support the requested operation. (Error code: sec_error_invalid_key) The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem. Expected results: I should be allowed to use my own self-signed certificate to access my router! Apparently I'm supposed to use Chrome or Safari now?
Same behavior on 10.0.8.1, 192.168.1.1, etc.
maybe we could allow to override more things if the target is in an IPv4 private network ? Reporter: What kind of router do you use ? A self signed certificate is not the problem. You get errors like this only if there is something else wrong with the certificate.
Hi, could you check Bug 1084606 Comment 4 (or at least Comment 3), and see if you get similar results to the reporter there? I suspect that this is a duplicate. Thanks.
on linksys switches https contain self-signed certs (and that is not possible to change) , that not accepted on the new version of firefox & seamonkey ... so must have old-style add exceptions ... quite URGENT and BLOCKING option, as not possible of local network configurations ... get back to older versions is more security hole, that have own exception definitions ...
also new zyxel swithes affected to that unchangeable self-signed certs ...
(In reply to DaLiV from comment #5) > also new zyxel swithes affected to that unchangeable self-signed certs ... Can you please provide examples of the public portions of the affected certs?
Modulus (512 bits): b4 00 b0 ae 73 c0 e2 2d d5 3e a1 bb be 6b 64 d3 fe a9 fa 77 af 49 8d 03 51 26 4f ed b3 bd 0e 8b ee 8d c3 2c ee 5e 58 af 38 d9 85 60 90 8b 7f b5 c1 17 a3 ad 0a 99 86 83 e6 36 be d1 19 2e bb 7f
(In reply to DaLiV from comment #7) > Modulus (512 bits): > b4 00 b0 ae 73 c0 e2 2d d5 3e a1 bb be 6b 64 d3 > fe a9 fa 77 af 49 8d 03 51 26 4f ed b3 bd 0e 8b > ee 8d c3 2c ee 5e 58 af 38 d9 85 60 90 8b 7f b5 > c1 17 a3 ad 0a 99 86 83 e6 36 be d1 19 2e bb 7f That's not enough to go on; can you provide the full public key info from the cert dialog when using an older version to connect to the site, please?
full public cert ... -----BEGIN CERTIFICATE----- MIIBFjCBwaADAgECAgECMA0GCSqGSIb3DQEBBQUAMBQxEjAQBgNVBAMTCUdTMTkx MC00ODAeFw0xMDAxMDEwMDAwMDBaFw0yOTEyMzEwMDAwMDBaMBQxEjAQBgNVBAMT CUdTMTkxMC00ODBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC0ALCuc8DiLdU+obu+ a2TT/qn6d69JjQNRJk/ts70Oi+6NwyzuXlivONmFYJCLf7XBF6OtCpmGg+Y2vtEZ Lrt/AgMBAAEwDQYJKoZIhvcNAQEFBQADQQCCeKJKzzGT24JiHmpaX/KGzq1TJkff Lf1A9ayPApkzlBSIHd8NqGji/ER+RcW8UKyws30T5EqvSdBKYMg/QsFT -----END CERTIFICATE-----
dkeeler, can you help diagnose what's going on here? Thanks!
(IMHO) size of cert is 512 ... new security enforcements require 1024 ... exceptions written in seamonkey/firefox for not-met-requirements certs is ignored ...
Looks like the same as bug 1084606 (i.e. 512 bits is too small to be considered secure for an RSA key). We're still working on allowing users who need to connect to devices with this problem an option to continue while still protecting the majority of our users. See bug 1084606 comment 17.
(This bug has been marked as a duplicate, so clearing needinfo request).