Must CSRs be generated on the server that will host the SSL certificate?

Question

Is it necessary to generate the CSR (Certificate Signing Request) on the same machine that will host my web application and SSL certificate?

This page on SSL Shopper says so, but I'm not sure if that's true, because it would mean I'd have to buy a separate SSL certificate for each server in my cluster.

What is a CSR? A CSR or Certificate Signing request is a block of encrypted text that is generated on the server that the certificate will be used on.

Solution 1

No. It is not necessary to generate the CSR on the machine that you want to host the resulting certificate on. The CSR does need to be generated either using the existing private key that the certificate will be eventually paired with or its matching private key is generated as part of the CSR creation process.

What's important is not so much the originating host but that the private key and resulting public key are a matching pair.

Solution 2

kce is dead right, it absolutely does not need to be done on the same machine, but it does need to be done from the relevant private key.

The only reason I'm posting a second answer is because no one has said why you might want to do such a thing. Nearly every key/CSR set that I generate is done from my laptop or desktop, then the key is securely copied onto the server where the certificate will be installed, and the CSR is sent off to the signing agency. The reason is entropy: SSL certificates are generally used to secure servers, and servers often have very shallow entropy pools, which either weakens keypairs they create or makes creation take a long time. Desktops, on the other hand, have a useful source of randomness connected via keyboard/mouse cables, and thus tend to have deep entropy pools. They therefore make much better platforms for operations that require high-quality random numbers, keypair generation being one such purpose.

So not only can the key/CSR be generated off-server, but I find there is frequently a good reason to do so.

Comments

[David Schwartz]

You are confusing different meanings of the word "server". When you say "each server in my cluster", by "server" you mean a physical box. When they say "on the server that the certificate will be used on", they mean a thing that provides a service, whether it's a physical box or not. (When you generate a CSR, before you send it off to a CA, make 100% sure you know precisely where the corresponding private key is. The certificate will be useless without it.)

[Ladadadada]

And that the private key remains private. Don't just go copying it around everywhere and then email it to your mate and ask him to generate the csr for you.

[Andrew B]

The factor that limits the key+cert to usage with a specific machine is DNS (hostname needs to match the cn or a SubjectAltName field), as well as uniqueness. Not only does using the same private key with multiple servers create a higher risk profile, but software will ocasionally freak out of it detects multiple hosts using the same serial number. (with good reason)

[Andrew B]

(also, I'm agreeing with the answer, I should have worded that as "client-perceived hostname")

[Andrew B]

I view the human risk as greater than the entropy risk. Desktops also have a plethora of their own risks depending on the OS and asset management policy, nevermind the practices of the administrators involved. (are the hard drive sectors being shredded prior to deletion if it's an unencrypted private key? does user practice ever run the risk of exposing the key?) PKI is one of those things I don't trust many people to understand from end to end, nevermind the human error element, so I question the statement of there being "frequently a good reason to do so". Otherwise, an interesting point.

[MadHatter]

Those are all reasonable questions, especially if turned round into a best-practice list for keypair generation. For those who want to take this really seriously, there are some excellent suggestions at serverfault.com/questions/307896/… - the question is about CA generation and handling, but many of those ideas can also be adopted for best-practice in keypair generation.

[Andrew B]

That's fair now, thank you. I just felt there needed to be some kind of disclaimer, as it's dangerous for rank and file admins who don't understand the risks involved to interpret that as a best practice statement. If the key can be stolen, it's game over.

[Patrick Mevzek]

"servers often have very shallow entropy pools" I would love to see some references about that... Nowadays maybe true, because mostly of VMs and docker stuff that indeed do not have real entropy and depends on the host anyway. But real hardware servers do have other sources of entropy, like network related events. Besides the fact that modern CPUs have internal entropy sources (that some may dislike to rely on).

[Marc]

Does the private key need to be generated on the server?