I'm new to the field of cryptography, but I want to make the web a better web by setting up the sites that I host with Perfect Forward Secrecy. I have a list of questions regarding the setup of Perfect Forward Secrecy. Here it goes:

  • Can my choice of certificate authority hinder the use of Perfect Forward Secrecy?
  • How can I create the strongest certificate using ONLY Perfect Forward Secrecy (meaning if the browser can't use PFS, it won't load anything)?
  • Are there any extra settings that I need to know about for configuring my sites to use these certificates (especially since I only want PFS)?
  • Anything else that I should know, feel free to tell me. I'm completely new to this idea.

3 Answers 3


In the beginning SSL handshake, the client sends a list of supported ciphersuites (among other things). The server then picks one of the ciphersuites, based on a ranking, and tells the client which one they will be using.

This step is the one that determines whether or not the future connection will have perfect forward secrecy. Note that, at this point, certificates have not entered the picture at all. This is because whether or not a connection has perfect forward secrecy is determined by how the session key is derived. And how the session key is derived is determined by the ciphersuite in use. So, the ciphersuites that use ephemeral Diffie-Hellman (DHE) or the elliptic-curve variant (ECDHE) will have perfect forward secrecy while the other options will not.

Thus, in order to configure PFS for your site, what you want to configure is your web server's ciphersuite-selecting options. More on this below.

Can my choice of certificate authority hinder the use of Perfect Forward Secrecy?

No. Perfect forward secrecy protects against the revelation of master keys. CAs do not have access to private (master) keys; a certificate from a CA is a signed public key. The CA is there to say "okay, client, I have verified that the public key here is indeed associated with <host>, it's safe." (Or, rather, the fact that it's signed by the CA says this.) Thus, your choice of CA will not impact PFS in any way.

How can I create the strongest certificate using ONLY Perfect Forward Secrecy (meaning if the browser can't use PFS, it won't load anything)?

As you can see, certificates are unconnected with the choice of ciphersuite (and hence PFS).

Instead, the web server you use probably has a ciphersuite configuration in its SSL configuration. There are usually two relevant options: first, the ciphersuites that you want your server to use, and second, how the server picks the ciphersuite. Here is the relevant section in my nginx configuration:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

The first line tells nginx to use those four protocols, as is apparent. The third line tells nginx to prefer its own ciphersuites over the client's. The point here is that we want to control exactly which ciphersuite will be selected. A client may send an ordering that suggests a non-PFS ciphersuite; hence, we trust the server.

The second line is where the magic happens. Note that I manually specify that I want those three ECDHE-* schemes first if they are supported by the client. From there, I fall back to the usual schemes. I feel the need to emphasize that I don't disallow clients that don't support PFS; some encryption is better than no encryption at all. Not all clients do support PFS, so this is pretty important. I realize your question said you want only PFS ciphersuites, but I would advise against that. With the above nginx configuration, the vast majority of connections' selected ciphersuites will have PFS. The configuration for Apache is apparently quite similar, which is not surprising given that both use OpenSSL.

To that end, a useful tool: the SSL Labs SSL Test. It gives you a basic grade on your SSL configuration. See, for example, Google's grade (click on one). It has a little green box under the grade informing you that the site supports PFS for all its tested browsers, and if you scroll down to 'Configuration', you will see a ciphersuite priority list, including which ciphersuites have PFS, as well as "simulated handshake" for the common browsers of the day.

  • 3
    $\begingroup$ Actually, for the DH cipher suites you need a key which can be used for signature. If your CA only gives certificates where the RSA key is marked as "encryption only", there might be problems. (I didn't ever try this out, though.) $\endgroup$ Jun 30, 2013 at 12:01
  • 1
    $\begingroup$ @PaŭloEbermann: Do you know of any (widely-used) CAs that will actually issue such a certificate? I was under the impression that CAs essentially always issued certificates with both keyEncipherment and digitalSignature set. $\endgroup$
    – Reid
    Jun 30, 2013 at 15:17
  • 1
    $\begingroup$ The reason that I asked for disallowing browsers that don't support PFS is because I am developing something that needs high security. It would be ideal to refuse to serve the page to clients without PFS support, or either redirect them to an error page. Thanks for the thorough explanation. I really appreciate your help. $\endgroup$ Jul 15, 2013 at 1:17
  • $\begingroup$ This anser leaves off some important server configuration involving how session resumption is handled. Do this the wrong way, and you don't actually have forward secrecy if your server is compromised or you are NSLd. imperialviolet.org/2013/06/27/botchingpfs.html $\endgroup$ Aug 23, 2013 at 7:20
  • $\begingroup$ There is a great book: OpenSSL Cookbook, which is completely free. In the first chapter, section: Putting It All Together, you can find solution how to filter out only these ciphers that support PFS. $\endgroup$ Sep 1, 2016 at 9:53

Here is a good guide for deploying forward secrecy on your SSL server. Here's another good guide that describes how to deploy forward secrecy for Apache, Nginx, and OpenSSL.

To answer your specific questions: As far as I know, you should be able to use any CA. The choice of forward secrecy doesn't come from the certificate; it comes from the list of ciphersuites you configure on your server. Therefore, if you configure your server with a short list of ciphersuites (listing only ciphersuites that provide forward secrecy), you will ensure that connections will either use forward secrecy or will fail. The guide I linked to above should give you guidance on everything you need to know.


Warning: it is widely believed that the ECC curves used for PFS have got NSA back doors in them. If you're up-to-no-good, setting up to use curves and algorithms that were designed and promoted by the NSA themselves might not be the best solution.

  • 4
    $\begingroup$ This answer definitely needs justification. Yes, it's widely believed that Dual EC DRBG is backdoored, but I don't think it is widely believed that all PFS ECC curves are backdoored? $\endgroup$ Dec 4, 2013 at 12:03
  • 3
    $\begingroup$ NIST curves are a bit suspicious since they contain large constants chosen without proper application of nothing-up-my-sleeve techniques. But we don't have any idea how such a weakness would work. $\endgroup$ Dec 4, 2013 at 12:30
  • 2
    $\begingroup$ For an explanation of why NIST curves are suspicious, see safecurves.cr.yp.to. In particular, the “rigid” criterion. $\endgroup$
    – Nate
    Dec 29, 2013 at 7:54
  • 2
    $\begingroup$ "Widely believed" may be a bit exaggerated, but there is reason for suspicion; crypto-systems should be safe beyond reasonable doubt. $\endgroup$ Jun 11, 2015 at 18:20
  • 1
    $\begingroup$ On the contrary, if the NSA had known an attack on the discrete log in the NIST P-256 curve, they would have been able to (among other things) have a backdoor in DUAL_EC_DRBG without getting caught (i.e. with publishing the SHA-1 seeds for both points). This would also have worked had they known a preimage attack on SHA-1. So the DUAL_EC_DRBG mess quite proves that NIST P-256 is safe (or at least, was safe in 2006 when DUAL_EC_DRBG was standardized). $\endgroup$ Mar 31, 2016 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.