Hi there! I am running a "webserver" for me and a few friends. Everything seems to work as it should, but i am having problems to understand ssl / mail config or the concept behind it. So, my server is setup with a name like "server.domain.tld" and it has a letsencrypt certificate. There are ~10 email domains configured for <5 "isp clients". all have their mx in dns set to "mail.maildomain.tld" so for example "mail.maildomain1.tld" "mail.maildomain2.tld" and so on. when i telnet to any of them, for example "telnet mail.maildomain1.tld" i get a response from "server.domain.tld". and its the same for all mail-domains. The ssl cert presented is also always the one for "server.domain.tld". Is this... "correct"? I guess that this would be correct if the letsencrypt certificate would include all mail-domains as san but without? Not sure if i am overthinking this but... maybe someone can help me to understand this better. Thanks!
Hi Till! Thanks for your response. I am not sure which section of the mail guide you are referring to? Maybe i didnt express myself correctly: i am talking about multiple domains controlled by different clients (ISPConfig Clients). So Client1 might have X mail domains and each of them Y mail accounts. the domains all have a mx set (mail.maildomain1.tld or mail.maildomainXY.tld for example) that points to the single static ip of the "server.domain.tld" so a client adding a imap account to thunderbird for example would put in: "mail.maildomain1.tld" as server address... But that would lead to a hostname mismatch because the client would get a ssl cert from "server.domain.tld" instead of the "mail.maildomain1.tld" cert. Thats why i am asking about Subject Alternative Names in den server certificate used.
i guess i found what you are referring to: Would that problem be solved by including the customer domains as SAN in the servers certificate?
The mail guide explains that you must use the server hostname to connect to the mail system as the SSL certificate is issued for the server hostname. Your server hostname is server.domain.tld, so you use server.domain.tld as imap/pop3 and SMTP server. And that's what the guide explains. The mistake you made with your telnet command is that you are using the wrong subdomain; the correct subdomain would have been server.domain.tld. So to test your mail server, use: telnet server.domain.tld and not telnet mail.maildomain1.tld That's not what a client would do. You should really have read the email account guide where I posted the link to, its explained there.
The problem is solved by using the right hostname as outlined in the guide. You do not use any other third party subdomains to connect to your server, you use the domain / subdomain of the provider. using external third party domains in your SSL cert is possible, but it will limit the scalability and reliability of your system. But if you just run a home server, then reliability and scalability might not matter for you. In that case, you can use the following small system workaround as described here: https://www.howtoforge.com/securing...server-with-a-valid-lets-encrypt-certificate/
the server was previously hosted on a server that was controlled through plesk and before that it was confixx i believe.(yes, that server goes a looong way back) both handled that differently and i guess thats why the problem emerged in the first place. nevermind. easy enough to tell the couple of users to use the isp domain instead of their own ones. it "just" means that they have to modify a decent numer of mail clients to use a different server url.
They did not handle that differently. The only difference I could imagine here is that the autoconfig worked here and the mail clients "guessed" the correct servername, ports and encryption settings.
