Assume that I have created a CSR and I am going to buy an SSL certificate with it. Would I be able to use the SSL certificate on another machine than where the CSR was created?

Someone I know recently told me it wasn't, but I'm not entirely sure.

2 Answers 2


No, it is not true.

The CSR defines various parameters for the certificate that you are requesting, such as the Common Name, any Alternative Names, etc. However the CSR is, ultimately, just a file, and you can do all the usual file things with it -- such as copying or moving it to another server, if you wanted to.

Not that even that much is required. Your SSL certificate that you receive in response to your CSR (oftentimes with a key file and/or a "certificate chain") is all that you need. And you can put it on as many machines as you want, even if none of them ever saw the CSR in the first place, let alone were the originating machines for it.

Case in point: I manage a cluster of 5 (soon-to-be-deprecated) email servers, another cluster of 9 (soon-to-replace-the-former) email servers, a pair of BigIp load balancers, a cluster of 5 web servers, and more -- and all 20+ of them use exactly the same certificate, key, and chain files, but not the CSR (heck, the load balancers don't even have an option in their GUI to upload the CSR at all!). The CSR that was used to get this certificate in the first place? The machine that generated it was decommissioned a while ago, taking the sole copy of the CSR with it.

What you can't do, however (well, not without provoking errors anyway) is use your certificate on a domain other than that named on the certificate; e.g. if you have a certificate for example.com, with an alternative name of example.net, you could not use it on example.org. (Well, technically you could, but you'd get "invalid certificate" errors any time you visited it.) You also could not use it on sub.example.com. This has nothing to do with the CSR other than that's where you put those names in the first place, though.


You don’t need the CSR in order to use the certificate. In order to have a machine authenticate with this certificate, though, the machine also needs the private key that goes with the certificate.

The private key is typically generated along with the CSR. In the simplest scenario, the private key is just a file which you can copy over to as many machines as you like, along with the certificate. (If you use a hardware security module (HSM), this step is more complex, but there are still ways to do it.) This is also the reason why you should protect the private key from unauthorized access, similar to a password.

As Kromey mentioned, the other thing to consider is the name for which the certificate has been issued. It has to match the name at which your users will reach the server:

  • In a load-balancing scenario (five identical servers behind a load balancer, all using the same certificate) you’re fine.
  • Same goes if you have a wildcard certificate (such as *.example.com) and all your server names match it (e.g. www.example.com and mail.example.com).
  • If your certificate is for www.example.com and you try to use it on mail.example.com, users will get a server name mismatch warning when they try to connect (some software products might even refuse to connect altogether).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .