Creating & Installing SSL/TLS Certificates

This document explains how to create an SSL Certificate and install it into the Web Console on the Enterprise Recon Master Server.

https_keyboard.jpg

There are five sections (you only really need the first two)

1: Quick SSL Overview, and the minimum you need to know to work with SSL Certificates.

2: Generating a Cert Signing Request (CSR) to send to Certification Authority (CA) and then installing the Signed Certificate.

    • i.e. Install proper Signed SSL Certificate

3: Creating a Demo CA to Sign Certificates, Installing Signed Certificate, Configuring Browser to accept certificates signed by that CA.

    • for testing purposes only (or may be acceptable as a valid certificate on an internal network)

4: Generating a Simple Self Signed Certificate, Installing it, Configuring Browser to Accept it.

    • similar to the default cert that's initially on ER2 for test purposes only

5: Introduction to  Asymmetric Cryptography, Public Key Infrastructure and Digital Certificates.

    • includes SSL vs TLS

  

         1                                                                                                                                                                                     

 

Quick SSL Overview

SSL Certificates are small data files that digitally bind a cryptographic key to an organization’s details. When installed on a web server, it activates the padlock and the https protocol and allows secure connections from a web server to a browser. Typically SSL is used to secure credit card transactions, data transfer and logins.

SSL Certificates bind together:

  • A domain name, server name or hostname.
  • An organizational identity (i.e. company name) and location.


An organization needs to install the SSL Certificate onto its web server to initiate a secure session with browsers. Once a secure connection is established, all web traffic between the web server and the web browser will be secure.

When a certificate is successfully installed on your server, the application protocol will change to HTTPS, where the ‘S’ stands for ‘secure’. Depending on the type of certificate you purchase and what browser you are using, the browser may show a padlock or green bar when you visit a website that has an SSL Certificate installed.

More: https://www.globalsign.com/en/ssl-information-center/what-is-an-ssl-certificate/

 

The minimum you need to know to work with SSL Certificates 

For an SSL Cert to function it requires 2 keys (the private key / public key pair)
It must be signed (even if just signed by itself)
and contains fields such as:-

Subject:
Issuer:
Not Before:
Not After:

Version:
Serial Number:

Public Key Algorithm:
Public Key:
Signature Algorithm:
Signature:

Typically the private key has it's own file the Key file and the other details go in the Cert file.

(for our purposes we mostly just look at the first four fields above)

The 'Not Before:' the 'Not After:' fields indicate the validity period for the cert.

So where is the Cert Name ???

First we need to understand that the Cert Name has multiple parts

Cert Name Attributes:-

C = Country Name: Use the two-letter code without punctuation for country, for example: US or UK.

ST = State or Province: Spell out the state completely; do not abbreviate the state or province name. For example: California, not CA

L = Locality or City: The city or town where the organization is headquartered spelled in full. For example: Mountain View, not Mt. View

O = Org Name: aka Company Name. If the company or department has an &, @, or any other symbol using the shift key in its name, the symbol must be spelled out or omitted, in order to enroll. Example: XY & Z Corporation would be XYZ Corporation or XY and Z Corporation.

OU = Organizational Unit: This can be used to identify the name of the department or organization unit making the request.

emailAddress = Email Address: strictly informational, but can be handy to identify the administrator when the certificate causes problems (e.g. when it expires).

CN = Common Name: For a Server Certificate this is the Host Name + Domain Name i.e. the fully qualified domain name (FQDN). It looks like "www.company.com" or "company.com"


Technically speaking, the only Name Attribute you must provide for an SSL certificate is the Common Name (CN)


All of the Name Attributes taken together are referred to as the Distinguished Name (DN)


So where is the Certificate Name ???

The Certificates DN (which includes the CN) is stored in it's 'Subject:' field,
the DN of the Certification Authority (CA) cert that signed this cert is stored in the 'Issuer:' field.

In a self signed certificate the 'Issuer:' & 'Subject:' fields are the same

 

To get a Certification Authority (CA) to sign a SSL Certificate, we need to send them the Certificate Details (including DN & public key) in the form of a Certificate Signing Request (CSR)

 

         2                                                                                                                                                                                     

 

Generating a Certificate Signing Request (CSR)
Sending the CSR to a Certification Authority (CA)
Verifying, then Installing the Signed Certificate in ER2

 

0: check DNS resolution

An SSL Certificate won't be of any use if the certificate name (FQDN) doesn't resolve to the IP of the ER Master Server

Create FQDN variable
[root@er-master /]# FQDN=master-server.my.lan
[root@er-master /]# echo $FQDN

master-server.my.lan

Note the colour codes:-
Blue indicates exactly what you need to type (and can be cut and pasted from here onto command line).
Green is for text you type but need to use your own values rather than copying the example from here.
Brown  shows output you can expect to see.

Run DNS test, does FQDN resolve?
ping -c1 $FQDN >/dev/null 2>&1 && (grep $FQDN /etc/hosts && echo "DNS test not valid as ping is resolving via /etc/hosts" || echo DNS OK) || echo DNS Fail

Run IP test, does FQDN resolve to correct IP?
ifconfig -a | grep $(ping -c1 $FQDN | head -n 1 | sed 's/[^(]*(\([^)]*\)).*/\1/') >/dev/null 2>&1 && echo IP OK || echo FQDN does not resolve to correct IP

 

1: Create the CSR (& private key)

Make a Directory to store CSR & keyfile
mkdir -p /opt/cert_request && cd /opt/cert_request

We will use the openssl tool to create the CSR (see https://www.openssl.org/docs/)

This will create the Cert's DN and it's public & private keypair
The DN & Public Key will go in the CSR to be sent to the CA.
The Private Key has it's own file and stays with us.

The Cert Name Attributes for the DN can be entered interactively or passed on the command line via the -subj switch.
(These examples will use variable $SUBJECT to populate -subj)

CC="2 letter country code"
ST="State or Province"
LOC="Locality or City"
EMAIL="email address of server admin"

FQDN="CN aka FQDN fully qualified domain name"
ORG="Organisation or Company name"
UNIT="Department or subdivision of Organisation"

SUBJECT="/CN=$FQDN/O=$ORG/OU=$UNIT/C=$CC/ST=$ST/L=$LOC/emailAddress=$EMAIL" 

Fill out the fields you want to use
FQDN="master-server.my.lan"
ORG="Groundlabs"
UNIT="Support"

Build the SUBJECT string (using just those fields you want included in the cert)
SUBJECT="/CN=$FQDN/O=$ORG/OU=$UNIT" 
echo "\"$SUBJECT\""

"/CN=master-server.my.lan/O=Groundlabs/OU=Support"

Create the CSR & Key File
openssl req -nodes -sha256 -newkey rsa:2048 -keyout sslkey.pem -out er2-master.csr -subj "$SUBJECT"

QuickCheck of CSR details
openssl req -in er2-master.csr -noout -subject

subject=/CN=master-server.my.lan/O=Groundlabs/OU=Support

N.B. If the above details aren't correct go back and fix them (rather than sending wrong info to CA)

Output all details
openssl req -in er2-master.csr -text

Output just the CSR text
cat er2-master.csr

 

2: Send the CSR text to your CA

e.g. Equifax, Geotrust, Verisign, GoDaddy etc...

Either attach the file er2-master.csr or paste the output from 'cat er2-master.csr'
into the form provided by your Certification Authority (CA)

The text should look like

-----BEGIN CERTIFICATE REQUEST-----
MIICjzCCAXcCAQAwSjEhMB8GA1UEAwwYbWFzdGVyLXNlcnZlci5jb3JtYWMubGFu
MRMwEQYDVQQKDApHcm91bmRsYWJzMRAwDgYDVQQLDAdTdXBwb3J0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApMeTFfvv7OANym48pvXS7uqGhkYZb3Uj
U/0IV7W/NvqbKJxtUWTjAhjLfoeXvHVBjBS0jFquQ75YvbaGOjF9oRowCeEia3WO
0LI+p/wsO6HmLkA8HkI8m+EI8Ve8RvQ2R+kiMS4q5LM+MB0erfekOkI3axZvPtB9
05pt2fI0l2newXGvXWoM4aXg6o72D7pnUIoYA0zqHtpH1Bb+RwEh594H7kbhDmmT
qQAp9udA5MOYl0/bCWeewvRjlP+Jln4xwYppi/qpPnxqIrPSQEN5iuNR+/82u6hC
giPU4zSNZFU6g9UQJPL/zMrnkWgPVVmeT/vlTxqzjijqKLSuJN+06QIDAQABoAAw
DQYJKoZIhvcNAQEFBQADggEBAE9X0PqHdLFSNXXWgcYyhaaxXTcn8gIhWnGpCEe+
zZdPI5B1PuesUq4pRgOn7zIdwV+rJWAR4A5Go8iuTrER53UBlQQzQ/ta1l8nv4k5
D4t3E5FI9TswOoGgo6MNN80cpSTkDPAAmHVNddnBjw9Kn6XD7vhkWNZ87xIAEhuO
A0/ZlFI5nWOooNm51tipsIzkJMydPYoPqTsxT2ocFBXEQQm9qV/qckEbZbwyccIm
Bdo6T6P5k99qXK/OlxZC11Q8Xxlb18R010MbC0UGUXMb2rK85IyPKXHWmEQtVa05
ts87ICpJidOZHxXWGJvdtuyGVxciTz/K2bFKpUL55lM73pc=
-----END CERTIFICATE REQUEST-----

If there is an option to select the type of file that you want returned then select PEM

 

3: N.B. Ensure you keep the sslkey.pem file safe as it contains your private key

chmod 400 sslkey.pem

 

4: Wait until CA returns a signed cert.

The cert may be in a file with extension .pem .crt .cer .key .der .p7b .p7c .pfx .p12
(containing a file of type PEM, PKCS7, DER or PKCS12)

 

5: Copy the returned signed cert file to ER Master Server location where you stored the sslkey.pem file

In this example the directory is /opt/cert_request/
& the cert filename is mycertfile.ext

Start ssh daemon on ER Master Server to allow file copy via ssh (scp or sftp)
[root@er-master /]# service sshd status || service sshd start

If you downloaded the certificate onto a UNIX / Linux workstation, 
the simplest way to send it to the ER Master is to scp it from the command line
[user@workstation ~]$ scp mycertfile.ext root@master-server.my.lan/opt/cert_request/

From Windows use an application that supports sftp or scp
e.g. WinSCP or Filezilla

FileZilla steps:-

Fill out the fields at the top of the window

Host: master-server.my.lan
Username: root
Password: <ER Master root PW>
Port: 22

Click Quickconnect button

Remote site: /

Change to /opt/cert_request
either by typing directly into the field or navigating the tree in pane below.
(you should see files er2-master.csr & sslkey.pem listed, if you are in the correct location)

Local site: C:\Users\<username>

Change to directory containing the Cert file from your CA

Right Click on the Cert file and select 'Upload'
(or drag file to files pane on remote side)

Optional, stop the ssh daemon on ER Master Server (unless it's configured to autostart anyway)
[root@er-master /]# chkconfig --list sshd  | grep :on >/dev/null || service sshd stop

 

6: Identify the file-type of the signed cert

cd /opt/cert_request
FILE=mycertfile.ext
file $FILE | grep text && grep BEGIN $FILE || echo $FILE is binary

Should output BEGIN statement or say that the file is a binary.

.pem .crt .key should be PEM (ASCII, will contain '—–BEGIN CERTIFICATE—–')
.der will be DER (binary file)
.cer may be either PEM or DER (PEM if it's ASCII, DER if binary)
.p7b .p7c are PKCS7 (ASCII, will contain '—–BEGIN PKCS7—–')
.pfx .p12 are PKCS12 (binary file)

Sometimes files will have the wrong extension type, you may need to test multiple options,
run some or all of the following until file-type is identified.

openssl x509 -in $FILE -inform pem -text 2>/dev/null | grep Subject: && echo 'format is PEM

openssl x509 -in $FILE -inform der -text 2>/dev/null | grep Subject: && echo 'format is DER'

openssl pkcs7 -print_certs -in $FILE 2>/dev/null | grep subject= && echo 'format is PKCS7'

openssl pkcs12 -in $FILE -clcerts -nokeys -info -password pass:'' 2>/dev/null | grep subject= && echo 'format is PKCS12'

 

7: having identified file type, convert / rename as necessary

PEM file, rename it to match what ER Master expects
mv $FILE sslcert.pem

DER file, convert to PEM
openssl x509 -inform der -in $FILE -out sslcert.pem

PKCS7, Export certs to PEM
openssl pkcs7 -print_certs -in $FILE | openssl x509 -out sslcert.pem

PKCS12, Export certs to PEM
openssl pkcs12 -in $FILE -clcerts -nokeys -nomac -password pass:'' -out sslcert.pem

 

8: check the cert details before installing

openssl x509 -in sslcert.pem -text | grep -A4 Issuer:

The Issuer should Match your CA
Check the dates are correct,
and that the CN matches your server's FQDN

N.B. sometimes a CA will insert the correct CN, but ignore other DN fields that you have requested.
Perhaps instead inserting whatever details they already have on file rather than what you specifically requested.
Go back to CA and ask for a new cert if you are not happy with what they have given you.

To output the full details
openssl x509 -in sslcert.pem -noout -text

Do the keys match? (are the public & private keys from the same matching pair)
openssl rsa -in sslkey.pem -noout -modulus | sum
openssl x509 -in sslcert.pem -noout -modulus | sum

The output should be the same from both

 

9: backup any previous cert installed

DIR=/var/lib/er2/ui
[ -f $DIR/sslcert.pem ] && chown root:root $DIR/sslcert.pem && chmod 400 $DIR/sslcert.pem && mv $DIR/sslcert.pem $DIR/sslcert.pem.$(date +%d%m%y)
[ -f $DIR/sslkey.pem ] && chown root:root $DIR/sslkey.pem && chmod 400 $DIR/sslkey.pem && mv $DIR/sslkey.pem $DIR/sslkey.pem.$(date +%d%m%y)

 

10: install the cert

DIR=/var/lib/er2/ui
cp sslcert.pem sslkey.pem $DIR/
chown erecon:erecon $DIR/*.pem
chmod 400 $DIR/*.pem
ls -l $DIR/ssl*.pem

 

11: activate cert by restarting ER2

/etc/init.d/er2-master restart

 

12: optional test that Cert is working by reading it from ER Master Server Port 443

FQDN=master-server.my.lan
echo | openssl s_client -showcerts -servername $FQDN -connect $FQDN:443 2>/dev/null | openssl x509 -text | grep -A4 Issuer:

The Issuer should Match your CA
Check the dates are correct,
and that the CN matches your server's FQDN

Check TLS & Cipher
echo | openssl s_client -showcerts -servername $FQDN -connect $FQDN:443 2>/dev/null | grep -A2 SSL-Session:

SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-SHA

 

         3                                                                                                                                                                                     

 

Building your own Certification Authority (CA)
Creating a Certificate Signing Request (CSR)
Using the CA to sign the CSR
Installing the Signed Cert in ER2
Adding the new CA to your Browser

*** N.B. this is a test / demo process NOT supported by Groundlabs ***

0: First Create the CA files

Create A Directory Structure for CA files
CA=/tmp/miniCA
mkdir -p $CA && cd $CA
mkdir -p certs crl newcerts private

Add a few default files
touch index.txt
[ -f crlnumber ] || echo "01" > crlnumber
[ -f serial ] || echo "01" > serial

Paste the whole block of code below onto command line
to create the ca.cnf file

cat << EOF > ca.cnf

[ ca ]
default_ca = miniCA

[ miniCA ]
certificate = ./cacert.pem
database = ./index.txt
private_key = ./cakey.pem
new_certs_dir = ./certs
default_md = sha256
policy = policy_match
serial = ./serial
default_days = 365

[policy_match]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

EOF

 

Check that it was created ok
cat ca.cnf

[ ca ]
default_ca = miniCA

[ miniCA ]
certificate = ./cacert.pem
database = ./index.txt
private_key = ./cakey.pem
new_certs_dir = ./certs
default_md = sha256
policy = policy_match
serial = ./serial
default_days = 365

[policy_match]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

 

1: Create root CA cert

Set the Values to be used in the DN
(In this example CN is the Cert Title rather than a FQDN)
FQDN="Certificate Authority"
ORG="Groundlabs Test CA"
UNIT="Support"

SUBJECT="/CN=$FQDN/O=$ORG/OU=$UNIT"

echo "\"$SUBJECT\""

openssl req -x509 -nodes -sha256 -newkey rsa:4096 -days 3652 -out cacert.pem -keyout cakey.pem -subj "$SUBJECT"
openssl x509 -in cacert.pem -text
chmod 400 cakey.pem


2: Create the CSR (& private key)

Create variables for subject line
FQDN="master-server.my.lan"
ORG="Groundlabs"
UNIT="Support"

SUBJECT="/CN=$FQDN/O=$ORG/OU=$UNIT"

openssl req -nodes -sha256 -newkey rsa:2048 -keyout sslkey.pem -out er2-master.csr -subj "$SUBJECT"

chmod 400 sslkey.pem

quick check CSR details
openssl req -in er2-master.csr -noout -subject

Subject=/CN=master-server.my.lan/O=Groundlabs/OU=Support

To output full CSR details
openssl req -in er2-master.csr -text


3: Create signed key

Use our CA config file & the CSR to sign cert and enable it for 10 years
openssl ca -config ca.cnf -days 3652 -in er2-master.csr -out sslcert.pem

View Cert Details
openssl x509 -in sslcert.pem -text | grep -A4 Issuer:


4: Install Cert & Restart ER2

cp sslcert.pem sslkey.pem /var/lib/er2/ui
chown erecon:erecon /var/lib/er2/ui/*.pem
chmod 400 /var/lib/er2/ui/*.pem
/etc/init.d/er2-master restart

5: Install CA into browser
(otherwise it will issue warnings etc...)

cat cacert.pem
(paste output into file on browser machine)

To add CA to Chrome
settings > show advanced settings > Manage Certificates > Authorities > Import > cacert.pem > Open > Trust this Certificate for identifying websites > OK > Finished

To add CA to Firefox
menu > Preferences > Advanced > Certificates > View Certificates > Authorities > Import > cacert.pem > Open > Trust this Certificate for identifying websites > OK > OK

 

         4                                                                                                                                                                                     

 

To create a Self Signed Cert

cd /tmp
FQDN=master-server.my.lan

SUBJECT="/CN=$FQDN"

openssl req -x509 -nodes -sha256 -newkey rsa:2048 -days 3652 -out sslcert.pem -keyout sslkey.pem -subj "$SUBJECT"

quick view basic details (Issuer, Validity, Name)
openssl x509 -in sslcert.pem -text | grep -A4 Issuer:

install cert

cp sslcert.pem sslkey.pem /var/lib/er2/ui
chown erecon:erecon /var/lib/er2/ui/*.pem
chmod 400 /var/lib/er2/ui/*.pem
/etc/init.d/er2-master restart

 

Install Cert (aka CA) into browser

cat sslcert.pem
(paste output into file on browser machine)

To add Cert to Chrome
settings> show advanced settings > Manage Certificates > Authorities > Import > sslcert.pem > Open > Trust this Certificate for identifying websites > OK > Finished

To add Cert to Firefox
menu > Preferences > Advanced > Certificates > View Certificates > Authorities > Import > sslcert.pem > Open > Trust this Certificate for identifying websites > OK > OK

 

         5                                                                                                                                                                                     

 

Introduction to Asymmetric Cryptography, Public Key Infrastructure and Digital Certificates

Encryption is the process of encoding a message or information in such a way that only authorized parties can access it. In an encryption scheme, the intended information or message, referred to as plaintext, is encrypted using an encryption algorithm, generating ciphertext that can only be read if decrypted.

An encryption key is a random string of bits created explicitly for scrambling and unscrambling data. Encryption keys are designed with algorithms intended to ensure that every key is unpredictable and unique. The longer the key built in this manner, the harder it is to crack the encryption code. An encryption key is used to encrypt, decrypt, or carry out both functions, based on the sort of encryption software used.

Symmetric key encryption uses the same cryptographic keys for both encryption of plaintext and decryption of ciphertext. The keys may be identical or there may be a simple transformation to go between the two keys. The keys, in practice, represent a shared secret between two or more parties that can be used to maintain a private information link. This requirement that both parties have access to the secret key is one of the main drawbacks of symmetric key encryption, in comparison to public-key encryption (also known as asymmetric key encryption).

Asymmetric cryptography, uses public and private keys to encrypt and decrypt data. The keys are simply large numbers that have been paired together but are not identical (asymmetric). One key in the pair can be shared with everyone; it is called the public key. The other key in the pair is kept secret; it is called the private key. Either of the keys can be used to encrypt a message; the opposite key from the one used to encrypt the message is used for decryption.

Many protocols like SSH, OpenPGP, S/MIME, and SSL/TLS rely on asymmetric cryptography for encryption and digital signature functions. It is used in software programs, such as browsers, which need to establish a secure connection over an insecure network like the internet or need to validate a digital signature.

For asymmetric encryption to deliver confidentiality, integrity, authenticity and non-repudiability, users and systems need to be certain that a public key is authentic, that it belongs to the person or entity claimed and that it has not been tampered with or replaced by a malicious third party. There is no perfect solution to this public key authentication problem.

A public key infrastructure (PKI), where trusted certificate authorities (CAs) certify ownership of key pairs and certificates, is the most common approach.

A CA issues digital certificates to entities and individuals after verifying their identity. It signs these certificates using its private key; its public key is made available to all interested parties in a self-signed CA certificate. CAs use this trusted root certificate to create a "chain of trust" -- many root certificates are embedded in Web browsers so they have built-in trust of those CAs. Web servers, email clients, smartphones and many other types of hardware and software also support PKI and contain trusted root certificates from the major CAs.

Along with an entity’s or individual’s public key, digital certificates contain information about the algorithm used to create the signature, the person or entity identified, the digital signature of the CA that verified the subject data and issued the certificate, the purpose of the public key encryption, signature and certificate signing, as well as a date range during which the certificate can be considered valid.

It is this Digital Certificate (containing a Web Server's Identity and Public Key) that it typically referred to as an 'SSL Cert'

Further Reading:-

http://searchsecurity.techtarget.com/definition/asymmetric-cryptography
http://searchsecurity.techtarget.com/definition/PKI
https://www.comodo.com/resources/small-business/digital-certificates-intro.php


For our purposes we don't need to be experts in Asymmetric Cryptography & Public Key Infrastructure

We simply need to know how to:-

  • Generate the Public & Private Keys
  • Add the required Server & Organisation Identity information to the Cert
  • Bundle the Identity Info and the Public key into a Certificate Signing Request (CSR)
  • Send The CSR to a Certification Authority (CA)
  • Wait for the CA to send us a Signed Cert
  • Install the Signed Cert (including Identity + Public Key) and the Private Key into our Web Server
  • Activate the Newly Installed Cert in the Web Server

 (hopefully these are all covered in sufficient detail in previous sections above)

 

SSL vs TLS

TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are protocols that provide data encryption and authentication between applications and servers in scenarios where that data is being sent across an insecure network. The terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is in fact the predecessor of the other.  SSL 3.0 served as the basis for TLS 1.0 which, as a result, is sometimes referred to as SSL 3.1.

Traditionally Cryptographic Certs on Web Servers are referred to as 'SSL Certs', because initially SSL was the only protocol used, nowadays TLS is more likely used. Actually the Cert (which contains the Web Server's Identity and Public Key) doesn't have anything to do with which protocol will be used.

Basically 'SSL Cert' is a misnomer, 'Public Key Cert' or 'Identity Cert' would be better names, some people now use the term 'TLS/SSL Cert'


Whether SSL or TLS is used will be determined by how the web server and web browser have been configured.

Enterprise Recon is currently configured to use TLSv1 by default. It can be configured to require TLS v1.2
We're not currently forcing TLSv1.2 due to the fact that IE10 and below don't have support for it enabled by default
(hence many of our customers would see our product is broken rather than going to IE's Tools/Internet Options/Advanced/Security and enabling TLSv1.2)

Further Reading:-

https://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html

 

All information in this article is accurate and true as of the last edited date.

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.