ACME certificate protocol (Let's Encrypt) proxy client with a dashboard and monitoring
ACME (currently implemented by Let’s Encrypt) is a way to automatically (re)issue TLS certificates.
Most ACME clients are designed to run on the same machine as your TLS services.
But if you have a lot of servers, there are two problems with that:
freshcerts solves both problems.
It runs a server that exposes a much simpler API to your servers (they’ll use a tiny shell script that’s pretty much openssl | curl | tar
) and a dashboard to your system administrators.
Servers are monitored to ensure they actually use the certs issued for them.
Email notifications are sent to the admins for all errors found by monitoring and for all issued certificates.
It’s a typical Ruby app, so you’ll need Bundler:
git clone https://github.com/valpackett/freshcerts.git
cd freshcerts
bundle install --path vendor/bundle
mkdir data
Use environment variables to configure the app. Read common.rb
to see which variables are available.
You probably should change the ACME endpoint (by default, Let’s Encrypt staging is used, not production):
export ACME_ENDPOINT="https://acme-v01.api.letsencrypt.org/"
export ADMIN_EMAIL="[email protected]"
Generate a tokens key:
openssl ecparam -genkey -name prime256v1 -out data/tokens.key.pem
Generate and register an account key:
openssl genrsa -out data/account.key.pem 4096
chmod 0400 data/account.key.pem
bundle exec ./register-account-key
Run:
bundle exec puma -p 9393
In production, you’ll want to configure your process manager to run it.
Set RACK_ENV=production
there in addition to the config variables (ACME_ENDPOINT
, etc.)
If you want to run freshcerts on e.g. a cheap VPS with low RAM:
SEPARATE_MONITORING=1
for the server process (puma/rackup);bundle exec ruby monitoring.rb
into your crontab for every 10 minutes or so.time-until-stop
to something ridiculously low like 1 second, because freshcerts keeps challenges in memory.This way, memory will only be used when there are requests to the freshcerts server or when it’s doing the monitoring.
For every domain:
Generate an auth token with bundle exec ./generate-token
.
Configure the HTTP server to forward /.well-known/acme-challenge/*
requests to the freshcerts server.
Configure cron to run the freshcerts-client
script every day.
Args: domain, subject, ports (comma separated), reload command, auth token. Like this:
FRESHCERTS_HOST="https://certs.example.com:4333" freshcerts-client example.com /CN=example.com 443 "service nginx reload" "eyJ0eXAiOi..."
And figure out cert paths and file permissions 😃
If you want to issue a certificate for multiple domains, there’s a more advanced Ruby client, use it like that:
FRESHCERTS_HOST="https://certs.example.com:4333" FRESHCERTS_TOKEN="eyJ0eXAiOi..." freshcerts-multi-client example.com,www.example.com 443 && service nginx reload
If you can’t use Ruby, you can modify the shell client to support multi-domain certificates. Set up openssl.cnf to read SAN from the environment, modify the client to read that config section (add e.g. -extensions san_env
to the CSR generation command) and pass the domains via that variable. For the freshcerts part (first arg), use a comma-separated list of domains instead of just one domain. Do not use subjectAltName
as a subject field, that’s a special syntax supported by some CAs (not Let’s Encrypt!) that will turn it into real SAN fields.
Please feel free to submit pull requests!
By participating in this project you agree to follow the Contributor Code of Conduct.
The list of contributors is available on GitHub.
This is free and unencumbered software released into the public domain.
For more information, please refer to the UNLICENSE
file or unlicense.org.