Automatic Certificate Management Environment (ACME) through Consul service tags #3

New issue

Open

opened 2021-08-13 14:52:37 +00:00 by adrien · 0 comments

adrien commented

2021-08-13 14:52:37 +00:00

Owner

Let us consider a fake DNS service with a web front-end we would like to access through HTTPS:

consul services register -name=fake_dns  -tag="(diplonat (udp_port 53) (tcp_port 53) (acme dns-frontend.example.org)"

Upon reading the acme tag, diplonat would generate a TLS certificate through an ACME provider (e.g. Let's Encrypt), and add it to the Consul KV store (or to Vault KV store, ideally).

Then, a reverse proxy (e.g. nginx) could use Nomad's template stanza to populate its service configuration with the generated certificate.

The ACME configuration will require a configuration file for Diplonat (several pieces of information are needed, e.g. domain holder's e-mail address, TLS renewal interval etc.). See #2.

Diplonat could be in charge of generating TLS certificates for services, since it already knows how to read services' configuration through Consul service tags; and it's a diplomat's job, to edit certificates, isn't it? Let us consider a fake DNS service with a web front-end we would like to access through HTTPS: ``` consul services register -name=fake_dns -tag="(diplonat (udp_port 53) (tcp_port 53) (acme dns-frontend.example.org)" ``` Upon reading the `acme` tag, diplonat would generate a TLS certificate through an ACME provider (e.g. [Let's Encrypt](https://letsencrypt.org/)), and add it to the Consul KV store (or to Vault KV store, ideally). Then, a reverse proxy (e.g. nginx) could use [Nomad's `template` stanza](https://www.nomadproject.io/docs/job-specification/template) to populate its service configuration with the generated certificate. --- The ACME configuration will require a configuration file for Diplonat (several pieces of information are needed, e.g. domain holder's e-mail address, TLS renewal interval etc.). See #2.