On Wed, May 19, 2021 at 07:23:01PM -0400, post...@ptld.com wrote:
> > On 05-19-2021 7:02 pm, Viktor Dukhovni wrote:
> >> Well submission.example.com is a linux server running haproxy on it.
> >> The only way (i know how) to create a certificate assigned to
> >> submission.example.com is to create that certificate using commands in
> >> a bash shell using certbot physically on that server.
> >
> > Well, there's your false assumption.
>
> ...and? The correct assumption is a secret?
The correct assumption is that the backend server can *directly*
obtain a certificate for a service whose IP address resolves to
the front-end proxy.
> Using certbot (with a validation method that works with auto renew) i
> can create a certificate on the backend.exmample.com server and tell
> certbot the certificate will be for submission.example.com even though
> submission.example.com will not resolve to the server im running certbot
> on?
Correct, the only requirement is that the backend server be able to
prove "domain control", i.e. either be able to respond on port 80 and/or
443 for the cluster name, or be able to make DNS changes (likely add
challenge TXT records), ...
In the "webroot" case, it is simplest to have just one of the cluster
members do key rotation. Key rotation should never be urgent, and so
even if that host is down briefly, you can wait till it comes back
online (you have ~30 days to do that).
That way, the proxy can forward the HTTP ports statically to just that
one host. This is because the host running certbot needs to be one that
the proxy will forward the HTTP port to.
If the HTTP port is dynamically spun up by certbot itself (no permanent
HTTP servers on the MTAs), then the proxy may be able to discover the
one host that's live promptly even though health checks might have
recently shown all the HTTP servers to be down. I don't know how
quickly haproxy will find a service that's just come up on one member
of the cluster.
--
Viktor.
