I have to create a CSR for a wildcard SSL certificate. Some FAQs from SSL providers say that I should generate the CSR file on the machine where I want to install the certificate? My understanding is that it should not matter where I generate the CSR or the key file as long as I move the files to the right location later.
So my question is: Does it matter where the CSR and key files for SSL certification are generated?
Your understanding is correct. All other things being equal, it doesn't matter; but there are wrinkles.
One advantage to generating them on the server in question is it minimises the chance of the key being compromised in transit. As long as you use a secure machine to generate them, and a secure method (immune to MITM attacks) to move them to the server, you'll escape that. Don't forget to securely-erase them on the generating system, unless you deliberately intend to keep copies, and are secured accordingly.
One advantage to generating on a separate machine: usually, this will be your desktop. The entropy pool on a desktop machine is almost always deeper than on an unattended server, because the desktop has a big source of randomness connected via the keyboard and mouse cables (ie, you!). Shortage of entropy can either cause key generation to take a long time, or cause it to use /dev/urandom PRNG output instead, depending on how paranoid the generating tool is, and this can lead to weaker keys; desktop machines tend not to have this problem.
Later edit: pursuant to a discussion elsewhere which linked here, two points have been raised. Firstly, you could go for a half-way house by generating the entropy on your desktop with eg dd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat, copying that to the remote server, and feeding it to your key generation process either directly or by deepening the remote server's entropy pool. I have not yet found a way to do the former, and doing the latter generally requires exerting privilege, which - if the channel between you and the remote server is not secure, which is rather the point of the whole objection - is also insecure.
Secondly, the estimable mjg59 raises the issue of hardware security modules - that is, devices into which you put, or inside which you create, private keys, and which then performs key ops without ever letting the key out. That's an excellent point, but outside the scope of this question.
But the more general outcome of the thread - that you should have a precise threat model, and choose your responses appropriately - is a good one. My threat model is that my communications channels are secure but my endpoints are under intelligent attack. That means I will generate entropically-strong SSL keypairs locally and distribute them. If it turns out that my model is inaccurate and my comms turn out to be vulnerable, I will immediately know to assume that all my SSL keypairs are compromised. If your threat model is different, you should tailor your practices accordingly.
It somewhat matters.
If you generate them on an another machine, the keys are vulnerable on the generating machine, and then on the server. If you use an infected machine to generate them, some virii might steal the keys, even before they are moved to the secure server.
If you generate them on a secure server, and just move the CSR/cert around, the chances of someone/something getting the private key is smaller then in the first case, since the private key is located only on one machine.
