I've just moved my Let'sEncrypt certs to a new server for two domains with community help!
Now I want to install a signed certificate for my mailserver. I'm not asking for the mailserver-specific side, but for advice on what sort of cert I need.
The mailserver accepts mails for the two web domains, but the account (the MX record for both domains) is the server hostname.
I guess that the cert that the mailserver uses should be for the server hostname, and no doubt it is a different type to the HTTP ones I currently have.
Can someone point me to instructions on how to create the sort of key and cert that a mailserver needs for TLS. And will these be suitable and valid if I symlink to them from the filepaths my mailserver uses by default?
LE only provides one type of cert: DV
Which can be used by many devices and service (including email servers).
The best configuration would be one that can be fully automated.
In order to best advise you on how to achieve that, we would have to know some specifics/details.
Like:
Is the mail server running on the same system as your web server?
[if so, things are simpler; if not, then there are some considerations to deal with and overcome]
Do you have root access to these system(s)?
[there may be more questions depending on your answers]
That seems to imply that the email server is on the same system - but I take nothing for granted.
Symlinks usually work but that is a general permissions issue.
If they don't work via symlink, it is very simple to include in the process script to copy the files needed to another folder/path where the email system can access them.
Yes, I see @JuergenAuer point too and agree.
Both names use the same IP - why have two names?
Email server don't care what name is used (so long as it matches the cert).
It's rather simple: you need the hostname used by a TLS client in your certificate. But as this differs per situation:
For a MTA (mail tranfser agent) connecting to the MX record through SMTP you need the hostname of the MX record in your certificate
For a MUA (mail user agent), you need to add the hostname which is entered by the user in their MUA to your certificate. If you use separate hostnames for SMTP and/or IMAP (i.e., smtp.example.com for the SMTP server and imap.example.com for the IMAP server), you'll need to add both to the cert.
Apparently the GDPR regulations are causing many MTAs to require TLS, and I'm second-guessing the cert details that will satisfy current and future verification checks. The problem is that exim4 my mailserver by default only uses one key and cert. So if a sender to domain 1 sees a cert for domain2 it may flag it up as suspect or refuse to send.
Maybe I should designate the same domain for the MX for both. This would probably need to be grepnik.default.grepnik.uk0.bigv.io (which I'd thought was used as the MX record). And then I wonder if some MTA might find that suspect too!
There may be a way to ask the mailserver to use different certs for each domain, but exim4 is an ugly beast to configure and I'd rather go for the simplest solution that will look valid to a sender.
mail11.web-server.biz is a mail server from my dns provider I use. Because I don't want to manage an own mail server.
So you can centralize a lot of mail services from different domains to one domain address.
But then use a domain you control - not something like grepnik.default.grepnik.uk0.bigv.io.
There are a lot of mail configurations that are too complicated - subdomains imap/pop3/smtp, three different certificates, but the same ip address as the main domain. So it's easier to use the main domain with the three ports and only one certificate. So the webserver certificate can be re-used.
Thanks to all. I'd drafted a long reply but have found out more since.
I find that in fact I can set any domain for my MX, it doesn't have to default. So to follow Juergen's suggestion I could set the MX for both domains to the domain name of either of them, and symlink that domain's key and cert.
I don't have control over grepnik.default.grepnik.uk0.bigv.io in the sense of setting DNS records. But it is "mine" and has my server's static IP address. Also it maps to my webserver's docroot so it could be used with port 80 validation.
I've just run certbot certonly -d grepnik.default.grepnik.uk0.bigv.io --apache --dry-run successfully so unless there are reasons why it would be a problem I propose to install it and use that domain for both domains' MX records.
To add a further element, not contradicting anything other people have already said:
Many TLS mail relay systems (that is other servers which are using SMTP to transfer mail to your server for whatever reason, not client software running on somebody's phone or desktop) don't actually examine your certificates. They're engaged in what is called "Opportunistic TLS", they would have been willing (perhaps reluctantly) to send email to you without any security, so it's pointless for them to be picky about certificates. If your server is properly set up, these relays receive all security benefits unless there is an "on path attacker" able to pretend to be your mail server to them and intercept the email. The certificate's benefit is to eliminate this possibility by making it impossible to impersonate your server (as only your real server can demonstrate ownership of the trustworthy certificate) but all other benefits of TLS are achieved through the correct configuration of the server independent of certificates.
In fact, I'm using STARTTLS (at least for mails I send) which is opportunistic. A server move and an upgraded Exim4 server now causes a nag to be logged for every mail handled. And I was told I'm not offering "TLS" (as opposed to STARTTLS?) so many EU mailservers will refuse to send to me, under the requirements of the GDPR. Do you know if STARTTLS should be OK for this?
I don't see why you would need a cert for: grepnik.default.grepnik.uk0.bigv.io
Unless you plan on serving content securely from it...
Email servers (unlike web servers) really only need one name and cert.
But rg305, are you saying that it doesn't matter what name is on the cert? It doesn't need to match the MX record? Unless that's true, to use an existing cert I'd have to set domain1 as MX for both domain1 and domain2. Even if a sending MTA didn't care, it just looks weird!
I don't think it's a correct thing to say "Because MTA's don't check certificates anyway, I don't have to get the certificate correct.." That's a catch 22!
I think @rg305 says here is that the hostname grepnik.default.grepnik.uk0.bigv.io isn't used, so it doesn't have to be in the certificate.
I don't have specific knowledge about exim. We're straying away from the purpose of this Let's Encrypt forum, and you might be better served asking exim experts about a nag (error log message?) that you are worried about but aren't sure you understand.
Unless things have changed radically since this was a focus for me, STARTTLS is the way a TLS session begins for SMTP MX rather than (as is normal for say HTTP) the entire protocol just being wrapped with TLS on a separate port.
So Osiris, I should use the server hostname in the exim cert, and as the MX for both domains. My MUAs use the server hostname as the SMTP server, so a cert for that name seems necessary.
I'm sure you're right about STARTTLS tialaramex. It's not the warning message that bothers me, more the suggestion that some mailservers will refuse to send to me if they don't see a cert they consider valid.