We rely on API clients to send cert and key as []byte when adding a backend to the proxy. When we receive a connection, we look at the domain on the request and query the database to find the associated entry with the cert we require.
Problems:
If we had a wildcard cert for several subdomains, we'd have to duplicate the data in the database. For example, for domains one.example.com and two.example.com, they would both need duplicate bytes for a valid *.example.com wildcard cert.
We don't provide a magical option for LetsEncrypt
Our goal is to do what Caddy does, which is to attempt to transparently provide https via letsencrypt if a path to a cert and key are not provided.
We'll also want to:
separate the storage of x509 certs and keys from other backend metadata, so that it is easier to cache and re-used certs and keys.
Always check the cache first, not just for existence, but for the validity/expiration of a cert. Hit Let's Encrypt's API as little as possible in other words.
Current state:
We rely on API clients to send cert and key as
[]bytewhen adding a backend to the proxy. When we receive a connection, we look at the domain on the request and query the database to find the associated entry with the cert we require.Problems:
one.example.comandtwo.example.com, they would both need duplicate bytes for a valid*.example.comwildcard cert.Our goal is to do what Caddy does, which is to attempt to transparently provide https via letsencrypt if a path to a cert and key are not provided.
We'll also want to: