Bruno Tavares asked:
So my problem is simple I just need a solid answer so that I don’t break the email service.
I have two servers one for mail and other for the web service. The web server is responsible for the SSL certificates renewal (I’m using Let’s Encrypt Certificate Authority).
My DNS A record is mail.example.com and points to the mail server IP. The MX record points to that A record.
The SSL certificates validation is made via DNS so I added another A record with the same hostname (mail.example.com) but pointing to the web server IP.
I tried this for a little while and It worked out (the validation succeeded and the mail service worked normally) but im not 100% sure about it and led me two the following thoughts:
1 – The A record for the web server was added after, so in the DNS query the mail server IP comes first, and because of this everything works fine.
2 – I read somewhere that the in the browser the DNS queries results are used in a random order. If the first IP can’t serve HTTP requests the second will be used. I’m not sure about this but could it be that for the mail service the same happens? If the first IP resolved does not accept mail, it will try the second one?
I would like to be clarified about this because I wan’t to be 100% sure of what is happening and why, to prevent any problems in the future.
This is the wrong approach for getting Let’s Encrypt certificates for a mail server with no installed web server.
Instead, you should use certbot’s standalone plugin. With this, certbot starts its own built in temporary web server to perform the HTTP validation.
You request a certificate for the name corresponding to the value of your MX record. For instance, if you have the domain example.com and your MX record points to mail.example.com, then you request a certificate for mail.example.com, the IP address for which must point only to that mail server.
certbot certonly --standalone -d mail.example.com
You can then add the resulting certificate links in
/etc/letsencrypt/live to your mail server configuration.
Note that when you
certbot renew, your mail server won’t be restarted automatically. You’ll need to set up a
--post-hook to do that. For example:
certbot renew --post-hook "systemctl reload postfix dovecot"
For further information on automating certificate renewal, see Cron job for let’s encrypt renewal.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.