ssl-certificates

12y, 4d ago [edited]

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

Generate a private key and CSR
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

Generate a private key and CSR
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

Verify or install openssl package on host
Is openssl in your path?
```
which openssl
```
Install openssl if missing:
```
sudo apt-get install openssl
```

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}

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 -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr
```

This process will prompt for a passphrase to protect the private key.

Verify that the following files were created:
- <domain>.csr
- <domain>.key
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

SSL Offloading

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

The BigIP is capable of SSL Offloading. For SSL Offloading to occur we must load our domain's SSL certificate AND private key into the BigIP certificate store.

BigIP would then gain responsibility of creating an SSL tunnel or session between the Internet user and the edge of our corporate network. the VIP.

Optionally the traffic between the VIP and it's upstream nodes (internal network) may also be wrapped by SSL.

when should it be used?

If we want a central place to configure SSL for a pool of many nodes. Netadmins create a BigIP irule to manage SSL communications. The upstream nodes could run just plain HTTP (port 80). Less complicated configuration on each of the webserver nodes.

example

An example closer to home deploying Pyramid behind nginx proxy. Nginx in this case does the SSL Offloading for upstream waitress/paster nodes. The communication between users and Nginx could be SSL wrapped while the communication between nginx and the upstream waitress/paster nodes could remain 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.

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

Definitions

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.

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.

.. contents::

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:

.. code-block:: bash

sudo make-ssl-cert generate-default-snakeoil --force-overwrite
 
Request an internally signed cert
==================================

#. `Generate a private key and CSR`_
#. 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
==================================

#. `Generate a private key and CSR`_
#. 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
==================================

#. Verify or install openssl package on host

Is openssl in your path?

.. code-block:: bash
   
      which openssl
    
    Install openssl if missing:

.. code-block:: bash
    
      sudo apt-get install openssl
      
#. 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

.. code-block:: ini

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}

#. 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):

.. code-block:: bash

openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr

This process will prompt for a passphrase to protect the private key.

#. Verify that the following files were created:
  
   * <domain>.csr
   * <domain>.key

#. 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:

.. code-block:: bash

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:

.. code-block:: bash

# 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

SSL Offloading
==================================

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

The BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must 
load our domain's SSL certificate *AND* private key into the BigIP certificate
store.

BigIP would then gain responsibility of creating an SSL tunnel or session between
the Internet user and the edge of our corporate network. 
the VIP.

Optionally the traffic between the VIP and it's upstream nodes
(internal network) may also be wrapped by SSL.

**when should it be used?**

If we want a central place to configure SSL for a pool of many nodes.
Netadmins create a BigIP irule to manage SSL communications. The upstream
nodes could run just plain HTTP (port 80).  Less complicated configuration 
on each of the webserver nodes.

**example**

An example closer to home deploying Pyramid behind nginx proxy.
Nginx in this case does the SSL Offloading for upstream waitress/paster nodes.
The communication between users and Nginx could be SSL wrapped while the
communication between nginx and the upstream waitress/paster nodes could
remain 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.

.. code-block:: bash

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!

.. code-block:: bash

openssl x509 -noout -hash

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

..  code-block:: bash

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

Definitions
============

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.

Comments

Leave first comment to start a conversation!