Certificate for SMTP TLS

Help
#1

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?

Sample e-mail address handled anyuser@notjustcamden.uk
Server name grepnik.default.grepnik.uk0.bigv.io
Running exim4 on Debian 10

1 Like
#2

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.

1 Like
#3

Hi @grepnerd

your configuration looks a little bit curious.

If you use that mail address, notjustcamden.uk is relevant, the part after @.

D:\temp>nslookup -type=MX notjustcamden.uk.

notjustcamden.uk MX preference = 10, mail exchanger = a.mx.notjustcamden.uk

So a client would connect a.mx.notjustcamden.uk, so you should have a certificate with that domain name.

And you should use that domain name as pop3 server / imap server too.

But the A of notjustcamden.uk is 46.43.2.88, a.mx.notjustcamden.uk has the same ip address.

So you don't really need a.mx.notjustcamden.uk, you can use notjustcamden.uk directly. There you have already a certificate, you can re-use it.

But that requires that you change your MX record.

3 Likes
#4

Thanks rg305

Yes, mailserver and webserver are on the same system. I have root access.

2 Likes
#5

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).

Name:    a.mx.notjustcamden.uk
Address: 46.43.2.88

Name:    notjustcamden.uk
Address: 46.43.2.88

Unless you expect to split these services to different IPs soon, you can use the same name and IP.

OR

You can get another cert for the email server as it is named - LE certs are FREE ! ! !

1 Like
#6

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.
1 Like
#7

Thanks again Juergen.

The mailserver receives mails for notjustcamden.uk and aeolian.org.uk. I see that the MX for these are a.mx.notjustcamden.uk and a.mx.aeolian.org.uk. These resolve to the same IP as the server, grepnik.default.grepnik.uk0.bigv.io.

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.

#8

The actual hostname configured on the host itself is not relevant regarding TLS certificates. Only the hostname used by the TLS client is relevant.

#9

That's not a problem. See one of my own domains:

D:\temp>nslookup -type=MX sql-und-xml.de.
...
sql-und-xml.de MX preference = 10, mail exchanger = mail11.web-server.biz

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.

1 Like
#10

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.

1 Like
#11

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.

1 Like
#12

Thanks tialaramex

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?

1 Like
#13

It should be OK.

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.

#14

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!

#15

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.

Please see my earlier "it's rather simple" reply: Certificate for SMTP TLS - #6 by Osiris

1 Like
#16

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.

1 Like
#17

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.

#18

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.

#19

Your users are typing grepnik.default.grepnik.uk0.bigv.io as their SMTP and IMAP servers in their Outlooks and Thunderbirds?

1 Like
#20

Normally, I would say: Never use such a domain name

grepnik.default.grepnik.uk0.bigv.io .

Nobody want's to use that name.

But:

D:\temp>nslookup 46.43.2.88

Name: grepnik.default.grepnik.uk0.bigv.io
Address: 46.43.2.88

So the reverse ip is that domain name.

A mail server should have such a configuration.

Conclusion: If you can't change the reverse ip of 46.43.2.88 to one of your shorter domain names: Use that long and terrible name.