Generate a Self-Signed Certificate or a Certificate Signing Request

The creation and use of new SSL certificates is a part of establishing encrypted communications at most customer sites. This involves using signed certificates from an authority, operated or contracted by our customers. SSL certificates are used by the web server daemons on your server. They allow a Certificate Authority to vouch for your authenticity. This is designed to prevent an unauthorized user to intercept your browser's web page requests as they are sent from your computer to the web server, and pretends to be the webpage itself for malicious purposes such as stealing credit card numbers, identity, etc.

A Certificate Authority (CA) is someone that everyone on the internet or intranet trusts. It confirms the authenticity of the website and informs the user's browser of its authenticity. The process is pretty simple.

• You start by creating a key for your server. This is your server's personal identifier and is unique to your server. As an analogy, think of it as your server's Birth Certificate. Then, you can take this key to generate a Certificate Signing Request (CSR). A CSR is brought to a CA as a request to apply for a Digital Identity Certificate (CRT). A CRT is sort of like an ID card that says who you are.
• For servers connected to the internet (public-facing), this will typically be an internet company like Symantec, GoDaddy, Digi-cert, etc.
• For servers on an intranet (internal network), some larger companies might have their own CA to vouch for the legitimacy of their internal webpages to their internal customers.
• The CA takes the CSR which contains the unique key for your server and generates a CRT file for the requester.
• The CRT file is placed on the server and plugged into the web server configuration.
• Now, when a user requests a website from the server, the digital identity certificate is handed out to users as part of the request. The user's browser will use the CRT to ask the CA to confirm the server prior to loading the page. This is done automatically in the background by the browser. It also add the lock icon in your browser confirming that you have a secure and verified connection to the real server.
  Note: There is an alternative to the CA process known as a Self Signed Certificate. Instead of a third party confirming your server's authenticity, your server validates itself.

  Server: I'm me.

  Browser: Says who? Server: Says me!"

  This is good in that if your browser has been to the server and saved the self signed certificate in the past, and someone attempts to attack your browser, it will return that the certificate does not match.

  With this method, you do not have a third-party confirming your server for the first time when the browser first saves the certificate, or subsequent times. This makes it more vulnerable.

Commonly, there are two scenarios:

1. Generate a Private Key and a Self-Signed Certificate
2. Generate a Private Key and a Certificate Signing Request (CSR) for a Certificate Authority

You need to provide the web server(s) the key and crt in order to allow https webpages from your server. SevOne NMS 5.7.2 and up only use nginx.

nginx certificate and private key can be found in /secrets/nginx/nginx.crt and /secrets/nginx/nginx.key respectively.

Generate key & certificate

openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout server.key -out server.crt

The output prompts for a Distinguished Name (DN)which is general information about the web server and the actual answers for a self-signed certificate do not matter too much.

Generate CSR

openssl req -nodes -sha256 -days 365 -newkey rsa:2048 -keyout server.key -out server.csr

An extension to the X.509 specification called Subject Alternative Name (SAN) allows for the definition of multiple host names on an SSL certificate. SANs are replacing common names on SSL certificates, and as of Google Chrome version 58, it is the only extension used to match the domain name and site certificate. A CSR can be generated with any number of SANs by following the method below.

1. Create a configuration file named san.cnf
2. Using a text editor of your choice, copy the following text into it, replacing the SevOne info in each line of the req_distinguished_name section with the appropriate information for your SSL certificate.
   Example

   [ req ]
   default_bits = 2048
   distinguished_name = req_distinguished_name
   req_extensions = req_ext
   default_days = 365
   [ req_distinguished_name ]
   countryName = US
   stateOrProvinceName = Delaware
   localityName = Newark
   organizationName = SevOne
   organizationalUnitName = Support
   emailAddress = support@sevone.com
   commonName = www.sevone.com
   [ req_ext ]
   subjectAltName = @alt_names
   [alt_names]
   DNS.1 = www.sevone.com
   DNS.2 = support.sevone.com
   DNS.3 = portal.sevone.com

   Note:

   • A commonName must still be specified, and can match a subjectAltName.
   • In this example, three alt_names are specified, meaning that the SSL Certificate must be valid for all three hostnames.
   • There can be any number of alt_names, just add/remove DNS.# lines as needed.
3. Run the openssl command with the -config flag, and specify the san.cnf file.
   

   openssl req -out server.csr -newkey rsa:2048 -nodes -keyout server.key -config san.cnf

   Note: You will be presented with input prompts for each item under req_distinguished_name, and you must re-enter the values.

   Warning: Do not accept default values as it will result in an error.

   Example of output

   
   openssl req -out server.csr -newkey rsa:2048 -nodes -keyout server.key -config san.cnf
   

   
   Output:
   Generating a 2048 bit RSA private key
   ...........................................................................+++
   ......................+++
   writing new private key to 'server.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.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   US []:US
   Delaware []:Delaware
   Newark []:Newark
   SevOne []:SevOne
   Support []:Support
   support@sevone.com []:support@sevone.com
   www.sevone.com []:www.sevone.com

The CSR and key generated by this method will include the SANs you have specified. They can be used to obtain, verify, and install an SSL through the normal methods described in this guide.

Using the commands below, verify that the output matches.

Verify certificate commands

openssl rsa -noout -modulus -in server.key | openssl md5;

openssl x509 -noout -modulus -in server.crt | openssl md5;

The output should look something like the following and must be identical for both commands.

(stdin)= 93b826c032ab9358efc88da0a744dc79

Files must be moved to an appropriate location.

From the NMS container, restart nginx for the new certificate to take effect.

sudo podman exec -it nms-nms-nms /bin/bash

supervisorctl restart nginx

If the customer is using an intermediate certificate, you will need to include the following in the normal server.crt. It is important to maintain the order in the command - server hash must be followed by the intermediate hash.

cat server.crt intermediate.crt > server.crt.new

Generate a CSR from an existing private key

openssl req -key server.key -new -out server.csr

Generate a CSR from an existing certificate and private key

openssl x509 -in server.crt -signkey server.key -x509toreq -out server.csr

Generate a Self-Signed Certificate from an existing private key

openssl req -x509 -sha256 -days 365 -new -key server.key -out server.crt

Decrypt a private key

openssl rsa -in encrypted.key -out decrypted.key

Decrypt a CSR

openssl req -in server.csr -noout -text

• http://www.thegeekstuff.com/2009/07/linux-apache-mod-ssl-generate-key-csr-crt-file/
• https://en.wikipedia.org/wiki/Certificate_signing_request
• https://en.wikipedia.org/wiki/Public_key_certificate
• https://en.wikipedia.org/wiki/Certificate_authority
• https://en.wikipedia.org/wiki/Self-signed_certificate
• https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs
• https://www.openssl.org/docs/man1.0.2/man1/
• https://support.google.com/chrome/a/answer/7391219?hl=en
• https://support.citrix.com/article/CTX227983
• https://support.dnsimple.com/articles/what-is-ssl-san/