Many le ssl certs assigned to postfix

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: case is related with each domain on the server

I ran this command:

It produced this output:

My web server is (include version): Apache/2.4.33 (Ubuntu)

The operating system my web server runs on is (include version): ubuntu 16.04 lts

My hosting provider, if applicable, is: ovh

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): ISPconfig3 3.1.11


I have server created based on Perfect Server tutorial for Ubuntu 16.04. Is it possible to assign to postfix/dovecot as many lets encrypt ssl certs as possible? I have 20 domains on the server but postfix uses ispserver.crt and ispserver.key certs generated by letsencrypt:

lrwxrwxrwx 1 root root       48 Mar 13 07:42 smtpd.cert -> /usr/local/ispconfig/interface/ssl/ispserver.crt
lrwxrwxrwx 1 root root       48 Mar 13 07:42 smtpd.key -> /usr/local/ispconfig/interface/ssl/ispserver.key

which are from:

lrwxrwxrwx 1 root root   50 Nov  3  2017 ispserver.crt -> /etc/letsencrypt/live/s1.example.net/fullchain.pem
lrwxrwxrwx 1 root root   48 Nov  3  2017 ispserver.key -> /etc/letsencrypt/live/s1.example.net/privkey.pem

For each domain except server fqdn I have certificate mismatch in mail client. Sending emails works but I would like to fix certs mismatch.

http://www.postfix.org/TLS_README.html#server_cert_key

There are no plans to implement SNI in the Postfix SMTP server.

To the best of my understanding, Postfix is very primitive when it comes to TLS support on the server side.

The lack of SNI support in the server would mean that it is not possible to have separate certificates served by a single instance of Postfix. You could have a single giant Let's Encrypt certificate with all of your tenant domains on it, but I don't believe its at all viable in practice due to the need to constantly re-issue the certificate when domains are added/removed.

You might consider replacing Postfix with Exim, which does support SNI and is deployed widely to take advantage of it (for example, in all cPanel installations), or potentially fronting Postfix with an external TLS proxy like haproxy/nginx etc. In particular, I believe nginx supports STARTTLS.

1 Like

Thank you for answer. I am not happy that I use postfix which is unable to use SNI.

The nginx proxy idea seems like a good one—I just learned about that quite recently on this forum. In that case nginx can probably handle the certificates on behalf of Postfix, and you can continue using Postfix for the e-mail service.

1 Like

Main developer of Postfix - Wietse Venema - on postfix mailing list said in reply to my problem:
"Postfix does not yet support SNI, so you would need to update master.,cf
with one smtpd definition per IP address with its own smtpd_tls_*cert_file
and smtpd_tls_*key_file.

But why? SMTP is not HTTP. With SMTP, the MX records for different
domains can contain the same SMTP server hostname."

But I am not sure what he advices. Should I setup in some way MX record with only SMTP server?

Normally user@domain1 receives their emails through an SMTP server that is NOT the same “domain1”.
It doesn’t have to be and it usually isn’t.
If it did have to be that way, systems like Gmail, Outlook and Yahoo! would all be overwhelmed by the number of unique entries and corresponding TLS certificates they would require.

So you only really need one FQDN per system.
Just have your users update their MX records to use your service name.

(If you service anyone other than yourself, you are an ESP - act like one - LOL)

Thank you for answer. My server fqdn looks like s1.example.net. On this server I have few domains, like do-main.pl, anotherdomain.com etc. Each of them has own MX record like mail.do-main.pl and mail.anotherdomain.com etc. but the server uses s1.example.net domain and for this domain is provided lets encrypt ssl. In this case should I change in each domain’s dns zone MX record to this one provided for s1.example.net?

yes. using only s1.example.net would fix the problem.
Be sure to consider related controls (like: SPF), if this will also be affecting your outbound emails.

Much like a DNS service provider uses their DNS server names and IPs for all their customers.
ESPs use their SMTP server names and IPs for all their customers.

Unless you are trying to provide some “white-label” type SMTP service, I don’t really understand the use case to even try to use unique server names.

1 Like

Thank you for answer. Exactly, I use SPF and sometimes DKIM. I will consider this way. What are “ESPs”? I think that “white-label” type of SMTP service is currently above of my knowledge. Could you point to some valuable sources? Currently I have easy configuration, i.e. one domain.com + own MX record like mail.domain.com. :slight_smile:

Email Service Providers

Implies non branded - generic - services.

Ok, so I should understand your earlier message like you don’t understand using one mail domain for each domain deployed on the server, am I right?

It’s very common for the mail server address to be on a completely different domain than the email domain. If done correctly, with suitable autoconfiguration setup at the ESP end, this can even be nearly transparent to the user. A setup like this will greatly simplify your use of encryption on the mail server, and is what the postfix developer you’re quoting is recommending.

If you are adamant that the mail server domain must be the same as the domain of the email address, then things are much more complicated for you.

Thank you for answer. I will update dns zone of each domain with s1.example.net as mailserver.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.