> [3] Speaking of letsencrypt ... requesting, generating and implementing SSL certs (even for use on the web) is simply creating, and trading, blocks of plain old ASCII text. I haven't looked into this, but is there an "expert mode" somewhere in letsencrypt where I don't have to run webserver instances and ... I can just run openssl command lines and cut and paste blobs of ASCII ?

Let's Encrypt provides an ACME service. So, you will want to (run something that can) speak ACME, a somewhat RESTful HTTP API documented in RFC 8555 - https://tools.ietf.org/html/rfc8555. You can use a web service to do this part, but then you're relying on some random web service and you have to manually do a bunch of steps to renew at least every 90 days which I'm going to assume you agree sucks.

There are lots of people who have built such tools that can look after this for you automatically, perhaps you would like https://acme.sh/ which as its name might suggest is a shell script.

Let's Encrypt offers three of the (increasingly misnamed) Ten Blessed Methods, you can prove control over a DNS name by doing any of these three things:

1. Running an HTTP server on port 80 which can answer certain well-known requests in a specific way acknowledging your ACME keys. This server needn't have any privileges, acme.sh can help you spin one up that will basically say "Yes, rsync is allowed this certificate" for any request. Except instead of "rsync" it's a key only you have, so your server answering this way never helps any bad guys so long as you keep your ACME keys secure. [You may not be aware you have "ACME keys" the software you've used probably just minted some and squirreled them away in a dot directory]. With that server in place, your requests for a certificate for that name will always work, because the key matches, Let's Encrypt will call your server, make up a random nonce and ask if that's authorised and for who, your HTTP server will always answer "rsync is authorised" so it works, tidy.

2. ALPN on port 443. A TLS server answering port 443 can accept a special ACME-only ALPN protocol choice from the Let's Encrypt servers and use that to prove control. You almost certainly don't want this unless you implement web servers (which run on port 443 with TLS already)

3. DNS queries for a magic name that can't be a hostname. The queries ask for _acme-challenge which has an underscore in it. Underscores are allowed in DNS but can't be hostnames, which is fine because this isn't a hostname. Your ACME client will need to write to DNS, it can either have a way to write to your actual DNS, or you can use a CNAME to redirect the names you need to another DNS server and give the ACME client control over that. [Edited to fix DNS name mistake]

You can insulate the ACME client from the server completely with either the trick I described in (1) or using DNS like (3) and using a Certificate Signing Request, CSR, which is one of the many ASCII text blobs you can get from OpenSSL. If you're comfortable re-using a private key for longer periods than the 90-days assumed in Let's Encrypt (a 2048-bit RSA key seems safe to me for the usual lifetime of a mailserver) you can even re-use the same CSR again and again to request each new certificate without sending any data from the mail server to the system calling Let's Encrypt.

You will need to arrange to get each new certificate installed (the private keys don't change in this scenario). But certificates are public documents, if it came to it the mail server can (this is very silly but it would actually work) just wait until 24h after the certificate should have been issued and then go get it from https://crt.sh/ -- In reality you can probably find some sensible way to get this public information back to the mail server each time the certificate is renewed.