Generate Ca Private Key Openssl

While Encrypting a File with a Password from the Command Line using OpenSSLis very useful in its own right, the real power of the OpenSSL library is itsability to support the use of public key cryptograph for encrypting orvalidating data in an unattended manner (where the password is not required toencrypt) is done with public keys.

The Commands to Run

$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt Enter pass phrase for ca.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. Create a root CA certificate. Create your root CA certificate using OpenSSL. Create the root key. Sign in to your computer where OpenSSL is installed and run the following command. This creates a password protected key. Openssl ecparam -out contoso.key -name prime256v1 -genkey At the prompt, type a strong password.

Generate a 2048 bit RSA Key

You can generate a public and private RSA key pair like this:

openssl genrsa -des3 -out private.pem 2048

Openssl

That generates a 2048-bit RSA key pair, encrypts them with a password you provideand writes them to a file. You need to next extract the public key file. You willuse this, for instance, on your web server to encrypt content so that it canonly be read with the private key.

Export the RSA Public Key to a File

This is a command that is

openssl rsa -in private.pem -outform PEM -pubout -out public.pem

The -pubout flag is really important. Be sure to include it.

Next open the public.pem and ensure that it starts with-----BEGIN PUBLIC KEY-----. This is how you know that this file is thepublic key of the pair and not a private key.

To check the file from the command line you can use the less command, like this:

less public.pem

Do Not Run This, it Exports the Private Key

A previous version of the post gave this example in error.

Openssl Generate Rsa Private Key

openssl rsa -in private.pem -out private_unencrypted.pem -outform PEM

The error is that the -pubout was dropped from the end of the command.That changes the meaning of the command from that of exporting the public keyto exporting the private key outside of its encrypted wrapper. Inspecting theoutput file, in this case private_unencrypted.pem clearly shows that the keyis a RSA private key as it starts with -----BEGIN RSA PRIVATE KEY-----.

Visually Inspect Your Key Files

It is important to visually inspect you private and public key files to makesure that they are what you expect. OpenSSL will clearly explain the nature ofthe key block with a -----BEGIN RSA PRIVATE KEY----- or -----BEGIN PUBLIC KEY-----.

You can use less to inspect each of your two files in turn:

  • less private.pem to verify that it starts with a -----BEGIN RSA PRIVATE KEY-----
  • less public.pem to verify that it starts with a -----BEGIN PUBLIC KEY-----

The next section shows a full example of what each key file should look like.

The Generated Key Files

The generated files are base64-encoded encryption keys in plain text format.If you select a password for your private key, its file will be encrypted withyour password. Be sure to remember this password or the key pair becomes useless.

The private.pem file looks something like this:

The public key, public.pem, file looks like:

Protecting Your Keys

Generate Ca Private Key Openssl

Depending on the nature of the information you will protect, it’s important tokeep the private key backed up and secret. The public key can be distributedanywhere or embedded in your web application scripts, such as in your PHP,Ruby, or other scripts. Again, backup your keys!

Remember, if the key goes away the data encrypted to it is gone. Keeping aprinted copy of the key material in a sealed envelope in a bank safety depositbox is a good way to protect important keys against loss due to fire or harddrive failure.

Oh, and one last thing.

If you, dear reader, were planning any funny business with the private key that I have just published here. Know that they were made especially for this series of blog posts. I do not use them for anything else.

Found an issue?

Rietta plans, develops, and maintains applications.

Learn more about our services or drop us your email and we'll e-mail you back.

Other Blog Articles Published by Rietta.com

-->

The Application Gateway v2 SKU introduces the use of Trusted Root Certificates to allow backend servers. This removes authentication certificates that were required in the v1 SKU. The root certificate is a Base-64 encoded X.509(.CER) format root certificate from the backend certificate server. It identifies the root certificate authority (CA) that issued the server certificate and the server certificate is then used for the TLS/SSL communication.

Application Gateway trusts your website's certificate by default if it's signed by a well-known CA (for example, GoDaddy or DigiCert). You don't need to explicitly upload the root certificate in that case. For more information, see Overview of TLS termination and end to end TLS with Application Gateway. However, if you have a dev/test environment and don't want to purchase a verified CA signed certificate, you can create your own custom CA and create a self-signed certificate with it.

Note

Self-signed certificates are not trusted by default and they can be difficult to maintain. Also, they may use outdated hash and cipher suites that may not be strong. For better security, purchase a certificate signed by a well-known certificate authority.

In this article, you will learn how to:

  • Create your own custom Certificate Authority
  • Create a self-signed certificate signed by your custom CA
  • Upload a self-signed root certificate to an Application Gateway to authenticate the backend server

Prerequisites

  • OpenSSL on a computer running Windows or Linux

    While there could be other tools available for certificate management, this tutorial uses OpenSSL. You can find OpenSSL bundled with many Linux distributions, such as Ubuntu.

  • A web server

    For example, Apache, IIS, or NGINX to test the certificates.

  • An Application Gateway v2 SKU

    If you don't have an existing application gateway, see Quickstart: Direct web traffic with Azure Application Gateway - Azure portal.

Create a root CA certificate

Create your root CA certificate using OpenSSL.

Create the root key

  1. Sign in to your computer where OpenSSL is installed and run the following command. This creates a password protected key.

  2. At the prompt, type a strong password. For example, at least nine characters, using upper case, lower case, numbers, and symbols.

Create a Root Certificate and self-sign it

  1. Use the following commands to generate the csr and the certificate.

    The previous commands create the root certificate. You'll use this to sign your server certificate.

  2. When prompted, type the password for the root key, and the organizational information for the custom CA such as Country, State, Org, OU, and the fully qualified domain name (this is the domain of the issuer).

Create a server certificate

Next, you'll create a server certificate using OpenSSL.

Create the certificate's key

Use the following command to generate the key for the server certificate.

Create the CSR (Certificate Signing Request)

The CSR is a public key that is given to a CA when requesting a certificate. The CA issues the certificate for this specific request.

Note

The CN (Common Name) for the server certificate must be different from the issuer's domain. For example, in this case, the CN for the issuer is www.contoso.com and the server certificate's CN is www.fabrikam.com.

  1. Use the following command to generate the CSR:

  2. When prompted, type the password for the root key, and the organizational information for the custom CA: Country, State, Org, OU, and the fully qualified domain name. This is the domain of the website and it should be different from the issuer.

Generate the certificate with the CSR and the key and sign it with the CA's root key

  1. Use the following command to create the certificate:

Verify the newly created certificate

  1. Use the following command to print the output of the CRT file and verify its content:

  2. Verify the files in your directory, and ensure you have the following files:

    • contoso.crt
    • contoso.key
    • fabrikam.crt
    • fabrikam.key

Configure the certificate in your web server's TLS settings

In your web server, configure TLS using the fabrikam.crt and fabrikam.key files. If your web server can't take two files, you can combine them to a single .pem or .pfx file using OpenSSL commands.

IIS

For instructions on how to import certificate and upload them as server certificate on IIS, see HOW TO: Install Imported Certificates on a Web Server in Windows Server 2003.

For TLS binding instructions, see How to Set Up SSL on IIS 7.

Apache

The following configuration is an example virtual host configured for SSL in Apache:

NGINX

The following configuration is an example NGINX server block with TLS configuration:

Access the server to verify the configuration

  1. Add the root certificate to your machine's trusted root store. When you access the website, ensure the entire certificate chain is seen in the browser.

    Note

    It's assumed that DNS has been configured to point the web server name (in this example, www.fabrikam.com) to your web server's IP address. If not, you can edit the hosts file to resolve the name.

  2. Browse to your website, and click the lock icon on your browser's address box to verify the site and certificate information.

Verify the configuration with OpenSSL

Or, you can use OpenSSL to verify the certificate.

Upload the root certificate to Application Gateway's HTTP Settings

To upload the certificate in Application Gateway, you must export the .crt certificate into a .cer format Base-64 encoded. Since .crt already contains the public key in the base-64 encoded format, just rename the file extension from .crt to .cer.

Azure portal

To upload the trusted root certificate from the portal, select the HTTP Settings and choose the HTTPS protocol.

Azure PowerShell

Or, you can use Azure CLI or Azure PowerShell to upload the root certificate. The following code is an Azure PowerShell sample.

Note

The following sample adds a trusted root certificate to the application gateway, creates a new HTTP setting and adds a new rule, assuming the backend pool and the listener exist already.

Verify the application gateway backend health

  1. Click the Backend Health view of your application gateway to check if the probe is healthy.
  2. You should see that the Status is Healthy for the HTTPS probe.

Openssl Create Private Key

Next steps

To learn more about SSLTLS in Application Gateway, see Overview of TLS termination and end to end TLS with Application Gateway.