c9215801f0
This autogenerates the list of ssl domains for the ssl-cert-check tool directly from the letsencrypt list. The first step is the install-certcheck role that replaces the puppet-ssl_cert_check module that does the same. The reason for this is so that during gate testing we can test this on the test bridge.openstack.org server, and avoid adding another node as a requirement for this test. letsencrypt-request-certs is updated to set a fact letsencrypt_certcheck_domains for each host that is generating a certificate. As described in the comments, this defaults to the first host specified for the certificate and the listening port can be indicated (if set, this new port value is stripped when generating certs as is not necessary for certificate generation). The new letsencrypt-config-certcheck role runs and iterates all letsencrypt hosts to build the final list of domains that should be checked. This is then extended with the letsencrypt_certcheck_additional_domains value that covers any hosts using certificates not provisioned by letsencrypt using this mechanism. These additional domains are pre-populated from the openstack.org domains in the extant check file, minus those openstack.org domain certificates we are generating via letsencrypt (see letsencrypt-create-certs/handlers/main.yaml). Additionally, we update some of the certificate variables in host_vars that are listening on port !443. As mentioned, bridge.openstack.org is placed in the new certcheck group for gate testing, so the tool and config file will be deployed to it. For production, cacti is added to the group, which is where the tool currently runs. The extant puppet installation is disabled, pending removal in a follow-on change. Change-Id: Idbe084f13f3684021e8efd9ac69b63fe31484606
74 lines
3.1 KiB
ReStructuredText
74 lines
3.1 KiB
ReStructuredText
Request certificates from letsencrypt
|
|
|
|
The role requests certificates (or renews expiring certificates, which
|
|
is fundamentally the same thing) from letsencrypt for a host. This
|
|
requires the ``acme.sh`` tool and driver which should have been
|
|
installed by the ``letsencrypt-acme-sh-install`` role.
|
|
|
|
This role does not create the certificates. It will request the
|
|
certificates from letsencrypt and populate the authentication data
|
|
into the ``acme_txt_required`` variable. These values need to be
|
|
installed and activated on the DNS server by the
|
|
``letsencrypt-install-txt-record`` role; the
|
|
``letsencrypt-create-certs`` will then finish the certificate
|
|
provision process.
|
|
|
|
**Role Variables**
|
|
|
|
.. zuul:rolevar:: letsencrypt_use_staging
|
|
|
|
If set to True will use the letsencrypt staging environment, rather
|
|
than make production requests. Useful during initial provisioning
|
|
of hosts to avoid affecting production quotas.
|
|
|
|
.. zuul:rolevar:: letsencrypt_certs
|
|
|
|
A host wanting a certificate should define a dictionary variable
|
|
``letsencyrpt_certs``. Each key in this dictionary is a separate
|
|
certificate to create (i.e. a host can create multiple separate
|
|
certificates). Each key should have a list of hostnames valid for
|
|
that certificate. The certificate will be named for the *first*
|
|
entry.
|
|
|
|
For example:
|
|
|
|
.. code-block:: yaml
|
|
|
|
letsencrypt_certs:
|
|
hostname-main-cert:
|
|
- hostname01.opendev.org
|
|
- hostname.opendev.org
|
|
hostname-secondary-cert:
|
|
- foo.opendev.org
|
|
|
|
will ultimately result in two certificates being provisioned on the
|
|
host in ``/etc/letsencrypt-certs/hostname01.opendev.org`` and
|
|
``/etc/letsencrypt-certs/foo.opendev.org``.
|
|
|
|
Note the creation role ``letsencrypt-create-certs`` will call a
|
|
handler ``letsencrypt updated {{ key }}`` (for example,
|
|
``letsencrypt updated hostname-main-cert``) when that certificate
|
|
is created or updated. Because Ansible errors if a handler is
|
|
called with no listeners, you *must* define a listener for event.
|
|
``letsencrypt-create-certs`` has ``handlers/main.yaml`` where
|
|
handlers can be defined. Since handlers reside in a global
|
|
namespace, you should choose an appropriately unique name.
|
|
|
|
Note that each entry will require a ``CNAME`` pointing the ACME
|
|
challenge domain to the TXT record that will be created in the
|
|
signing domain. For example above, the following records would need
|
|
to be pre-created::
|
|
|
|
_acme-challenge.hostname01.opendev.org. IN CNAME acme.opendev.org.
|
|
_acme-challenge.hostname.opendev.org. IN CNAME acme.opendev.org.
|
|
_acme-challenge.foo.opendev.org. IN CNAME acme.opendev.org.
|
|
|
|
The hostname in the first entry for each certificate will be
|
|
registered with the ``letsencrypt-config-certcheck`` for periodic
|
|
freshness tests; from the example above, ``hostname01.opendev.org``
|
|
and ``foo.opendev.org`` would be checked. By default this will
|
|
check on port 443; if the certificate is actually active on another
|
|
port you can specify it after a colon;
|
|
e.g. ``foo.opendev.org:5000`` would indicate this host listens with
|
|
this certificate on port 5000.
|