TLS Certificate Generation

The following describes how to generate new TLS certificates in EJBCA Enterprise Cloud either using elastic or public IP, or using a custom domain.

The TLS certificate allows external SSL connections to the server. Setting the correct IP and DNS names will allow the server to respond without browser errors once the ManagementCA is trusted.

Including the public hostname in the TLS certificate (using the -p option) allows remote connections to EJBCA via HTTPS as well as the ClientToolBox.

HINT If you powered off your Azure instance and want to regenerate your TLS certificates for your new IP, use the -p option. For example, /opt/PrimeKey/support/new_tls_cert.sh -p.

NOTE A total of 6 DNSNames and 3 IPs can be included in the TLS certificate. The local IP (local-ipv4) and hostname (local-hostname) are always included when using the -p option. This leaves 4 DNSName and 1 IP Address spaces remaining. If you do not want the local-hostname and local-ipv4 in your public facing certificate, specify each DNS and IP name you would like using the -d and -i options, omitting the -p. 

Using the script without the -p option and with -d <DNSName>, will make the DN of the certificate the first DNSName specified.

Options

Using Assigned or Public IP

EJBCA Cloud comes with a script to be able to easily generate new TLS certificates whenever the public IP is changed. The Public IP can change whenever a node is shut down, if a static IP is not assigned to the instance. A Public IP is the equivalent of a DHCP public IP address. 

As detailed in the hint above, if you want to regenerate or renew the TLS certificate on the node, use the -p option with no other options. It will grab all of the public info and regenerate the certificate.

To generate new certificates using the Elastic or Public IP, do the following:

1. Using the SSH key that you selected when procuring the instance, SSH into the EJBCA Cloud instance using the username that was chosen at instance launch time. In this example, we are using azure-user:
   

   # ssh azure-user@<public-ip>

   CODE
2. Run the command sudo su to get elevated privileges:
   

   # sudo su

   CODE
3. Change to the /opt/PrimeKey/support directory.
4. Run the new_tls_cert.sh script with the -p option. 
   

   # cd /opt/PrimeKey/support
   # ./new_tls_cert.sh -p

   CODE
   
5. New certificates will be generated and the current certificates replaced. These will then be rotated into place and you will be prompted to restart Apache.
   NOTE When using a public IP, this script will need to be run each time the instance is powered down. It will not be affected on reboots, but when the instance is powered down and Azure releases the public IP assigned to it back into the pool.
   For more information, refer to Azure Documentation to Add, change, or remove IP addresses for an Azure network interface.

Using Custom Domain

To generate new certificates using a custom domain, do the following:

1. Using the SSH key that you selected when procuring the instance, SSH into the EJBCA Cloud instance using the username selected upon provisioning.
2. Run the command sudo su to get elevated privileges:
   

   # sudo su

   CODE
3. Change to the /opt/PrimeKey/support directory.
4. Run the new_tls_cert.sh script followed by your domain to generate new certificates with the current Public or Elastic IP and your custom DNS value. The following example uses the domain pki.sample.com and the IP address 1.2.3.4. When using this method, it is recommended to assign a dedicated elastic IP before running this command, but not required:
   

   # cd /opt/PrimeKey/support
   # ./new_tls_cert.sh -d pki.sample.com -i 1.2.3.4 -p -v

   CODE
   Options used in the command:
   -d: To add a custom domain to the certificate. 
   -i: To specify a custom IP address. 
   -p: To add the nodes public IP information assigned to it by AWS automatically. 
   -v: For verbose output to show all of the domains being added to the certificate.
5. In the output below, with the verbose option, we see that the first and second FQDNs are the public and internal FQDNs from Azure.
   The third FQDN is pki.sample.com as specified with -d. The same principles apply to the IP addresses as well.
   
6. New certificates will be generated and the current certificates replaced. These will then be rotated into place and the script will prompt to restart Apache.
   If using a custom domain name with an Elastic IP, this script should only need to be run once since an Elastic IP should never change.
7. We can now see the custom information captured in the SAN of the certificate. You may need to restart your browser or clear its cache to load the new certificate, accept the browser warning if promoted and view the certificate SAN details.