This seems to be a duplicate of bug #1228233 and very likely problem with the server you are connection to.  FWIW, curl is able to connect the host if you specify the TLS_RSA_WITH_AES_128_CBC_SHA cipher-suite:

$ curl -svo/dev/null --ciphers rsa_aes_128_sha https://www.cisco-global-returns.com/ciscologin/
*   Trying 201.131.109.45...
* Connected to www.cisco-global-returns.com (201.131.109.45) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
*       subject: CN=www.cisco-global-returns.com,OU=nsProtect Secure Xpress,OU=Domain Control Validated
*       start date: Apr 02 00:00:00 2014 GMT
*       expire date: Jun 28 23:59:59 2017 GMT
*       common name: www.cisco-global-returns.com
*       issuer: CN=Network Solutions DV Server CA,O=Network Solutions L.L.C.,C=US
> GET /ciscologin/ HTTP/1.1
> User-Agent: curl/7.40.0
> Host: www.cisco-global-returns.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Pragma: no-cache
< Cache-Control: no-cache, no-store
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: JSESSIONID=6ABB47B07B80E824AB0D6818C78C6F82; Path=/; Secure
< Content-Type: text/html;charset=ISO-8859-1
< Content-Length: 1134
< Date: Mon, 08 Jun 2015 15:33:40 GMT
< Server: Cisco GCT
< 
{ [1134 bytes data]
* Connection #0 to host www.cisco-global-returns.com left intact

Hi

Reading the bug report, I can concur that he is experiencing the SAME problem that I am.  

To point out:  1) last week I could work on my servers before upgrading, 2) it works on my colleague's Ubuntu desktop now, 3) the server has not been changed at all, 4) it fails on four different Call Managers, the Call Centre Servers and the Unity Voicemail server.

From my laptop:
A)   The Cisco site
[louis@lenovo ~]$ curl https://www.cisco-global-returns.com/ciscologin/
curl: (35) SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message.


B)   My Call Manager Server
[louis@lenovo ~]$ curl https://10.96.63.132:8443/ccmadmin/showHome.do
curl: (60) Issuer certificate is invalid.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
[louis@lenovo ~]$ 


The other bug refers to a fix for LogJam.  This is nss update is affecting the use of Firefox and Seamonkey.  Why is this suddenly treated as an invalid certificate error?  In the past I could always accepted that "I know this is not a trusted CA certificate, but I trust this site" type of situation.

Surely Firefox should PROMPT me if I still wish to process instead of just killing my connection.   

My big problem is that now I am unable to manage my Call Managers, and this is affecting my work!

How can I implement the equivalent of "--ciphers rsa_aes_128_sha" in Firefox?

Perhaps the implementation of this needs to be treated with understanding of the end-user instead of a draconian approach?  At this time there is nothing I can do to fix my Call Managers -- I can't even apply a fix should one become available eventually, because now I cannot log onto them!!


Thank you so much for your time and input.

You can use the following command to check the size of Diffie-Hellman parameters used by the server (you need at least Fedora 21 version of OpenSSL or upstream OpenSSL 1.0.2):

openssl s_client -connect www.cisco-global-returns.com:443 -cipher EDH </dev/null 2>&1 | grep 'Server Temp Key'

in this case you'll see:
Server Temp Key: DH, 768 bits

Parameters of this size are known to be breakable using academically accessible computing resources. This is known as the Logjam attack, you can read details about it on https://weakdh.org/.

This is a misconfiguration of the server on the level of enabling just SSLv3 (POODLE attack) or only export grade ciphers(FREAK attack). Please complain about this issue to your vendor.

This change also follows policy set by NSS upstream: Mozilla.

To workaround this problem, you can disable DHE ciphers in Firefox. But I strongly recommend doing that only in a profile[1] dedicated to connecting to such broken devices. To disable those ciphers, go to about:config page, search for "security.ssl3" and change setting for all ciphers which names start with "dhe_rsa" to False, in practice that means "security.ssl3.dhe_rsa_aes_128_sha" and "security.ssl3.dhe_rsa_aes_256_sha". This should have an immediate effect.

 1 - https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

OK, I provided POODLE and FREAK as examples of misconfiguration, I didn't expect the server to be actually vulnerable to them:

https://www.ssllabs.com/ssltest/analyze.html?d=cisco-global-returns.com

Thanks ... I have logged a TAC case with Cisco to help with my Call Managers, and also mentioned the above issue as a side note!  Oops!

Can I make an exception to the key test? some of my customer as a SSO system use Server Temp Key of 768 bits and I can't work with those sites after the last update?

There is no mechanism to configure the minimum DHE key size, it's hardcoded in the library.

How can I downgrade the nss? I try 
$ dnf downgrade nss
but I got error about nss-tools required.

(In reply to Avi Levy from comment #8)
> How can I downgrade the nss? I try 
> $ dnf downgrade nss
> but I got error about nss-tools required.

Try
  dnf downgrade nss nss-sysinit nss-util nss-softokn nss-softokn-freebl

If it mentions additional nss-* packages, add them to the command line, too.

$ sudo dnf downgrade nss nss-sysinit nss-util nss-softokn nss-softokn-freebl
Last metadata expiration check performed 2:24:25 ago on Mon Jun 29 10:06:50 2015.
Error: package nss-tools-3.19.2-1.0.fc22.x86_64 requires nss(x86-64) = 3.19.2-1.0.fc22, but none of the providers can be installed.
package nss-3.19.2-1.0.fc22.x86_64 requires nss-softokn(x86-64) >= 3.19.2, but none of the providers can be installed

workaround for Firefox

you can make the following change in about:config:
security.ssl3.dhe_rsa_aes_128_sha=false

(In reply to Taras from comment #11)
> workaround for Firefox
> 
> you can make the following change in about:config:
> security.ssl3.dhe_rsa_aes_128_sha=false

Thank you Taras, this worked for me.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 '21'.

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 21 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.

I think we can close this bug as a WONTFIX