32
votes

I need to create a csr file to give it to someone.

The csr file is for a SSL certificate for a azure web app.

When I google I find inconsistent information about where to generate the csr file.

Some sources say: I have to create the csr file on the server the web app is running.

In my case the server on azure is unknown. I can not run anything there...

Or is it ok to create the csr on my local pc with all company data + the subject filled out with the custom domain?

5

5 Answers

12
votes

openssl is installed in the console, you can generate the files there. You will have to specify all of the settings necessary in the original command to openssl because it is supposed to prompt you with questions but it doesn't work at present. So something like this:

openssl req -new -newkey rsa:2048 -nodes -out yoursite_com.csr -keyout yoursite_com.key -subj "/C=US/ST=California/L=San Francisco/O=Your Site Inc./OU=Engineering/CN=yoursite.com"

once you have your csr you can't open it from the console, you actually have to use Kudu (click on Advanced Tools) to open the file and copy the contents.

10
votes

You're able to create a cer-file with the help of the Certreq.exe or OpenSSL tool.

For more details, please have a look at the official documentation how to enable HTTPS for an app in Azure App Service.

7
votes

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:

  1. Why would you want (or even should) generate the CSR on the target machine?
  2. 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.

5
votes

Instead of doing it manually, an option is to search through the extra services for "App Certificate Service" which will provide you with a wizard for buying an SSL certificate and then binding it to your application. It's much simpler and quicker than generating a CSR by hand, and it's a lot less confusing as well. The documentation was verbose and wasn't really clear on whether or not we're supposed to remote into the server and generate the CSR there, etc, so I highly suggest doing it via the App Certificate Service.

1
votes

For example, do it in the command line with ssl in your local machine:

  • create csr: openssl req -new -newkey rsa:2048 -nodes -keyout yourprivate.key -out yourdomainname.csr

here you already have generated the crt and bundle file:

  • next step to create pfx: openssl pkcs12 -export -out certificate.pfx -inkey yourprivate.key -in nameofyourcertfile.crt -certfile nameofyourtcacertfile.ca-bundle

after you can upload your certificate.pfx file into Azure App Services and bind to your custom domain

You have to buy a certificate and setup for your naked and www domain, because Azure currently only provide free, managed certificate for www domain.