Generate Ssl Key And Chain

 
Generate Ssl Key And Chain Rating: 4,1/5 6377 reviews
  1. Creating a.pem with the Entire SSL Certificate Trust Chain Log into your DigiCert Management Console and download your Intermediate (DigiCertCA.crt), Root (TrustedRoot.crt), and Primary Certificates (yourdomainname.crt).
  2. Self-signed ssl certificates can be used to set up temporary ssl servers. You can use it for test and development servers where security is not a big concern. Use the form below to generate a self-signed ssl certificate and key.

Generating a KeyStore and TrustStore

During SSL setup, if you’re on a Windows-based system, there may be times when you need to generate your Certificate Signing Request (CSR) and Private key outside the Windows keystore. This may be useful, for example, if you want to backup your SSL Certificate or import it to multiple servers.

The following sections explain how to create both a KeyStoreand a TrustStore (or import a certificate into an existing TrustStoresuch as the default Logical Host TrustStore in the location:


where <c:JavaCAPS> isthe directory where Java CAPS is installed and <MyDomain> isthe name of your domain. The primary tool used is keytool, but openssl isalso used as a reference for generating pkcs12 KeyStores.

For more information on openssl andavailable downloads, visit the following web site:

http://www.openssl.org.

Creating a KeyStore in JKS Format

This section explains how to create a KeyStore using theJKS format as the database format for both the private key, and theassociated certificate or certificate chain. By default, as specifiedin the java.security file, keytool usesJKS as the format of the key and certificate databases (KeyStore andTrustStores). A CA must sign the certificate signing request (CSR).The CA is therefore trusted by the server-side application to whichthe Adapter is connected.

Note –

Itis recommended to use the default KeyStore


where <c:JavaCAPS> isthe directory where Java CAPS is installed and <MyDomain> isthe name of your domain.

To Generate a KeyStore

  1. Perform the following command.


  2. Once prompted, enter the information required to generatea CSR. A sample key generation section follows.


    If the KeyStore password is specified, then the password mustbe provided for the adapter.

  3. Press RETURN when prompted for the key password (thisaction makes the key password the same as the KeyStore password).

    This operation creates a KeyStore file clientkeystore in the current working directory. You must specify a fullyqualified domain for the “first and last name” question.The reason for this use is that some CAs such as VeriSign expect thisproperties to be a fully qualified domain name.

    Thereare CAs that do not require the fully qualified domain, but it isrecommended to use the fully qualified domain name for the sake ofportability. All the other information given must be valid. If theinformation cannot be validated, a CA such as VeriSign does not signa generated CSR for this entry.

    This KeyStore containsan entry with an alias of client.This entry consists of the generated private key and information neededfor generating a CSR as follows:


    This command generates a certificate signing request which canbe provided to a CA for a certificate request. The file client.csr contains the CSR in PEM format.

    Some CA (one trusted by the web server to which the adapteris connecting) must sign the CSR. The CA generates a certificate forthe corresponding CSR and signs the certificate with its private key.For more information, visit the following web sites:

    or

    If the certificate is chained with the CA’scertificate, perform step 4; otherwise, perform step 5 in the followinglist:

  4. Perform the following command.


    The command imports the certificate and assumes the client certificateis in the file client.cer and theCA’s certificate is in the file CARoot.cer.

  5. Perform the following command to import the CA’scertificate into the KeyStore for chaining with the client’scertificate.


  6. Perform the following command to import the client’scertificate signed by the CA whose certificate was imported in thepreceding step.


    The generated file clientkeystore containsthe client’s private key and the associated certificate chainused for client authentication and signing. The KeyStore and/or clientkeystore, can then be used as the adapter’sKeyStore.

Creating a KeyStore in PKCS12 Format

This section explains how to create a PKCS12 KeyStoreto work with JSSE. In a real working environment, a customer couldalready have an existing private key and certificate (signed by aknown CA). In this case, JKS format cannot be used, because it doesnot allow the user to import/export the private key through keytool. It is necessary to generate a PKCS12database consisting of the private key and its certificate.

The generated PKCS12 database can then be used as the Adapter’sKeyStore. The keytool utility iscurrently lacking the ability to write to a PKCS12 database. However,it can read from a PKCS12 database.

Note –

There are additional third-party tools available for generatingPKCS12 certificates, if you want to use a different tool.

X force key generator free download. For the following example, openssl isused to generate the PKCS12 KeyStore:

Generate Ssl Key And Chain Password


The existing key is in the file mykey.pem.txt in PEM format. The certificate is in mycertificate.pem.txt, which is also in PEM format. A textfile must be created which contains the key followed by the certificateas follows:


This command prompts the user for a password. The password isrequired. The KeyStore fails to work with JSSE without a password.This password must also be supplied as the password for the Adapter’sKeyStore password.

This command also uses the openssl pkcs12 commandto generate a PKCS12 KeyStore with the private key and certificate.The generated KeyStore is mykeystore.pkcs12 withan entry specified by the myAlias alias.This entry contains the private key and the certificate provided bythe -in argument. The noiter and nomaciter optionsmust be specified to allow the generated KeyStore to be recognizedproperly by JSSE.

Creating a TrustStore

For demonstration purposes, suppose you have the followingCAs that you trust: firstCA.cert, secondCA.cert,thirdCA.cert, located in the directory C:cascerts. You can create a new TrustStore consistingof these three trusted certificates.

To Create a New TrustStore

  1. Perform the following command.


  2. Enter this command two more times, but for the secondand third entries, substitute secondCA and thirdCA for firstCA.Each of these command entries has the following purposes:

    • The first entry creates a KeyStore file named myTrustStore in the current working directoryand imports the firstCA certificateinto the TrustStore with an alias of firstCA.The format of myTrustStore is JKS.

    • For the second entry, substitute secondCA to import the secondCA certificateinto the TrustStore, myTrustStore.

    • For the third entry, substitute thirdCA to import the thirdCA certificateinto the TrustStore.

    Once completed, myTrustStore is available to be used as theTrustStore for the adapter.

-->

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

Generate Ssl Certificate Using Openssl

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

Generate Ssl Key And Chain Key

  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 Generate Key

Next steps

Ssl Chain File

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