Certificate Management 1.0

How we manage SSL certificates


There are a number of steps involved in creation of SSL certificates and it is important that we employ a maintainable and consistent and secure process.


  • FQDN for host
  • Shell access to host server
  • Any Server Alternate Names (SAN) These will be needed when creating the cert
  • The private key to be used with this cert (created with CSR)
  • A certificate creation entity. In our case incommon at https://cert-manager.com/customer/InCommon


  1. Create a Certificate Signing Request (CSR) for the server. This also creates a local private key

    openssl req -new -newkey rsa:2048 -nodes -keyout servername.key -out servername.csr

This can be created anywhere the SSL tools are installed. Archive the private key and CSR.

  1. Log into InCommon. Use the CSR to request a certificate, applying any alternate names to the request. This will likely involve cutting and pasting the CSR into a web form

  2. Have the certificate approved

  3. Download the certificate (.cer file) from incommon, choosing the appropriate option for the cert

    • Certificate (w/chain), PEM encoded
    • Certificate only, PEM encoded
    • PKCS#7, PEM encoded
    • PKCS#7
    • Root/intermediate(s) only, PEM encoded
    • Intermediate(s), Root only, PEM encoded

The certificate must be encrypted into an eyaml file using the private key of the Pupper server. USE WHATEVER PROCESS THAT WE DEVELOP FOR MANAGING KEYS THAT S&C APPROVES

  1. Upload the cert and private key to the Puppet server. Encrypt the ..key and with eyaml

    eyaml encrypt -f servername.csr -o block ????????

  2. Download the encrypted cert and key from the Puppet server and store the encrypted cert and private key in the node files for the server in Puppet (see syntax below)

  3. Install certificate and private key on server and confirm functionality. Be sure to delete any other copies of the private key. The key can be regenerated from the CSR. This leaves us with the only other copy of the certificate and private key stored in eyaml format in GitHub

  4. Add certificate information to SSL Key Minder once the certificate has been deployed. SSL Key Minder actively checks the certs on their active ports using the Systools servers. Tool is at https://systools.oit.ncsu.edu/tools-bin/sslkey-status

  • Select “Add record”. As the system actively checks the certs, the TEST HOST and TEST PORT must be valid and reachable through any firewalls from the test servers so that the certificate can be accessed. Fields
  • ID - usually common name, unique identifier (42 character limit)
  • TEST HOST - FQDN of hostname where cert is installed* TEST PORT - service port used by certificate (i.e 443)
  • SNI HOSTNAME - usually left blank, unless you have one or most certificates where the CN is different from the name of the server. Occasionally needed on shared servers.
  • KEY CONTACT - email of group responsible for key/cert

Searching : The Search field uses ID, TEST HOST and SNI HOSTNAME content when searching for a key

Summary of commands

  • Creating the key and certificate signing request (csr) openssl req -new -nodes -keyout ./proxy-dev-vip.oit.ncsu.edu.key -out ./proxy-dev-vip.oit.ncsu.edu.csr -config proxydev100.openssl.cnf

Convert certs to eyaml format

  1. Upload files to pm00.oit.ncsu.edu:/tmp
  2. Run /opt/puppetlabs/puppet/bin/eyaml
  3. Download encrypted eyaml files to local host
  4. Add these encrypted stanzas to the node file for the host

Syntax of encrypted cert and key to be included in node description file

(located in oit_linux/data/nodes/.eyaml)

# signing cert and key 
# certificate
oit_linux::profile::<profilename.pp>::certificate: >
    … (remainder of cert)

# private SSL key for server
oit_linux::profile::<profilename.pp>::private_key: >
    … (remainder of key)

stunnel certificate specifics

The certificate as it received from inCommon must be modified before being installed

The certificate file is made up of multiple certificates The contents looks like this :

  • root certificate
  • AddTrust certificate
  • xxxxTrust certificate
  • InCommon certificate
  • server certificate

The production certificate must have the server certificate as the first certificate in the file (the bottom cert must be moved to the top)

  • server certificate
  • root certificate
  • AddTrust certificate
  • xxxxTrust certificate
  • InCommon certificate
Edit me