Hello again masters, I please ask again for your help.
Question1: When trying to configure a local Outlook email client, it returns a certificate error; it searches for a certificate that was apparently created when I first installed Hestia (print attached , exhe01 is the hostname where runs HestiaCP). This entry that it finds is not on my external DNS server (Cloudflare). Where do I find this entry in Hestia to point to the correct entry for Hestia’s letsencrypt certificate (mail.domain)?
Question2: I created pop, smtp, imap entries in my cloudflare, pointing to the mail.domain entry (which points to the HestiaCP / Exim IP), I can access these new entries + mail ports via telnet from my station, but I cannot use them in my Outlook client or another like Gmail for mobile. I see in the dovecot log that it apparently closes communication in the initial test, but the error screen returns. The error only disappears when I manually place the mail.domain entry on the incoming and outgoing servers, which should be being translated by DNS…Where am I going wrong?
When you add a mail domain in Hestia and you add a certificate to that mail domain, Hestia request a certificate valid for these domains (I will use example.com as domain):
So, if you want to configure a mail client like Outlook, you must configure it adding manually mail.example.com as the host for smtp, imap and pop3, you can’t use smtp.example.com, imap.example.com etc. because even if those domains point to your server, when you try to connect, exim and dovecot will try to find a certificate for smtp.example.com, imap.example.com but there is none because the certificates and the conf point to mail.example.com and that’s the reason for the error, as they can’t find it, they use the default certificate that is the cert for your server hostname.
Said that, use always mail.example.com to configure the hostname for smtp, imap and pop3 in your email client.
Yes @sahsanu, the letsencrypt certificate at the addresses webmail.example.com and mail.example.com were already working in email clients, as long as they were configured manually as you mentioned. The question is where, and why the Outlook email client was automatically searching Hestia for a certificate that shouldn’t exist! The scenario I’m experiencing is that I’m migrating an email server to Hestia, and more than 200 users work remotely. They have different settings in their email clients. They use mail, pop, imap, smtp addresses… (not my fault, I swear! ) To avoid having to interact with these 200 users, I asked about a way to create these entries in Hestia.
We found a solution in the Hestia WEB panel that worked very well so far:
We created a web entry for the address that was appearing in the Outlook email client (exhe01.example.com), and created the nicknames I needed for the email clients (pop, smtp,imap). We activated letsencrypt for this domain and “voilà, vive hestiaCP ! ”, Outlook and other email clients worked like a charm, and stations pre-configured with alias addresses (a lot in imap mode ) didn’t even notice the change
I’ll monitor how it works over the next few days, and hoping that you don’t alert me that my solution has some flaw (just kidding, I’m always listening and grateful for your help )
Happy to be in the HCP community. Great week to everyone
Well if it works, perfect but that is a workaround, you are saying to your Exim and Dovecot servers to use always the default certificate because they won’t find a certificate for the subdomains the user will try to use The main issue is if you use different domains but if you only use one domain or the other domains don’t need this workaround, then I see no more issues.
For existing users this won’t work (they should reconfigure the mail account in their mail clients) but for new users or new configurations, you could implement autoconfig and autodiscover methods to be able to give your users the right conf automatically.