I am extending my use of Let’s Encrypt certification from Apache to Postfix/Dovecot, over a (small) number of domains.
Reading ‘here’, many folk seem to use multiple names per domain, eg www.domain.tld, smtp.domain.tld, imap.domain.tld, mail…domain.tld, webmail.domain.tld, etc.
In Apache, I’ve set up ServerAlias www.domain.tld under (virtual) Server domain.tld, ie the names become synonyms. Currently, I have Thunderbird interacting with Postscript (SMTP) and Dovecot (IMAP) using domain.tld only; thus relying upon the ports (25 and 143) and protocols instead.
What is the advantage in listing so many server names on the certificate, as opposed to using just one ‘everywhere’?
It depends how people configure their email clients.
In the end, your SMTP server is only going to have one canonical hostname - let's call this smtp.example.org. So, the certificate needs to at least be valid for smtp.example.org for the server to be able to securely communicate with other MTAs.
Next, users come into the picture. People might configure their clients' SMTP server to connect using any of the following hostnames:
smtp.example.org
smtp.mydomain.tld
1.2.3.4
etc
In order for them to be able to send their email securely (over TLS/STARTTLS), the certificate must be valid for the name they choose. Otherwise their clients will fail to connect to your SMTP server.
The easiest thing to do is for everybody to configure the canonical server name (i.e. smtp.example.org) in their clients, and have only that name on Postfix's certificate (and Postfix only supports a single certificate, unlike Dovecot). Otherwise you are responsible for the ability to be able to renew a certificate that is valid for dozens, hundreds etc of domains that you may have no control over. That's not fun.
Surely it doesn’t matter if the SMTP server is called example.org or smtp.example.org PROVIDING the certificate (inspected by other MTAs) uses the same name - per your STARTTLS advice?
As to users, they expect me to tell them how, or to perform one-off tasks (such as email client configurations) for them. Accordingly, name variations are not expected/controllable, in this instance - I’m only talking half-a-dozen domains on a VPS and not an ISP/hosting situation!
If I understand you correctly, that's right. The name can be anything you want, as long as the canonical name matches the certificate name, and the email clients use that name. Everybody has to be on the same page, basically.
Apologies, I may be over-reacting to what was written:
Researching the topic, I had understood that Postfix would accept a "SAN" format certificate, which chains domain names together under one certificate. Thus, (am only testing with one domain name, at present) with a certificate name of "VPS" I was hoping to be able to string together domains: a.tld, b.tld, c.tld, etc, each of which is a separate domain (and users) under Postscript/Dovecot. (each of which would become smtp.domain.tld, according to other reply) Perhaps I have misunderstood (Postscript or the SAN-certificate concept)?
Alternatively, does the term "everybody to configure the canonical server name" (emphasis on the "the" - singular) imply that I should set-up one Postscript SMTP server, eg using the VPS' domain name, and then configure each domain's client software to use that server/name despite it being different from their own domain name - which, without reviewing the details, seems to conflict with SPF and other security measures?
Apologies, I've probably misinterpreted your intent... =dn
_az, the [quote="_az, post:4, topic:67032"]
Everybody has to be on the same page
[/quote] part is what makes sense to me. Thus only using domain.tld on the certificate AND in the Postscript cf file, the Apache vhost .conf file, etc, is putting all the servers “on the same page” as well as (my) configuring all the client s/w consistently.
Yes, that's my personal view of what you should do. If Postfix actually supported SNI (multiple certificate support, like Exim does), then I would support the idea of giving one certificate to each domain. But, it is operationally a giant pain in the ass to do multi-tenant Postfix SAN certificates.
It is just a personal opinion though - plenty of operators DO use the SAN approach.
However,
That's not the case. SPF/DKIM/DMARC all work just fine with "generic" server names.
_az, you have been most generous with your time. Thank you.
Would you mind explaining:
If renewal is cron-automated and doesn't need a list of domains or even certificates, that is zero-effort.
(speaking selfishly) I only have a small number of domains to administer. Is the "pain" related to the sheer number of domains administrated?
Reading the docs, I thought to write a bash script (or even use the cli.ini configuration file), rather than type the entire command each time - especially starting in the staging server sand-box to get things right first. This would avoid the need to type long lists of domain names (etc), each time. (I'm also looking into the (new-ish) idea of wild-card domain certificates - but have yet to experiment, figuring that the 'small number' and 'bash script' ideas might avoid any need for such extra complication)
Does that avoid said "pain" or is there some other aspect I have yet to realise?
I imagine that the pain is mostly when you have to change the certificate coverage somehow (adding new names or removing old names), or if you have enough domains that they won’t fit in one SAN certificate (more than 100, by Let’s Encrypt policy), or perhaps if you might have some users with very old clients that don’t understand SNI.
Hence the idea of a short script - otherwise I’m likely to try ‘extending’ a certificate but accidentally leaving-off something very necessary from the ‘old list’…