Securing multiple systems with Letsencrypt

Securing Multiple Systems with LetsEncrypt

A few weeks ago we showed you how to secure your Digium Switchvox with a free SSL Certificate from LetsEncrypt.

Now that LetsEncrypt has release wildcard certificates, I thought that now would be a good time to update our process a little to add some additional flexibility. After all, it is highly likely that you have more then 1 device or appliance that you need to secure with a valid SSL Certificate.

Wild Wild West

Starting Feb 27 2018, LE has enabled wild card certificates. *.domain.com can not be yours! well sort of.

What good is generating a wildcard certificate if certbot and acme.sh will install the certs for us? Well it allows us to deploy the same certificate on multiple systems. Some of which might not have direct access from the outside world.

Creating your certificate

Updating acme.sh

Lets start by making sure we have a current version of acme.sh

acme.sh --upgrade --auto-upgrade=1

You may be warned to install socat,

One macOS

brew install socat

Ubuntu/Debian

apt-get install socat

Then repeat the upgrade command

Issuing a new certificate

Now that we have the new version of acme.sh, lets make our first wild card certificate.

Wildcard configurations require that we have the use of a DNS server to configure the response, if you are using one of the supported DNS servers, be sure to add your credentials to your environment variables before proceeding.

acme.sh --issue -d *.voice1.me --dns dns_he

Getting renewed certs to deploy.

I shouldn’t have to state this, but I feel I need to. You must protect your private key! This typically means that you should not transmit it in a manner the exposes it to unauthorized individuals. This includes transmitting the private key via email. Because email can be transmitted as unencrypted.

Fishing Hooks

In our example here we will use the acme.sh script again, with DNS services. This allows us to automate our task and create a certificate for domains and hosts that we might not yet have connected to the internet.

To make this magic work we will use the some of the special “hooks” from acme.sh. specifically we will be using the –deploy-hook option to achieve our desired effect.

The Hardway

The hardway, is what most people actually settle on. Manually copying the files from your local system to the intended destination. We won’t cover how to copy files from system to system. But please, use SFTP, WinSCP, scp or some other encrypted connection when doing to.

Working Smarter

The –deploy-hook is intended to be a set of scripts for deploying to service specific software applications. We are going to utilize this process to create a new script that will encrypt our collection of certificate files and deliver them to the intended target. Before we start we need to understand how the –deploy-hook script works.

Every script starts with this base script. If you are not familiar on writing bash shell scripts, follow along anyways, but you may want to pick up a copy of Shell Scripting by Jason Cannon. In the mean time, just follow along.

#!/usr/bin/env sh

#Here is a sample custom api script.
#This file name is "myapi.sh"
#So, here must be a method   myapi_deploy()
#Which will be called by acme.sh to deploy the cert
#returns 0 means success, otherwise error.

########  Public functions #####################

#domain keyfile certfile cafile fullchain
myapi_deploy() {
  _cdomain="$1"
  _ckey="$2"
  _ccert="$3"
  _cca="$4"
  _cfullchain="$5"

  _debug _cdomain "$_cdomain"
  _debug _ckey "$_ckey"
  _debug _ccert "$_ccert"
  _debug _cca "$_cca"
  _debug _cfullchain "$_cfullchain"

  _err "Not implemented yet"
  return 1

}

If you look closely under the myapi_deploy() section you will see $1, $2 … $5. These are positional arguments, that the script takes as input. We are going to use this information to create some of our own extended functionality.

You first need to define what you want your deploy script to do. In our case we will simply take the certificates, and create a new zip file with all the data. ** This is a super simple example, and you should not use basic zip files for transmitting secure data. **

Bellow is our custom script, save this as zipcerts.sh in your ~/.acme.sh/deploy/ folder.

** PLEASE CHANGE THE PASSWORD **

#!/usr/bin/env sh

#Here is a sample custom api script.
#This file name is "zipcerts.sh"
#So, here must be a method  zipcerts_deploy()
#Which will be called by acme.sh to deploy the cert
#returns 0 means success, otherwise error.

########  Public functions #####################
PASSWORD=MySuperN0tS3curePa$$w0oRd

#domain keyfile certfile cafile fullchain
zipcerts_deploy() {
  _cdomain="$1"
  _ckey="$2"
  _ccert="$3"
  _cca="$4"
  _cfullchain="$5"

  _debug _cdomain "$_cdomain"
  _debug _ckey "$_ckey"
  _debug _ccert "$_ccert"
  _debug _cca "$_cca"
  _debug _cfullchain "$_cfullchain"

  
  zip -P ${PASSWORD} ${_cdomain}.zip $_ckey $_ccert $_cca $_cfullchain
  if [ $? -eq 0 ] ; then
      return 0
  fi

  # Compress files
  _err "Not implemented yet"
  return 1

}

So what happens?  This will take the certificates and add them to a zip file named domain.zip. We also added a password to the zip file. as a light layer of protection.

With the custom deploy script in place, you can execute acme.sh to “deploy” the certificates. In our case this will place the zipped files in the current directory.

acme.sh --deploy -d *.voice1.me --deploy-hook zipcerts

You should see a response simiular to the following:

$ acme.sh --deploy -d *.voice1.me --deploy-hook zipcerts
  adding: Users/ben/.acme.sh/*.voice1.me/*.voice1.me.key (deflated 23%)
  adding: Users/ben/.acme.sh/*.voice1.me/*.voice1.me.cer (deflated 30%)
  adding: Users/ben/.acme.sh/*.voice1.me/ca.cer (deflated 29%)
  adding: Users/ben/.acme.sh/*.voice1.me/fullchain.cer (deflated 34%)
[Thu Mar 14 12:28:52 PDT 2018] Success

And there you have it. A zip file with your password protected zip file with your new wild card certificate.

Deploying to Multiple Systems

You can run the –deploy option multiple times with different hooks to execute different actions. You should review the deploy folder for some examples, and some working scripts. If your bash skills are up to it, you can create any complex deployment strategy that you like. In the future we may add a couple better examples of deploying to a cert to multiple web servers, Digium Switchvox, and other appliances.

Need assistance deploying LE SSL Certificates? Drop us a line, we would be happy to help you create an automated workflow to allow you to deploy LE to all of your systems.