Login or register    

SSL Certificates

We use certificates to certify some of our domain names. The certificate is used to build trust and prove an identity.

A certificate builds trust because of the "background check" involved during procurement.

The integrity of our identity is proven because only we have the private key. The private key may be used to generate a CSR (Certificate Signing Request). The CSR may be provided to a 3rd party to generate and sign us a certificate.

The sole ownership of a private key prevents both man-in-the-middle attacks and domain-name identity spoofing in regards to SSL.

Create a snakeoil cert for testing

Even the 'minimal' flavour of Ubuntu has ssl-cert package pre-installed.

The files are auto-generated and installed here:

  • /etc/ssl/certs/ssl-cert-snakeoil.pem
  • /etc/ssl/private/ssl-cert-snakeoil.key

Regenerate snakeoil certs, if needed, with the following command:

sudo make-ssl-cert generate-default-snakeoil --force-overwrite

Request an internally signed cert

  1. Generate a private key and CSR
  2. send an email to Netadmins:
    • attach the CSR (NOT THE PRIVATE KEY)
    • provide the domain name desired for certification
    • ask for an internally signed CV CA certificate

Netadmins will respond back with the certificate.

Request an externally signed cert

  1. Generate a private key and CSR
  2. send an email to Netadmins:
    • attach the CSR (NOT THE PRIVATE KEY)
    • provide the domain name desired for certification
    • ask for an externally signed GoDaddy CA certificate

Netadmins will respond back after procurement with the certificate.

Generate a private key and CSR

  1. Verify or install openssl package on host

    Is openssl in your path?

    which openssl

    Install openssl if missing:

    sudo apt-get install openssl
  2. Create a file using the following template.

    Only the first line in the file (siteName = ) should be altered to match the domain name intended for certification. The filename should be the domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl

    siteName = secure.foxhop.net
    r = .
    [ req ]
    default_bits = 2048
    default_keyfile = ${siteName}.key
    distinguished_name = req_distinguished_name
    prompt = no
    [ req_distinguished_name ]
    C = US
    ST = CT
    L = New London
    O = Foxhop.net
    OU = Foxhop.net, New London
    CN = ${siteName}
  3. Generate a private key and a CSR for the host to be certified by using the template that we generated above; For example (secure.foxhop.net):

    openssl req -new -sha256 -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr
    # optional if you don't want to use a template ...
    #openssl req -new -sha256 -nodes -newkey rsa:2048 -keyout secure.foxhop.net.key -out secure.foxhop.net.csr
This process will prompt for a passphrase to protect the private key.
  1. Verify that the following files were created:
    • <domain>.csr
    • <domain>.key
  2. Store these details in a pass or keepass entry:
    • document the private key's passphrase in the password field
    • on the "Advanced" attach the tmpl, csr, key, and crt files

View the CSR data

We may want to validate the data in a CSR before submission for certification. To display a CSR's data to standard out, run the following command:

openssl req -in secure.foxhop.net.csr -noout -text

Remove passphrase from a private key

We need to remove the passphrase from the openSSL private key for use in deployment; Otherwise everytime the webserver is restarted it will prompt for the keys password.

Example command:

# make a copy
cp secure.foxhop.net.key secure.foxhop.net.key.orig
# strip passphrase
openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key
# clean up orig after testing
rm secure.foxhop.net.key.orig

TLS Offloading

TLS Offloading is the practice of using a proxy or load balancer to manage the TLS certificates, keys, and sessions for none or many upstream nodes.

Nginx, HAProxy, or BigIP are some of the load balancers capable of TLS Offloading. The load balancer must have access to both the domain's TLS certificate AND private key.

The load balancer gains responsibility of creating an TLS session (tunnel) between the Internet user and the edge of our network.

Optionally the traffic between the between the load balancer and upstream nodes (internal network) may also be wrapped by TLS.

when should it be used?

If you want a central place to configure TLS for a pool of many nodes. The upstream nodes could run just plain HTTP (port 80). Less complicated configuration on each of the webserver nodes.


An example closer to home would be deploying Pyramid behind Nginx proxy. Nginx in this case does the TLS Offloading for upstream waitress/paster nodes.

The communication between users and Nginx is TLS wrapped while the communication between Nginx and the upstream waitress/paster nodes remains plain http. Many times we can get away with this because the paster nodes are bound and listening only to localhost, thus "firewalled" from the rest of the network.

Verify SSL chain

Run this command and paste in your signed certificate for your host.

cat *.crt | openssl x509 -noout -issuer_hash

Document the resulting hash.

Then make sure that hash exist somewhere in the certificate chain, by running this command on each cert in the chain until you find a match. If you don't find a match you are using the wrong chain!

openssl x509 -noout -hash

You can also use this command to get information about the SSL chain:

openssl s_client -connect <put-domain-name-here>:443

Verify Certificate Subjects

In this story I have a certificate which has a subject and a few other alternative subjects. To list the other domains the certificate protects, look for "Subject Alternative Name" from the output of this command:

openssl x509 -noout -text -in example.com.crt

Verify relation between csr, crt, and key

Oops you mixed up a bunch of files, this is how to determine if a given key/csr/crt are related to each other.

openssl x509 -noout -modulus -in example.com.crt | openssl md5
openssl rsa -noout -modulus -in example.com.key | openssl md5
openssl req -noout -modulus -in example.com.csr | openssl md5


Transitive Trust
A trusts B, B trusts C, therefore A may trust C
Self-signed Certificate
This certificate was signed by the organization who created it.
Snakeoil Certificate
A "snakeoil" self-signed cert is a great example of a singular identity certifying itself. Outsiders may not trust a snakeoil cert because it lacks is not attached to a domain name. Snakeoil certs are excellent for testing! """I Trust myself"""
Internally Signed Certificate
An "internal" certificate signed by the Classified Ventures (CV) Certificate Authority (CA) provides trust within the company. Employees of CV may trust an internal cert because it has meta-data and is attached to a domain name. The Internet will not trust an internal cert because the CV CA itself was not certified by a trusted outside identity. From inside the organization, this is a signed cert. From outside the organization this is a self-signed cert. Internal certs are excellent for internal only servers and services! """Employees trust the CV CA, CV CA trusts my-server, therefore employees may trust my-server."""
externally signed certificate
An "external" certificate is signed by a trusted identity outside of the requesting organization. There are many trusted identities who perform this service. This is a popular choice among Internet websites because many of the trusted external Certificate Authorities have their keys pre-loaded into web browsers. The pre-loaded key relieves friction on the end-users, they do not need to manually review or install anything. """You trust XYZ org, XYZ org trusts my-server, therefore you may trust my-server."""
private key
This is the very sensitive and private portion of the certificate that must remain a secret in order for the SSL wrapped service to remain secure.

How I manage requesting certs


export DOMAIN=$1

# create a directory to hold this domain.
mkdir $DOMAIN

# change directory to new directory.

# create private key and csr.
openssl req -new -sha256 -config ../openssl-tls-template.tmpl -out $DOMAIN.csr

# remove passphrase from private key.
openssl rsa -in $DOMAIN.key -out $DOMAIN.key

# spit out public key.
openssl rsa -in $DOMAIN.key -pubout > $DOMAIN.key.pub

# output csr file info
openssl req -in $DOMAIN.csr -noout -text

cat $DOMAIN.csr


r = .

[ req ]
default_bits = 2048
default_keyfile = ${DOMAIN}.key
distinguished_name = req_distinguished_name
prompt = no

[ req_distinguished_name ]
C = US
L = New London
OU = ${DOMAIN}, New London

Then to create a new private key and csr I do this:

bash create_keys_and_csr.sh secure.foxhop.net

letsencrypt manual

sudo /path/to/bin/letsencrypt certonly --agree-tos --manual-public-ip-logging-ok --manual --domain www.foxhop.net

View expiration date from CLI

If you have the certificate on the filesystem you can do this:

openssl x509 -noout -dates -in example.com.crt

If the cert is currently being used by a webserver you can do this:

echo | openssl s_client -connect 2>/dev/null | openssl x509 -noout -dates
 notBefore=Jun 25 15:26:24 2015 GMT
 notAfter=Jun 24 15:26:24 2016 GMT

Another example, like if the cert is in a Java keystore:

keytool -list -v -keystore /etc/ssl/server.p12 -storetype PKCS12 | grep Valid


Leave a comment

Please login or register to leave a comment!