On another forum, someone who knows more about email than i, outlined that the following are options with SSL Certs: In shared scenarios people will either: 1) Use a SSL with SANs to cover all domains 2) Use multiple IPs to handle the traffic (being phased out and no longer really accepted) 3) Use 1 domain name that has a published cert and redirect traffic to that It really depends on what you are trying to accomplish and how much time / money / effort you want to invest If you are trying to setup a shared hosting service, maybe have a look at Plesk or WHM as it will do most of this for you Option 3 above is the model I believe i currently use in Postfix, however, whenever new clients configure their email client apps they get an invalid SSL certificate error. My understanding is that this is always a problem with shared hosting. 1. If I decided to choose option 1, how do I get the existing SSL with SANs to update to automatically add new users to the host SSL with SANs certificate when they sign up for services in ISPConfig? If using a Letsencrypt cert for the Server (i dont know if Letsencrypt actually does this btw), would we have to manually reapply or SSL or the host every time? -can this be automated based on new clients? -Is it achieved via a cron? -What is the procedure for creating a cron that would perform this task for the host SSL? 3. Is SSL with SANs the same as Wildcard, or does Wildcard only apply to subdomains of VPS host fqdn?
1) I call these certs just multi domain ssl certs, but my term might not be the right technical term. There is a limitation with that, you can have max. 100 domains in one LE SSL cert. There is currently no way to automate this in ISPConfig, you will have to write your own script to do that. 3) Wilcard is subdomains only, so this does not help you when dealing with different domains. Personally, I don't use any of these three. My mail systems have just a single hostname and all clients sue that hostname to connect to it, so there is just one ssl cert with one domain inside needed. That's the way most hosting providers do it as it also strenthens your brand by using your company name (domain) for the mail system and not a domain of a customer.
A So can you post 1. an example of what your client dns mxrecords look like (substitute real names for ficticious obviously) Im also hosting both email and websites on same host...does this change mxrecord? I assume not? 2. Example of incoming and ougoing mail server settings they would use for desktop pc and mobile email apps. If i could see these with real life examples i think might be able to put the pieces together. I get confused with the use of host.fqdn and domain.com. working examples are so much more meaningful (kind of like using a persons "name" vs calling them generically "mate" when introducing to someone else)
What do you mean by client MX record? The MX record is created on the e-mail domain. If I have domain taleman.ovh, I create MX record on that domain and record poinst to the FQDN of the e-mail server that received e-mails for that domain. If you have another e-mail domain, say xyzzy.tld, you create MX record on that domain with the same FQDN if the same e-mail server receives e-mails also for xyzzy.tld. It does not. These are from Thunderbird running on Linux: I grabbed the above images from my unpublised Tutorial. It has been unpublished for two months now.
Thanks Taleman. I don't have any problems with my own domain...it's the client ones that are getting invalid ssl cert warnings when they setup their email apps (outlook etc) If you also had shared client domains on your system using just your server ipaddress...What would their mx record need to be to avoid the invalid ssl cert warning? Also what incoming and outgoing settings would they be using in their client email apps? I'm currently using one of the following for clients domain1.com MX mail.domain.com mail.domain1.com.com A record <server IP addrese> OR domain1.com MX mymail-server.fqdn (e.g. or google mail server) No ipaddress for mail because that dns is resolved externally But I still get invalid ssl cert warnings when clients use my mail server and setup their email apps. How do we stop the invalid ssl cert warnings? Is it because I am using a letsencrypt/certbot SSL for my server?
Tell them to use the hostname of your server as smtp/pop/imap server in the mail client and NOT a subdomain of their own domain which does not exist in the SSL cert, see post #2.
The MX record must point to the e-mail server that receives e-mail for that domain. So if you have this one e-mail server, the MX record is the same. The same settigs for all domains. The e-mail server is the same for all domains. This way also the certificate works, since that e-mail server has an OK certificate. If you use mail.clientdomain.tld the certificate is not valid for that hostname.
