Must a CSR be generated on the server that uses the certificate?

No. A certificate signing request (CSR) does not depend on the machine that will serve the certificate. What matters is that the CSR is signed by the corresponding private key and that the deployed TLS service can use that same key securely.

You can generate the pair on the target server, on a trusted provisioning system, or through a supported HSM or key-management provider. Always verify the certificate's public key, SAN entries, and intended use before deployment.

How a CSR relates to its key

A CSR contains the public key and requested identity information, with a signature made using the private key. The CA applies its validation and issuance policy, then signs a certificate containing the approved identity and public key. A valid CSR signature does not by itself prove control of a domain.

On a trusted machine, an OpenSSL 3.x example is:

umask 077
openssl req -new -newkey rsa:2048 -noenc \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com"

Older OpenSSL versions use -nodes rather than -noenc. The private key in this example is unencrypted on disk, so restrict access. Send the CSR to the CA; the CA does not need your private key. See OpenSSL req.

Why generate on the target server?

Local generation can avoid transferring an exportable private key between machines and reduce the number of temporary copies. It can also fit an ACME client's issuance-and-deployment workflow.

These are operational benefits, not cryptographic requirements. Centralized automation can be appropriate, and generating locally does not eliminate the need to verify that the selected key and certificate match.

If generation and deployment happen in different places

Use an approved encrypted transfer or secret-distribution system for the private key, not chat or email. Retain controlled backups according to your key-management policy and remove unnecessary temporary copies. File deletion or shred does not guarantee erasure from SSDs, snapshots, or copy-on-write filesystems.

Check key pairing before loading the service:

openssl x509 -in cert.crt -pubkey -noout -out cert-public.pem
openssl pkey -in example.com.key -pubout -out key-public.pem
openssl pkey -pubin -in cert-public.pem -outform DER -out cert-public.der
openssl pkey -pubin -in key-public.pem -outform DER -out key-public.der
openssl dgst -sha256 cert-public.der key-public.der

Every command must succeed before equal hashes can establish a match. This approach works for common RSA and EC keys. Restrict the deployed key's ownership and permissions, commonly mode 600 for the controlled identity that reads it.

Nonexportable keys in an HSM or KMS

The program assembling a CSR can run separately from the device holding the private key. The signing operation is performed by that device. For TLS deployment, the server must support the same key provider and the required cryptographic operations; an arbitrary cloud KMS is not automatically a drop-in TLS private-key store.

A nonexportable key need not be copied onto the web server at all. This is a different workflow from generating a file key and transferring it.

Common questions

Is it safe to let a contractor generate the key?

Whoever can access the private key may be able to impersonate the service within the certificate's scope. Generate and retain your own key when outsourcing certificate administration, and provide only the CSR. If a key has been exposed, replace it rather than relying solely on a promise that other copies were deleted.

Can several servers share one certificate?

Yes, if they can securely use the corresponding key. A file-based deployment commonly distributes the same certificate and key to each TLS endpoint. Evaluate that shared key's exposure and renewal process; separate certificates may offer better isolation.

Must renewal reuse the original key?

No. A new key and CSR can be used for reissuance, subject to the CA's workflow. Some renewal tools can reuse a key; others rotate it. Choose according to your policy and confirm the newly issued certificate matches the key you deploy.