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?
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.
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.
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.
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.
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.
Related
I applied for certificates for my domains. I received files with the following extensions:
ca-bundle
crt (multiple files)
p7b
I would like to upload SSL certificates to Azure by installing the certificate. For that I need to upload pfx file that is not included. I read that I need to create a private key and then merge the certificates somehow in order to create one. Unfortunately, as a programmer, I do not understand what and where should be done. Could someone help?
I think, this link here talks about the exact scenario you are talking about.
"The question is, how do I convert the CRT file into a PFX file so that I can upload it to my Azure Web App? Here are the steps I followed to convert a CRT into a PFX file:"
Open Certificate Manager for the Local Computer
Import the Intermediate Certificate (.P7B file)
Import the SSL certificate (.CRT file)
Export the SSL certificate and its dependencies as a .PFX file
https://blogs.msdn.microsoft.com/waws/2015/12/02/add-an-ssl-certificate-to-an-azure-web-app-crt-and-p7b/
You will need to convert it using a Windows system.
More info can be found here
In the end I managed to do it in the following way:
I downloaded openssl from here: https://indy.fulgan.com/SSL/
Two files are needed - the domain certificate and the private key. Once you have them you issue the following command:
openssl pkcs12 -export -out file.pfx -inkey private.key -in certificate.crt
You need to provide a password for the export. This will create a file.pfx file that you can upload to Azure using the same password. The next step is to add SSL bindings. For each domain you choose the certificate and create the binding. After ~2 minutes the https connection will be available for your domains.
How can we setup an SSL for azure service fabrics website domain, since the server is going to run on 10 nodes. When i buying the certificate it is asking for CSR file. Where can i generate the CSR file since website is running on 10 nodes. How can i generate the CSR file regarding azure service fabrics website
I know about azure key vault where we will upload the the certificate and install on the nodes, but before doing that how can we generate CSR and get the Certificate from the providers like Symantec/Geotrust/godaddy
Can any one guide me for process of generating the CSR regarding azure service fabrics since it going to run on 10 nodes?
TLS certificates help create an encrypted channel between a browser and a web server while also authenticating the identity of the website that owns the cert. Your certificate is issued for one or more domain names, not nodes. You can use it on any number of nodes as long as the domain name the cert is issued for matches the site you are serving.
Most cert vendors provide tools to generate Certificate Signing Requests. An OpenSSL approach to the problem looks like this:
openssl req -new -sha256 -key domain.com.key -out domain.com.csr
There are already answers about generating self signed certificate with openssl like this. However, what I want is a certificate that can do nothing but authenticate and encrypt the traffic to predefined websites.
A certificate generated by the following command
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
has basic constraint / certificate authority set to YES, meaning that it can be used to sign other certificates. Suppose that my domain is mystackoverflow.com, an attacker who steals my private key would not only be able to MITM the connection to mystackoverflow.com, but also facebook.com or google.com because he can sign forged certificates with the said private key and get trusted by my system.
So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?
I want is a certificate that can do nothing but authenticate and encrypt the traffic to predefined websites...
So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?
There are three parts to this question.
First is how to "authenticate and encrypt [stuff]". That's handled by Key Usage and Extended Key Usage. In particular, bits like digitalSignature (signing key exchange, like Diffie-Hellman), keyEncipherment (key transport, like RSA), serverAuth, etc.
Second is how not to mint certificates. For end entity certificates (i.e., server certificates), you remove the CA=true basic constraint and you remove the keyCertSign bits. You will still need a intermediate CA with the ability to sign end entity certificates because that's where the policy of "this CA can only issue for these names" is applied.
Third is how to apply a policy like "this CA can only issue for these names". Under the IETF's rules for PKIX in RFC 5280, you can do it in the CA certificate with the Name Constraints extension. See section 4.2.1.10 for details.
Under CA/Browser Forum rules, you can do it because they have policy objects. But I don't know how to do it under the CA/B (it may be the same as the IETF).
You have to be careful with the IETF gear. They have extensions, but they don't have policies. So you need to ensure you are working within and existing extension, and not forging new policy. See OID for certificates issued under IETF policy? on the PKIX mailing list for more details.
The CA/B Forum is significant because browsers follow the CA/B Forum rules, and not the IETF. And the CA/B Forum and IETF have different requirements in a few key areas. That's why a certificate created with OpenSSL (which follows IETF guidelines) fails to validate in Browsers (which follow CA/B Forum guidelines).
A certificate generated by the following command: openssl req ...
It used to be how to do it, but its not how to do it today. Today it produces a malformed certificate (which may or may not cause problems, depending on your user agent). For the question you cited, one answer in particular tells you why its incorrect and how to do it.
.. an attacker who steals my private key ..
So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?
If you fear that the attacker might steal the key to the certificate and then sign other things with it, then you should not create a self-signed certificate. Instead create first your own CA. Then create a leaf-certificate which can not be used to sign certificates and sign it by your own CA. Once this is done put the private key of the CA far far away (offline or even destroy it if you don't need it to sign more certificates).
With this setup an attacker could still steal the identity of the certificate if it gets its private key. But since this certificate is not a CA itself (unlike normal self-signed certificates) it can not be used to sign new certificates.
I know a bit of authentication theory, but would like to know how is it really put in practice.
There are these software patches that must be distributed periodically. To ensure that only the genuine content reaches our users, we have been advised to sign our content before distribution.
The plan is to generate a Public-Private key pair. The patch would first be signed by our private key and recipients then authenticate the downloaded patch by using our public key. Our idea of signing is to generate a hash of the patch and encrypt the hash with our private key. The encrypted hash (signature) is to be bundled along with the patch before distribution.
We have been advised further that it is a good practice to get a digital certificate for our public key from a CA and post it on a certificate server in our premises. We are told that the CA would create this certificate using its private key. Our users are expected to download the public key certificate from our server and authenticate it using the public key of the CA. Thus our users would be confident that they have the right public key from us to authenticate the genuineness of the patch.
And finally the question:
How/where can the exact public key of the CA be downloaded for authentication of the public key certificate downloaded from our server?
In what formats are these certificates available? Are these plain text files or XMLs or ??
To answer your questions in order:
Using a browser and SSL. In that case you rely on the certificate store already in the browser. It may be a good idea to also publish the fingerprint of your own certificate. Note that you also distribute a certificate - or certificate chain - within your software. If the software download is trusted, then you may not even need an external Certificate Authority. But in that case you keep your private key of the CA very secure.
X5.09 certificates are created using ASN.1 DER encoding. DER is a binary encoding (and the textual ASN.1 definitions specifies the contents). Certificates are also often distributed in PEM format. This is a base 64 encoding of the binary certificate, with an additional header and footer.
I've been looking at how to create X509 certificates and I'm a bit confused. I understand the theory, and creating a single certificate is OK, but I don't have the operational know-how to create the system as a whole.
Here are the requirements:
1) There will be one master server. The SSL certificate for this will not be signed by any authority: it is the root. This certificate (or at least the means to verify it) will be distributed with the application.
2) There may be any number of secondary servers. Each will generate its own certificate and submit it to the master server.
3) The master server will sign secondary certificates with the root.
The use-case is that a client connects to a secondary server and must be able to verify that its certificate has been signed by the root.
N.B. The master server is identified by a DNS hostname. The secondary servers may be named or may be identified by IP address alone.
Four questions:
Can someone please show me the openssl commands to accomplish each of those three steps?
Which, if any, of the files generated by those steps should not be distributed?
After step 3, does the master have to return a modified certificate to the secondary?
Do the secondary certificates have to be distributed by the trusted master, or is it sufficient for the client to validate any certificate advertised by the secondary?
OpenSSL comes with a script useful for creating a basic CA: CA.pl. (You can of course configure it in more details by altering the OpenSSL configuration file.)
What the secondary servers should generate are Certificate Requests (CSR), which the CA can process to issue certificates (after a validation process of your choice).
Regarding file distributions: all parties should keep their private keys private.