SSL cert rotation is a problem that plagues nearly every web developer. Some are fortunate to work with infrastructure where an automated solution is available. This eliminates the need for tedious SSL cert management. Others are fortunate to have a team dedicated to managing infrastructure needs, so they can toss this issue to another engineer.
Unfortunately, I do not fall into either of these two camps when it comes to SSL certificate management. I needed to develop my own certificate management solution to ensure new SSL certs got properly installed on my servers. This post covers how to use Braintree's Runbook to automate the rotation of SSL certificates.
My certificate infrastructure is based on Jamie Nguyen's OpenSSL Certificate Authority Tutorial. I store a root certificate authority and intermediate certificate authority on my local machine. From the intermediate CA, I issue certs for servers within my infrastructure. All servers in my infrastructure trust my intermediate CA, so they accept traffic from valid certs when connecting to other servers.
SSL certificate rotation is a process that's ripe for automation. It is a tedious, repetitive process. The process is performed infrequently enough that it is easy to forget how to do it. And it is mission critical; failing to properly rotate SSL certificates almost certainly results in an outage.
The automation process
Several iterations were required before I boiled the rotation process down to a single command entered on the command line. My first pass at rotating SSL certs involved a lot of trial and error. Ultimately, I nailed down all the steps required to successfully rotate SSL certificates in my infrastructure. I took diligent notes to be well-armed for my next inevitable encounter with SSL cert rotation.
On my second iteration, with notes in hand, I was able to successfully rotate certificates with only minor tweaks to my documented process. Nevertheless, having a handful of servers still made this a tedious process. Retyping the several-dozen commmand incantations over and over for each server is not how I like to spend my afternoons. Leveraging Runbook allowed me to bring this process down to single command for rotating my SSL certs. Below is the SSL cert rotation runbook I developed.
The runbook
The SSL Cert rotation process breaks down into three main steps. First, a new cert needs to be generated using the intermediate CA. Second, the new cert needs to be distributed to the target server. And finally, the service must be restarted to pick up the new certificate.
See Runbook's README.md for details on setting up and working with Runbook.
Setup
First, we must collect some input for our parameterized runbook. The two pieces of information we need are the host and service for the SSL certificate we are generating.
#!/usr/bin/env ruby
require "runbook"
host = ENV["HOST"] # e.x. ldap01.stg
raise "Error no host specified using HOST env var" unless host
service = ENV["SERVICE"] # e.x. slapd
raise "Error no service specified using SERVICE env var" unless service
local_user = ENV["USER"]
company_name = "patricks_pickles"
intermediate_ca_path = "/root/ca/intermediate"
local_git_dir = "/home/#{local_user}/dev/#{company_name}/pp-infrastructure"
local_cert_path = "modules/ldap/files"
local_cert_file = "#{host}_#{service}.cert.pem"
staging_suffix = "#{company_name}-staging.com"
prod_suffix = "#{company_name}.com"
We collect this info from the command line using environment variables. The reason we do not use Runbook's ask statement to collect this info is because these values are used prominently throughout the runbook. It makes for a cleaner implementation to collect these values on the command line and then parameterize our runbook with them before executing it.
Additionally, we initialize a number of other local variables that are used throughout our runbook.
All runbooks are initialized with a title. It is best-practice to provide a description of the runbook as well.
runbook = Runbook.book "Renew SSL Certs" do
description <<-DESC
This Runbook rotates SSL Certs.
DESC
layout [[:runbook, :commands]]
section "Setup" do
step { ruby_command { @env = host.split(".").last.to_sym } }
end
end
This runbook has a layout, which implies the runbook manages multiple panes using tmux. The layout is a stacked layout where the runbook executes in the top pane and commands are sent to the bottom pane. The setup section sets the @env
instance variable at runtime. This value is subsequently available in all other ruby_command
blocks.
Certificate generation
After initial setup, the next runbook section encompasses all steps required to create the new certificate.
runbook = Runbook.book "Renew SSL Certs" do
#...
section "Create New Cert" do
user "root"
step "Backup and update index.txt" do
capture %Q{ls #{intermediate_ca_path}/index.txt.old* | tail -n 1 | sed -E "s/.*([0-9]{2})/\\1/"}, into: :backup_num
ruby_command do
@backup_num = (backup_num.to_i + 1).to_s.rjust(2, "0")
command "cp #{intermediate_ca_path}/index.txt #{intermediate_ca_path}/index.txt.old#{@backup_num}"
command "cp #{intermediate_ca_path}/index.txt.attr #{intermediate_ca_path}/index.txt.attr.old#{@backup_num}"
command %Q{sed -i "/#{host} #{service.upcase}/d" #{intermediate_ca_path}/index.txt}
end
end
step "Generate new cert" do
ruby_command do
case env
when :stg
@expiration_days = 1035
when :prod
@expiration_days = 1095
else
raise "Unknown env: #{env}"
end
tmux_command "sudo openssl ca -config #{intermediate_ca_path}/openssl.cnf -extensions server_cert -days #{@expiration_days} -notext -md sha256 -in #{intermediate_ca_path}/csr/#{host}_#{service}.csr.pem -out #{intermediate_ca_path}/certs/#{local_cert_file}", :commands
confirm "Have you generated the cert?"
end
command "sudo chmod 444 #{intermediate_ca_path}/certs/#{local_cert_file}"
tmux_command "sudo openssl x509 -noout -text -in #{intermediate_ca_path}/certs/#{local_cert_file}", :commands
confirm "Does the cert look correct?"
tmux_command "sudo openssl verify -CAfile #{intermediate_ca_path}/certs/ca-chain.cert.pem #{intermediate_ca_path}/certs/#{local_cert_file}", :commands
confirm "Is the cert valid?"
end
end
end
The user
setter designates that all commands in this section exececute as the root
user. Because no host is specified, commands are executed locally. confirm
statements allow us to confirm everything is correct before moving on to the next step.
Because the case statement references the env
instance variable, it must be wrapped in a ruby_command
block so it is executed at runtime. Because the tmux_command
references @expiration_days
, it also must be defined in the ruby_command
block.
Uploading the certificate
In this section we copy the newly-generated certificate to our version-controlled infrastructure management repository, upload the certificate to the server, and install the certificate.
runbook = Runbook.book "Renew SSL Certs" do
#...
section "Upload Cert" do
step "Copy the cert to pp-infrastructure" do
user "root"
command "cp #{intermediate_ca_path}/certs/#{local_cert_file} #{local_git_dir}/#{local_cert_path}"
command "chown #{local_user}:#{local_user} #{local_git_dir}/#{local_cert_path}/#{local_cert_file}"
end
step "Upload the cert" do
server host
upload "#{local_git_dir}/#{local_cert_path}/#{local_cert_file}", to: "/home/#{local_user}"
end
step "Install the cert" do
server host
user "root"
command "mv ~#{local_user}/#{local_cert_file} /etc/ssl"
command "chown root:ssl-cert /etc/ssl/#{local_cert_file}"
command "chmod 444 /etc/ssl/#{local_cert_file}"
command "cp /etc/ssl/#{local_cert_file} /etc/ssl/certs"
end
end
end
The server
setter uses entries in my ~/.ssh/config
file to resolve the long-form host name, port, and user to log in as for a given host string passed to ssh.
Restarting the service
Lastly, we restart the service, verify our new certificate is valid, and commit our certificate to version control.
runbook = Runbook.book "Renew SSL Certs" do
#...
section "Upload Cert" do
#...
step "Restart the service" do
server host
user "root"
command "service #{service} restart"
end
step "Validate the service cert is valid" do
ruby_command do
case env
when :stg
@suffix = staging_suffix
when :prod
@suffix = prod_suffix
else
raise "Unknown env: #{env}"
end
tmux_command "ssh #{host}", :commands
tmux_command "openssl s_client -connect #{host}.#{@suffix}:12345 -CApath /etc/ssl/certs", :commands
confirm "Is the cert valid?"
end
end
step "Commit cert changes" do
path "#{local_git_dir}"
command "git add #{local_cert_path}/#{local_cert_file}"
command %Q{git commit -m "Update #{local_cert_file} certificate"}
command "git push"
end
end
end
Including the cert validation step allows us to confirm that the new cert is working as expected so we don't encounter an issue when the old certificate expires.
With our runbook in hand, rotating SSL certs is as simple as invoking the following command:
HOST=ldap01.stg SERVICE=slapd runbook exec runbooks/renew_ssl_certs.rb
Conclusion
The full runbook for rotating SSL certs is available as a gist. This runbook likely won't meet your SSL rotation needs as is. But hopefully it can serve as a basis for automating your SSL cert rotation process, so you are no longer plagued with manually managing SSL certificates.
Top comments (0)