Others have provided valuable insights on those facts:
- That you can (and in case of Azure Web App, basically have to) generate the CSR on a different machine, than the target server (the one, which will be using the certificate).
- Tools, which you can use to generate the CSR (e.g. openssl, DigiCert utility).
- An alternative way to obtain certificate for Azure Web App (Azure App Certificate Service).
Maybe I'm missing something, but I do not see an answers on:
- Why would you want (or even should) generate the CSR on the target machine?
- Why don't you actually have to?
My approach to answering those two questions I would start with the fact, that generating CSR is actually a process, that produces two artifacts, where the obvious part - the request for certificate - is probably the less important one for this matter. The more important one, which also actually has to come first, is the RSA key pair being generated, where the public part of the pair is used in the CSR request, and the private one is the crucial part of the whole goal of using the certificates.
Although the key pair is usually being generated using entropy data based on the hardware, so specific to the machine you are using, the outcome (the key pair) may be used anywhere, as the key values are only mathematically bound to each other. The CSR content is based on the public key and the subject of the requested certificate, so again, there's nothing in there, which can't be used elsewhere. This explains why there's no technical limitation on actually generating the CSR (and keys) on a different machine/service, than the one, which will actually be using it, so the question number 2 is addressed.
The answer to the question number 1 comes from the crucial feature of the private key, which is being generated in the process. This crucial feature is that it should remain private. The ideal being only the sole user of the certificate identity being able to use it. That "user" would be the target service (the web server). When you generate the key elsewhere, you are responsible for protecting it on that environment and in transit to the target. This is often an unnecessary risk. The suggested solution is often to generate the key in the target certificate/key store, with private key protection, which prevents the private key from being extracted (exported) from the store. Even the target service (web server) will actually not be able to extract/read it (but will be able to use it). As the key pair is generated in the CSR creation process, this means that this process should be executed where that store is, and by that store features. This should answer this question. As a side note, the DigiCert tool as well as the IIS manager UI are using the Windows cert stores, which do add a protection layer for the private key, but they do mark the key as exportable, which allows key extraction. The OpenSSL tool (on Windows) generates the key outside of the Windows cert stores (as files), so you can easily access it, which is not that secure.
I've found this article: https://www.namecheap.com/support/knowledgebase/article.aspx/9854//how-to-generate-a-csr-code-on-a-windowsbased-server-without-iis-manager, which mentions 3 additional ways/tools for generating the CSR, where the first one (using Certificates snap-in in Microsoft Management Console) actually does allow you to mark the private key as not exportable.
Of course, in your case, the ability to take (e.g. export) the private key is crucial, as you have to generate the CSR elsewhere, as the Azure Web App cert store has currently no feature allowing generation of the CSR.