Description of problem: Upgrading nss-3.23.0-1.2.fc24 to nss-3.27.0-1.1.fc24 breaks openldap Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
After installing the said update, it is no longer possible to connect to slapd using TLS. This is very similar to a problem I reported earlier: https://bugzilla.redhat.com/show_bug.cgi?id=1342745. I do not actually intend to use NSS with slapd, instead, I am using OpenSSL-generated certificates stored as PEM files. However, the broken NSS library seems to prevent access to these.
I would be good to get help with debugging the cause of the breakage from openldap developers. In particular, which functionality that openldap is using, breaks after the update?
Slapd rejects all connections from clients using SSL/TLS.
$ ldapsearch -H ldaps://localhost:3636 ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: TLS error -12227:SSL peer was unable to negotiate an acceptable set of security parameters. slapd returns: TLS: error: accept - force handshake failure: errno 107 - moznss error -8186 TLS: can't accept: TLS error -8186:security library: invalid algorithm.. 57ff8167 connection_read(12): TLS accept failure error=-1 id=1004, closing That's the issue, I presume. I guess it's some change in supported ciphers that introduced this - openldap has those hardcoded due to OpenSSL-like cipherstrings parsing. I'll try to sync them. Hopefully it helps. FTR: The upstream won't be helpful here as it is an NSS-related stuff.
Is this possibly about an old export cipher, then the regression is expected.
I'm seeing exactly the same problem, all LDAP clients on Fedora core broke. I compiled openldap with the default compile settings and its clients work.
I just checked my certificate (it goes back a while). It does use sha1WithRSAEncryption and rsaEncryption with a 4096 bit key. sha1WithRSAEncryption is phased out on jan 1st, 2017. Is that what we are hitting here?
I'd like to emphasize again that I have no NSS certificate data base at all, just plain PEM files generated by OpenSSL. My understanding is (and this is how it is documented and used to work), that slpad falls back to using these in the absence of a NSS data base. But even this use case is broken now. I'd therefore conclude that the breakage cannot be related to any certificate features.
It looks like a problem with the newly introduced RSA-PSS signatures. The TLS connections work fine from OpenSSL but fail if the client is also using NSS library, that is because NSS advertises RSA-PSS signature method and NSS server will use it if available. that being said, I can't reproduce it with selfserv, only with slapd
Thomas, can you try configuring the server with nssdb for key and certificate storage? That should workaround the issue.
(In reply to Hubert Kario from comment #9) > It looks like a problem with the newly introduced RSA-PSS signatures. The > TLS connections work fine from OpenSSL but fail if the client is also using > NSS library, that is because NSS advertises RSA-PSS signature method and NSS > server will use it if available. > > that being said, I can't reproduce it with selfserv, only with slapd No, my clients are all using OpenSSL.
(In reply to Hubert Kario from comment #10) > Thomas, can you try configuring the server with nssdb for key and > certificate storage? That should workaround the issue. This would take a couple of days, as I am rather busy right now.
(In reply to Thomas Köller from comment #11) > (In reply to Hubert Kario from comment #9) > > It looks like a problem with the newly introduced RSA-PSS signatures. The > > TLS connections work fine from OpenSSL but fail if the client is also using > > NSS library, that is because NSS advertises RSA-PSS signature method and NSS > > server will use it if available. > > > > that being said, I can't reproduce it with selfserv, only with slapd > > No, my clients are all using OpenSSL. which version of OpenSSL? are you sure the server never processes a request from a client that uses new NSS before, for example, over loopback? (In reply to Thomas Köller from comment #12) > (In reply to Hubert Kario from comment #10) > > Thomas, can you try configuring the server with nssdb for key and > > certificate storage? That should workaround the issue. > > This would take a couple of days, as I am rather busy right now. If the issue is what Kai and I think it is, fixing it will require a lot of work so a fix likely won't be available quickly either, sorry.
Could we produce a NSS package update, that disables the use of RSA-PSS signatures with SSL/TLS completely, while we work on a smarter implementation?
Any update on a work around?
(In reply to Leendert van Doorn from comment #15) > Any update on a work around? Have you tried the workaround suggested in comment #10?
As suggested in comment #10, I switched to nssdb instead of individual TLS cert files, and it works for me (Fedora 23, openldap-servers-2.4.40-14.fc23.x86_64 and nss-3.27.0-1.1.fc23.x86_64). The problem has been introduced in nss-3.27.0, and downgrading to 3.26.0 makes it work back with TLS certs.
I'm running fc24 and I can only find nss-3.23.0 and the system is very unhappy to downgrade to that.
You can get other builds here : http://koji.fedoraproject.org/koji/packageinfo?packageID=248
Created attachment 1216147 [details] patch attempt v2 to disable RSA-PSS in NSS 3.27 The following upstream patches have originally added support for RSA-PSS signatures: https://hg.mozilla.org/projects/nss/rev/10b045de68e6 https://hg.mozilla.org/projects/nss/rev/71987d6f797f https://hg.mozilla.org/projects/nss/rev/ab21f845dbf9 While we're waiting for an upstream fix in https://bugzilla.mozilla.org/show_bug.cgi?id=1311950 here is patch (attached) for NSS 3.27 that attempts to disable the use of RSA-PSS signature completely. I created a scratch/test build that uses the attached patch: http://koji.fedoraproject.org/koji/taskinfo?taskID=16260879 Could someone please test if that build fixes the bug, and NSS still works correctly? (The NSS test suite passes with this patch.)
Comment on attachment 1216147 [details] patch attempt v2 to disable RSA-PSS in NSS 3.27 Bob, does this make sense? Tim said, the patch might disable more than necessary, but it passes the NSS test suite.
I can provide one confirmation that the scratch build worked. Showing client/server versions for nss package. Omitting nss-sysinit and nss-tools package versions because they mirror nss package version. ----------- Before test Server: nss-3.27.0-1.1.fc23.x86_64 Client: nss-3.27.0-1.1.fc23.x86_64 [client] $ ldapsearch -D <snipped> -Z -W -x -d8 TLS: error: connect - force handshake failure: errno 0 - moznss error -12227 TLS: can't connect: TLS error -12227:SSL peer was unable to negotiate an acceptable set of security parameters.. ldap_start_tls: Connect error (-11) additional info: TLS error -12227:SSL peer was unable to negotiate an acceptable set of security parameters. Enter LDAP Password: ber_get_next failed. ldap_result: Can't contact LDAP server (-1) ---------- After test Server: nss-3.27.0-1.1.0.test.2.fc24.x86_64 Client: nss-3.27.0-1.1.fc23.x86_64 [client] $ ldapsearch -D <snipped> -Z -W -x -d8 Enter LDAP Password: # extended LDIF # # LDAPv3 <snipped results>
Mark, thanks a lot. I think I should go ahead and create official builds for fedora testing with this change, so we can get broader feedback for potential regressions.
nss-3.27.0-1.2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d0de70c5c1
nss-3.27.0-1.2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e49d6409c7
nss-3.27.0-1.2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-456ead2c2e
Comment on attachment 1216147 [details] patch attempt v2 to disable RSA-PSS in NSS 3.27 r+ rrelyea. Tim is working on a more friendly fix upstream, but this allows us to update NSS as is. bob
nss-3.27.0-1.2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d0de70c5c1
nss-3.27.0-1.2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e49d6409c7
nss-3.27.0-1.2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-456ead2c2e
Even after installing nss-3.27.0-1.2.fc24, I am still encountering problems: [thomas@sarkovy ~]$ ldapsearch -H ldaps://sarkovy.koeller.dyndns.org:636 -Y plain -d 1 ldap_url_parse_ext(ldaps://sarkovy.koeller.dyndns.org:636) ldap_create ldap_url_parse_ext(ldaps://sarkovy.koeller.dyndns.org:636/??base) ldap_sasl_interactive_bind: user selected: plain ldap_int_sasl_bind: plain ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP sarkovy.koeller.dyndns.org:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: loaded CA certificate file /etc/pki/tls/root_ca.pem. TLS: could not set cipher list TLSv1.2. TLS: error: could not initialize moznss security context - error -12285:Unable to find the certificate or key necessary for authentication. TLS: can't create ssl handle. ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
(In reply to Thomas Köller from comment #32) > TLS: could not set cipher list TLSv1.2. That is not a connection error, that looks like a configuration error to me
> TLS: could not set cipher list TLSv1.2. This seems to be more of a bug 1375432 and/or bug 1387868 issue. Those should be fixed soon. > TLS: error: could not initialize moznss security context - error -12285:Unable to find the certificate or key necessary for authentication. This looks like an incorrect user cert/key configuration (but might be misleading due to the bugs I mentioned above).
Hubert, Matus, thanks for analysing the feedback from comment 32. In the meantime, we've received 9 positive karma points on the f24 update. (and two each for f25 and f23). It seems we can risk pushing this update to stable.
nss-3.27.0-1.2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Hubert Kario from comment #33) > (In reply to Thomas Köller from comment #32) > > TLS: could not set cipher list TLSv1.2. > > That is not a connection error, that looks like a configuration error to me I had that setting in my ldap.conf, but removing it did not help: --- [thomas@sarkovy ~]$ ldapsearch -H ldaps://sarkovy.koeller.dyndns.org:636 -Y plain -d 1 ldap_url_parse_ext(ldaps://sarkovy.koeller.dyndns.org:636) ldap_create ldap_url_parse_ext(ldaps://sarkovy.koeller.dyndns.org:636/??base) ldap_sasl_interactive_bind: user selected: plain ldap_int_sasl_bind: plain ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP sarkovy.koeller.dyndns.org:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: loaded CA certificate file /etc/pki/tls/root_ca.pem. TLS: certificate [CN=Köller Family Host Signing Certificate,OU=Network Administration,O=Köller Family,L=Hamburg,ST=Hamburg,C=DE] is not valid - error -8179:Peer's Certificate issuer is not recognized.. TLS: error: connect - force handshake failure: errno 2 - moznss error -8179 TLS: can't connect: TLS error -8179:Peer's Certificate issuer is not recognized.. ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: TLS error -8179:Peer's Certificate issuer is not recognized. --- Using 'opensssl s_client', I can connect without problems: --- [thomas@sarkovy ~]$ openssl s_client -connect 127.0.0.1:ldaps -CAfile /etc/pki/tls/root_ca.pem -verify 3 verify depth is 3 CONNECTED(00000003) depth=2 C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network Administration, CN = K\C3\B6ller Family Root Signing Certificate verify return:1 depth=1 C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network Administration, CN = K\C3\B6ller Family Host Signing Certificate verify return:1 depth=0 C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network Administration, CN = sarkovy.koeller.dyndns.org verify return:1 --- Certificate chain 0 s:/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=sarkovy.koeller.dyndns.org i:/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=K\xC3\xB6ller Family Host Signing Certificate 1 s:/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=K\xC3\xB6ller Family Host Signing Certificate i:/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=K\xC3\xB6ller Family Root Signing Certificate --- Server certificate -----BEGIN CERTIFICATE----- MIIGfzCCBGcCAgECMA0GCSqGSIb3DQEBBQUAMIGdMQswCQYDVQQGEwJERTEQMA4G A1UECAwHSGFtYnVyZzEQMA4GA1UEBwwHSGFtYnVyZzEXMBUGA1UECgwOS8O2bGxl ciBGYW1pbHkxHzAdBgNVBAsMFk5ldHdvcmsgQWRtaW5pc3RyYXRpb24xMDAuBgNV BAMMJ0vDtmxsZXIgRmFtaWx5IEhvc3QgU2lnbmluZyBDZXJ0aWZpY2F0ZTAgFw0x NjAyMTIxMTQzMjFaGA8yMDYwMDYwNjIzNTk1OVowgZAxCzAJBgNVBAYTAkRFMRAw DgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdIYW1idXJnMRcwFQYDVQQKDA5Lw7Zs bGVyIEZhbWlseTEfMB0GA1UECwwWTmV0d29yayBBZG1pbmlzdHJhdGlvbjEjMCEG A1UEAwwac2Fya292eS5rb2VsbGVyLmR5bmRucy5vcmcwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQCu64YqsBJ8KNlrMTwJewgZB+XKaBNRQPetOEmjzyTz U0MXwpJwzEZ9bAi4nTzaJ2YY/o898CKTf/x7UUxKiU3rb4Mzfmawkh4qhXn++2Cm H6+oTYRB6rU90VEyuGbyJElG/tpICX/145pVCh0M/MB2+/ZvGxh8CoaGSOYOHVpX MqhKlovnNO8YMopDuT8sOLsMYZqcC++nqXNFxHeNyZoXapoJl/pxywIgv5TJJsm0 kA7LmpHK1lS7aepT0i/D1ONmsTIgmBG6BsE39IJlSf+pV62RsZ3hu9Ryo3q+ua0p SGuAnmZ2FSBqr17O+Z4pISr94uzCME2lxzwWTNdmiDMwy/HBNX94gLm85ww+K4qq 5AEO9n1vfjZGm4WeZC/0+66IYR8IdqTC+/OdczFm3YaYptU5x/rrZrNtQIgsDpEs nr6XgPED3ZKBq/5HiLN5tAf1NZbifMBVjsuUc8Dom99jpnWn94BSfmGHBOhLJrmd ujggP+Jr8qNClGh08rowJWoJnVZHlM2hemGLCIoCX4+8eu4hgiuRYXLEHLBJbtRH o7f1597FRO0iJgne7l9StpufiS5PSWd6s7FGEVJ3tb02GR9mlySAoqQ96XT/uNfm 0MJenxgsP62T7cvIu70u6MlF9R0kk+y9xkzLQz6GQ9xR0H/Z23vxokV4BRrZrIun CwIDAQABo4HWMIHTMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgQwMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjB+BgNVHREEdzB1hwTAqAABhwTAqAEBhwTA qAIBghdkaGNwLmtvZWxsZXIuZHluZG5zLm9yZ4IWZG5zLmtvZWxsZXIuZHluZG5z Lm9yZ4IXbWFpbC5rb2VsbGVyLmR5bmRucy5vcmeCF2xkYXAua29lbGxlci5keW5k bnMub3JnMBcGA1UdHgQQMA6gDDAKhwjAqAAA//8AADANBgkqhkiG9w0BAQUFAAOC AgEAfbAn/YoOFrrlph1vFOGT5lyTeclbT6DzzNgD8Y2cSOOcQBYWfQRZPBn5eUYp FNPiC/kq3rfWSg9122dnYsJ60YVLWSj3WqYeX12ek6S5S/DWGWJmVpLNf9vsjML3 YzjaAZYOQomkQFMRdWp2y7gkiAS+yjOny6LPm2zU4AlXE/fKDtgmsFxg3lAnz9DZ fpJZKxzgUUyjJaO8Z6NjlYf6tgInLWiEjEvyVLxkK2VywrUlvGLDTUJxmsJa7oYi QCvPLK7xW2j0H4H3DK+czSrriJfbEYbs3yEA5guIgdisCIvY6I2wI2E6eUxeWv0H NUxz/tTsyG4SxHFR8cmdfPftUr5CH1ZtTi+7j0p/cwV03Mb7Lf4CZOntfDgdDQ1i TayvZCo6d1xsuSKYvuKRK8KXGnw6wHYhxuF2UG+J9fRoGu/S0rVucWJZUSt94ZFH +m5FccArgBhDOMv70lW+bKhYK57K4oByABN7+vk4J9T1qgu+8mBiA802RCVFIqUi 2x2SIOr1c+zjtuNaXGfkj1UTCgBXXqTxzWfo+6PO4OkJcIqtZZsEy3xmIBVonrSK +ILz8IfQRt6NYrpGruleEEwOeHIeKCCk9NuNKfQ3CZEbZIseyWNTF7GCQFTG33Mz GxDRz0xUe4gNVawwC+voOuThKqHf6B3sQ+bsVelusNGTAXg= -----END CERTIFICATE----- subject=/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=sarkovy.koeller.dyndns.org issuer=/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=K\xC3\xB6ller Family Host Signing Certificate --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3948 bytes and written 351 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-SHA Session-ID: 05DE5F07B11BF607E242013D1FFE2A80C2F0B814E19380F0F1C42086790F1590 Session-ID-ctx: Master-Key: DE5EECC6E5EFA4BA8BB630FF724E6E6152ADB5102A4E19DD75ACD4D69D083F572D082294BA73216303351094EEAF88D1 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1478561956 Timeout : 300 (sec) Verify return code: 0 (ok) --- So, I'd conclude it is a nss issue.
Thomas, it's a different issue. Your ldap server uses a certificate that was issued by your own CA. When you connect using openssl, you're telling it to trust your own CA, which you apparently have installed at /etc/pki/tls/root_ca.pem (and openssl wouldn't trust the server cert without that option). Although the ldapsearch command also appears to load that root CA certificate, it decides it isn't trustworth. The error messages clearly state that the connection is refused, because of certificate validation failures. If you believe that this is a problem with openldap/NSS, please let's keep this bug clear of this separate issue, and please file a separate bug (and cc me and Matus).
nss-3.27.0-1.2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Even after installing nss-3.27.0-1.2.fc23 I'm running into problems. Not all "clients" are able to connect. - sssd is able to connect via port 636 - php is not able to connect (still a tls negotiation error occurs)
Please ignore my previous comment. It was a configuration issue (missmatch between certificate and the configured CA certificate for validation)
The bug has apparently been fixed upstream, for NSS 3.28 It will be another 4 weeks, until we'll have a stable version of NSS 3.28 that we could test with Fedora. Should we try to test this earlier, by proving NSS 3.27 builds with a backported patch?
Created attachment 1220527 [details] attempted backport of upstream fix to NSS 3.27
nss-3.27.0-1.3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-03d76071b6
nss-3.27.0-1.3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-56cfdb6815
nss-3.27.0-1.3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-cddf0ec383
Everyone who was affected by this bug: Could you please repeat your testing with the most recent packages (which contains the better fix mentioned in comment 42), and test if everything still works for you? Thanks in advance. See comments 44, 45 and 46 for the newer package versions.
nss-3.27.0-1.3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-56cfdb6815
nss-3.27.0-1.3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-03d76071b6
nss-3.27.0-1.3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-cddf0ec383
I installed the -1.3 package (which, BTW, doesn't follow the Fedora versioning guidelines) on an F24 ldap slave server and restarted slapd. Everything seems fine so far. I'm not sure how to really exercise it but I can talk to it via ldaps which I couldn't do when the -1.1 package came out.
nss-3.27.0-1.2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.27.0-1.3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.28.1-1.1.fc24 nss-softokn-3.28.1-1.0.fc24 nss-util-3.28.1-1.0.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18
Please ignore comment 54, I mistakenly attached this bug to the update.
firefox-50.1.0-3.fc24 nss-3.28.1-1.2.fc24 nss-softokn-3.28.1-1.0.fc24 nss-util-3.28.1-1.0.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18
firefox-50.1.0-3.fc24, nss-3.28.1-1.2.fc24, nss-softokn-3.28.1-1.0.fc24, nss-util-3.28.1-1.0.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18
firefox-50.1.0-3.fc24 icecat-45.5.1-6.fc24 nss-3.28.1-1.3.fc24 nss-softokn-3.28.1-1.0.fc24 nss-util-3.28.1-1.0.fc24 seamonkey-2.46-3.fc24 thunderbird-45.6.0-5.fc24 xulrunner-44.0-9.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18
firefox-50.1.0-3.fc24, icecat-45.5.1-6.fc24, nss-3.28.1-1.3.fc24, nss-softokn-3.28.1-1.0.fc24, nss-util-3.28.1-1.0.fc24, seamonkey-2.46-3.fc24, thunderbird-45.6.0-5.fc24, xulrunner-44.0-9.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18
firefox-50.1.0-3.fc24, icecat-45.5.1-6.fc24, nss-3.28.1-1.3.fc24, nss-softokn-3.28.1-1.0.fc24, nss-util-3.28.1-1.0.fc24, seamonkey-2.46-3.fc24, thunderbird-45.6.0-5.fc24, xulrunner-44.0-9.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Closing this, as the fix shipped 6 months ago.