See also the issue in the lab.
It would be convenient to have a single role (instead of the three below) providing the following feature: using letsencrypt certificates in production and for testing, in an nginx server.
- As a developer I want to install the letsencrypt staging certs only, in a host that is a client of a letsencrypt enabled service in a staging environment:
role: nginx-letsencrypt vars: client: true staging: true or false
- As a sysadmin I want to install a letsencrypt enabled nginx server for mydomain.com
role: nginx-letsencrypt vars: mail: email@example.com domain: mydomain.com staging: true or false
- As a sysadmin I want to install a letsencrypt enabled nginx reverse proxy, configured to handle websockets:
role: nginx-letsencrypt vars: email: firstname.lastname@example.org reverse_proxy: mydomain.net => backend:8000 staging: true or false role: nginx-letsencrypt vars: email: email@example.com reverse_proxy: otherdomain.net => backend:8000 staging: true or false
The three roles that currently exist are are:
- certs role which installs the fake letsencrypt certificates when using the staging environment, convenient for testing so we don’t run into the throttling limits of production certificates
- certbot role which obtains letsencrypt certificates and installs them in a previously installed nginx server
- jdauphant.nginx used to install a web server or a reverse proxy to a service so it can be used by certbot to install a letsencrypt certificate
These three roles are used together, as can be seen at:
In all cases the certs role is used in the molecule playbook (see the weblate molecule playbook for instance) and not in the production playbook. The tests rely on the letsencrypt staging environment certificates to run otherwise curl/requests fail because the certificate is unknown (see the chat tests for instance).