This role is a light customization of the ansible-role-certbot by Jeff Geerling
Installs and configures Certbot (for Let's Encrypt)
It is integrated for the MediaWiki EZ Administration (Meza) platform and specifically its HAProxy TLS termination.
The role depends on the global use_certbot var in Meza's config/defaults.yml
certbot_install_method: package
Controls how Certbot is installed. Available options are 'package', 'snap', and 'source'.
certbot_auto_renew: true
certbot_auto_renew_user: "{{ ansible_user | default(lookup('env', 'USER')) }}"
certbot_auto_renew_hour: "3"
certbot_auto_renew_minute: "30"
certbot_auto_renew_options: "--quiet --deploy-hook /etc/letsencrypt/renewal-hooks/deploy/concat.pem.sh"
By default, this role configures a cron job to run under the provided user account at the given hour and minute, every day. The defaults run certbot renew via cron every day at 03:30:00 by the user you use in your Ansible playbook. It's preferred that you set a custom user/hour/minute so the renewal is during a low-traffic period and done by a non-root user account.
Currently the standalone and webroot method are supported for generating new certificates using this role.
For a complete example: see the fully functional test playbook in molecule/default/playbook-standalone-nginx-aws.yml.
certbot_create_if_missing: true
Set certbot_create_if_missing to yes or true to let this role generate certs.
certbot_create_method: standalone
Set the method used for generating certs with the certbot_create_method variable — current allowed values are: standalone or webroot.
certbot_testmode: false
Use the letsencrypt staging servers. Default is 'false' To do development you can either use --dry-run in certbot commands so that you hit the staging servers and avoid rate limiting; or else set certbot_testmode to true. In the latter case, you will need to delete your INVALID staging certificates and may also need to use --force-renew in order to get production certificates.
certbot_hsts: false
Enable (HTTP Strict Transport Security) for the certificate generation.
certbot_admin_email: email@example.com
The email address used to agree to Let's Encrypt's TOS and subscribe to cert-related notifications. This should be customized and set to an email address that you or your organization regularly monitors.
For Meza, you could use
certbot_admin_email: "{{ m_httpd_server_admin }}"
Certificates
certbot_certs: []
# - email: janedoe@example.com
# webroot: "/var/www/html"
# domains:
# - example1.com
# - example2.com
# - domains:
# - example3.com
A list of domains (and other data) for which certs should be generated. You can add an email key to any list item to override the certbot_admin_email. When using the webroot creation method, a webroot item has to be provided, specifying which directory to use for the authentication. Make sure your webserver correctly delivers contents from this directory.
certbot_create_command: "{{ certbot_script }} certonly --standalone --noninteractive --agree-tos --email {{ cert_item.email | default(certbot_admin_email) }} -d {{ cert_item.domains | join(',') }}"
The certbot_create_command defines the command used to generate the cert. See the full default command inside defaults/main.yml for a full example—and you can easily add in extra arguments that are not in the default command with the certbot_create_extra_args variable.
certbot_create_standalone_stop_services:
- httpd
- haproxy
Services that should be stopped while certbot runs it's own standalone server on ports 80 and 443. If you're running Apache, set this to apache2 (Ubuntu), or httpd (RHEL), or if you have Nginx on port 443 and something else on port 80 (e.g. Varnish, a Java app, or something else), add it to the list so it is stopped when the certificate is generated.
These services will only be stopped the first time a new cert is generated.
Beginning in December 2020, the Certbot maintainers decided to recommend installing Certbot from Snap rather than maintain scripts like certbot-auto.
Setting certbot_install_method: snap configures this role to install Certbot via Snap.
This install method is currently experimental and may or may not work across all Linux distributions.
When using the webroot creation method, a webroot item has to be provided for every certbot_certs item, specifying which directory to use for the authentication. Also, make sure your webserver correctly delivers contents from this directory.
certbot_webroot: /var/www/letsencrypt
Default webroot, overwritten by individual per-cert webroot directories
For Meza, you should use certbot_webroot: "{{ m_htdocs }}"
You can install Certbot from it's Git source repository if desired with certbot_install_method: source. This might be useful in several cases, but especially when older distributions don't have Certbot packages available (e.g. CentOS < 7, Ubuntu < 16.10 and Debian < 8).
certbot_repo: https://github.com/certbot/certbot.git
certbot_version: master
certbot_keep_updated: true
Certbot Git repository options. If installing from source, the configured certbot_repo is cloned, respecting the certbot_version setting. If certbot_keep_updated is set to yes, the repository is updated every time this role runs.
certbot_dir: /opt/certbot
The directory inside which Certbot will be cloned.
Let's Encrypt supports generating wildcard certificates, but the process for generating and using them is slightly more involved. See comments in this pull request for an example of how to use this role to maintain wildcard certs.
Michael Porter also has a walkthrough of Creating A Let’s Encrypt Wildcard Cert With Ansible, specifically with Cloudflare.
none - but this role is customized to run with the freephile fork of Meza
Create a file in src/playbooks with contents
- name: Run Certbot Role by itself
hosts: localhost
become: true
roles:
- certbot
See other examples in the tests/ directory.
Note: You can have this role automatically generate certificates; see the "Automatic Certificate Generation" documentation above.
You can manually create certificates using the certbot script (or use /opt/certbot/certbot-auto if installing from source). Here are some example commands to configure certificates with Certbot:
# Automatically add certs for all Apache virtualhosts (use with caution!).
certbot --apache
# Generate certs, but don't modify Apache configuration (safer).
certbot --apache certonly
If you want to fully automate the process of adding a new certificate, but don't want to use this role's built in functionality, you can do so using the command line options to register, accept the terms of service, and then generate a cert using the standalone server:
- Make sure any services listening on ports 80 and 443 (Apache, Nginx, Varnish, etc.) are stopped.
- Register with something like
certbot register --agree-tos --email [your-email@example.com]- Note: You won't need to do this step in the future, when generating additional certs on the same server. - Generate a cert for a domain whose DNS points to this server:
certbot certonly --noninteractive --standalone -d example.com -d www.example.com - Re-start whatever was listening on ports 80 and 443 before.
- Update your webserver's virtualhost TLS configuration to point at the new certificate (
fullchain.pem) and private key (privkey.pem) Certbot just generated for the domain you passed in thecertbotcommand. - Reload or restart your webserver so it uses the new HTTPS virtualhost configuration.
By default, this role adds a cron job that will renew all installed certificates once per day at the hour and minute of your choosing.
You can test the auto-renewal (without actually renewing the cert) with the command:
/opt/certbot/certbot-auto renew --dry-run
See full documentation and options on the Certbot website.
AGPLv3+
This role was created in 2016 by Jeff Geerling, author of Ansible for DevOps, and modified in 2024 to work an updated version of Meza by Greg Rundlett