On Tue, Jul 21, 2020 at 05:24:10AM -0600, @lbutlr wrote:
> Given two machines (or more) running as mail.example.com what is the
> best practices way of duplicating the certs for that domain so that
> each server has valid certificates.
If your issuing CA refuses to mint multiple overlapping certificates for
the same name, but distinct keys/serial numbers, ... Then it is in fact
best to avoid giving all the machines the same name. For inbound relays
(MX host service on port 25), this is easy enough, assign distinct names
to all the machines.
A single certificate covering all your MX hosts is a single point of
failure when it expires, or is updated incorrectly and no longer matches
the published DANE TLSA records. Diversity of certificates across your
MX hosts is a good thing (operational excellence and solid monitoring
can also make a single shared certificate work, but it takes more care
to avoid complete outages).
That said, per-host certificates do not scale to very large clusters of
servers, where each logical MX host is really a large pool of servers
behind a load balancer. It is also not practical for a distributed MSA,
because MUAs are typically configured to connect to a single logical
host.
Therefore, you also need to be able to have a shared X.509 identity
across multiple hosts. With a sufficiently liberal CA under your
control, you can issue separate certificates for the shared name, one
per host, and renew them independently. I do this at $work.
But if your public CA does not allow this, or the volume of requests to
the public CA would then be excessive, you need to be able to securely
deliver the private key to multiple hosts along with the associated
certificate chain (putting both in the same .pem file is best).
You can then atomically update the chain file replacing both the cert
and key in one operation.
You'll need monitoring in place to make sure all the hosts present
the expected certificate chain (including required intermediate
CA certs) when performing STARTTLS (or SMTP inside TLS for port
465 smtps).
If you publish DANE TLSA records you'll need to check the the chain
matches the TLSA RRs, but even before you deploy the chain, you
should already have published the TLSA RRs matching the upcoming
chain at least 2 TTLS (better, secondary server zone expiration
time + TTL) before deploying a certificate chain that would not
match the extant TLSA RRS.
> Third server that manages the certs and copies them to each mail
> server? A database server on one machine that the other machine checks
> for updated certs? Something else I haven’t thought of?
A push model (ssh or scp) is a reasonable minimal approach, with
appropriate authentication of the target. In larger environments, there
are these days orchestration systems for credentials, and servers can
contact services that vend the certificates the server is entitled to
present.
--
Viktor.
