I have an issue which is preventing migration of some clients from cPanel to Hestia.
Some mail clients default to using the domain eg “example.com” as the incoming/outgoing server, but for me Hestia currently only generates dovecot SSL certificates for “mail.example.com”
Most clients have only “example.com” configured as inbound/outbound server, and this breaks mail for them after migration.
How can I resolve this?
When you add a certificate to a mail domain, Hestia creates this conf in Dovecot (file /etc/dovecot/conf.d/domains/example.net.conf)
local_name mail.example.net {
ssl_cert = </home/YourUser/conf/mail/example.net/ssl/example.net.pem
ssl_key = </home/YourUser/conf/mail/example.net/ssl/example.net.key
}
That means that Dovecot will offer that certificate if the mail client uses mail.example.net as the hostname to connect to.
To resolve your issue, you must add a wildcard certificate for your domain, this wildcard cert must be valid for *.example.net AND example.net.
When you add a certificate like this to your mail domain, Hestia configures Dovecot this way:
local_name example.net {
ssl_cert = </home/YourUser/conf/mail/example.net/ssl/example.net.pem
ssl_key = </home/YourUser/conf/mail/example.net/ssl/example.net.key
}
local_name mail.example.net {
ssl_cert = </home/YourUser/conf/mail/example.net/ssl/example.net.pem
ssl_key = </home/YourUser/conf/mail/example.net/ssl/example.net.key
}
So the mail clients will be able to connect to example.net and Dovecot will offer the right certificate.
The way to add a wildcard certificate will depend, if you use Hestia as the DNS server for your domain, you can issue a wildcard certificate directly from Hestia. If you use a third party DNS server, you need to figure out how to issue and add the wildcard certificate to Hestia (I use acme.sh client to issue these certificates).
I use the “Use Let’s Encrypt to obtain SSL certificate” and it issues the certificate to “mail.example.com” with alternate of “mail.example.com, webmail.example.com”.
I think the most sensible option would be to also include alternate for “example.com” in the Let’s Encrypt request.
Is this possible?
Another possible solution might be to have an option to include the web server certificate ( /home/example/conf/web/example.com/ssl/example.com.pem/key ) in the list of local names for dovecot. Those are in my case managed by Hestia (Let’s Encrypt) as well.
I think automating this or having an option to do one of these would be a very nice feature to have. As it stand I have to fiddle with the dovecot conf file, and I am not sure if this will be overwritten at some point by Hestia.
When issuing a mail certificate and using Hestia to obtain a Let’s Encrypt certificate, no, it isn’t possible.
Anyway, it won’t work because in Dovecot, when using local_name, Dovecot will offer the certificate assigned to that local_name, so if the local_name is mail.example.net, doesn’t matter whether the assigned certificate includes example.net, Dovecot won’t offer that certificate because example.net is not included in a local_name directive.
Yes, you can do that and edit the Dovecot conf file manually BUT if you rebuild the mail domain that conf file will be overwritten. You can add the immutable attribute to the conf file chattr +i file so it can’t be edited/removed but that is pretty ugly.
As I said in my previous post, the best approach is a wildcard certificate.
When issuing a mail certificate and using Hestia to obtain a Let’s Encrypt certificate, no, it isn’t possible.
This is not true.
It can be done by changing line 123 in v-add-letsencrypt-domain:
- aliases="$WEBMAIL_ALIAS.$root_domain"
+ aliases="$WEBMAIL_ALIAS.$root_domain,$root_domain"
Let’s Encrypt now correctly issues the certificate with the domain.tld alias, and Hestia automatically also adds local_name domain.tld in the dovecot conf file.
Yes, it is. You must modify that script to work to fit your needs, that means that Hestia doesn’t support it and it will be removed on next update so keep that in mind.
My suggestion was to add this feature as default, so I interpreted your answer as “it is impossible to request the domain.tld alias when using let’s encrypt”.
This seems to me like a very simple fix which would save a lot of people who are migrating or considering migrating from other panels. A lot of these users have “domain.tld” configured as their incoming/outgoing servers.
Yes, but not all users point their base domain to Hestia or not the same Hestia server and you’ll generate a problem to that users not be able to generate a certificate for the mail domain.
Indeed the main reason why we do not support it. And implement custom (sub-)domains is currently out of focus as it would need a few rewrites of the mail stack.
So there is no way to resolve this problem then when using just the options available in the GUI?
I do not see any option to request a wildcard certificate there.
If you know what you’re doing, you can use our after install hooks of the hestia package to adjust the file again and make it changeproof. But still your system would be out of support, it could lead to issues if we change it sometimes.
Wildcard can only be requested if you’re running a hestia dns cluster, as it needs a dns verification.
My guess is that for the vast majority of users do have their domain and mail hosted on the same server ( when they are using Hestia for mail ). However I understand your concern is breaking compatibility for users where this is not the case.
A solution which does not require many changes would be having a input box where the user can input custom aliases, which the v-add-letsencrypt-domain script can allow with only a slight modification.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.