http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
But I've found in practice that many operate under different circumstances. For example, many hardware devices offer only a limited set of cipher suites. To know how to configure them, you have to understand the advantages and limitations of each.That's why I keep the SSL/TLS Deployment Best Practices higher level, without specific cipher suite configuration examples:
https://www.ssllabs.com/projects/best-practices/Are all of them problematic for other reasons?
Thanks for all your work in this area!
I am sure there is a reason, but Microsoft never supported the DHE and RSA combination, which was the only way to achieve Forward Secrecy before ECDHE became widely supported.
[1] Actually, some web servers support multiple keys/certificates. With Apache, for example, you could have an SSL site with RSA, DSA, and ECDSA keys if you wanted. I think nginx is adding this capability too. But IIS does not support it.
As for your case, I propose that you follow my advice from the blog post I linked to earlier. It's much easier to do that then to find out exactly why the results are not as you expect.
But even that doesn't give enough practical advice as to which ciphers to pick. This blog post helps, but basically points out that there's no "perfect replacement" for what SSL ciphers people tend to be using today. That said, any attempt to avoid bad ciphers -- usually defaults -- is better than nothing. Be careful: there are even valid SSL choices that don't encrypt your data at all. Do your research when planning SSL and verify your SSL configuration once you've selected server-side preferred options. It really does matter.
http://security.stackexchange.com/ is useful too, though not as fresh as many security blogs might be.