Add support for a "ask" parameter for on-demand TLS similar to Caddy's one #8

New issue

Closed

opened 2023-08-08 14:46:08 +00:00 by quentin · 1 comment

quentin commented

2023-08-08 14:46:08 +00:00

Owner

~~Blocked by: Deuxfleurs/garage#610~~
The TLS-on-demand endpoint should be called before any call to the Let's Encrypt API.
Furthermore, we should find a solution to garbage collect certificates that are not used anymore (for example, if we correctly call the check API before any renew, then unused certificates should expire after something like 7d or 14d. Then, we can say that expired certficates can be safely garbage collected).

<del>Blocked by: https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/610</del> The TLS-on-demand endpoint should be called before any call to the Let's Encrypt API. Furthermore, we should find a solution to garbage collect certificates that are not used anymore (for example, if we correctly call the check API before any renew, then unused certificates should expire after something like 7d or 14d. Then, we can say that expired certficates can be safely garbage collected).

quentin commented

2023-11-30 13:52:56 +00:00

Author

Owner

Interface

New directive of the form:

tricot-on-demand-tls-ask http://garage-admin.service.prod.consul:3903/check

Garage will then call the URL and return a 200 or 400 http status code:

$ curl -I -X GET http://localhost:3903/check?domain=guide.deuxfleurs.fr
HTTP/1.1 200 OK

$ curl -I -X GET http://localhost:3903/check?domain=noop.deuxfleurs.fr
HTTP/1.1 400 Bad Request

Some info about `src/check_cert.rs`

Currently certificate generation is done as follow:

It can be triggered in 2 different manners:
- Eagerly, upon receiving a service update when a host is defined by a string in the Consul service
- Lazily, upon receiving a client request when a host is defined by a glob pattern like * in the Consul service.
Both type of generation request are received and handled by src/cert_store.rs::CertStore::certificate_loop
That calls src/cert_store.rs::CertStore::check_cert
That calls src/cert_store.rs::CertStore::renew_cert
That does the Let's Encrypt calls

Internal change

Our change will be made at two places:

proxy_config.rs::ProxyEntry::new
- parse_tricot_tags must include the new directive
- the ProxyEntry needs to store the URL: Option<String>
- the new function must interpret the tag and set the appropriate structure entry
cert_store.rs::CertStore::certificate_loop will need to
- collect the on-demand-tls-ask URLs (and their associated glob patterns) in a vector outside of the loop:
  - indeed the check URL is collected during a Consul Service change...
  - ...but is used for on demand certificates
- when receiving an on-demand request, check that:
  - it matches at least one of the URL glob. If none match -> do not register it
  - for all matching globs, do the call to the Caddy-like API -> as soon as one 200 is received,

Out of scope

Garbage collection of non renewed certificates

## Interface New directive of the form: ``` tricot-on-demand-tls-ask http://garage-admin.service.prod.consul:3903/check ``` Garage will then call the URL and return a 200 or 400 http status code: ``` $ curl -I -X GET http://localhost:3903/check?domain=guide.deuxfleurs.fr HTTP/1.1 200 OK $ curl -I -X GET http://localhost:3903/check?domain=noop.deuxfleurs.fr HTTP/1.1 400 Bad Request ``` ## Some info about `src/check_cert.rs` Currently certificate generation is done as follow: - It can be triggered in 2 different manners: - Eagerly, upon receiving a service update when a host is defined by a string in the Consul service - Lazily, upon receiving a client request when a host is defined by a glob pattern like `*` in the Consul service. - Both type of generation request are received and handled by `src/cert_store.rs::CertStore::certificate_loop` - That calls `src/cert_store.rs::CertStore::check_cert` - That calls `src/cert_store.rs::CertStore::renew_cert` - That does the Let's Encrypt calls ## Internal change Our change will be made at two places: - `proxy_config.rs::ProxyEntry::new` - `parse_tricot_tags` must include the new directive - the ProxyEntry needs to store the URL: `Option<String>` - the `new` function must interpret the tag and set the appropriate structure entry - `cert_store.rs::CertStore::certificate_loop` will need to - collect the `on-demand-tls-ask` URLs (and their associated glob patterns) in a vector outside of the loop: - indeed the check URL is collected during a Consul Service change... - ...but is used for on demand certificates - when receiving an on-demand request, check that: - it matches at least one of the URL glob. If none match -> do not register it - for all matching globs, do the call to the Caddy-like API -> as soon as one 200 is received, ## Out of scope Garbage collection of non renewed certificates