You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Current state:
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:
one.example.com
andtwo.example.com
, they would both need duplicate bytes for a valid*.example.com
wildcard 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:
The text was updated successfully, but these errors were encountered: