Resolved SSL certificates for mail server

[campsjos]

I configured my server to have "mail.serverhostname.tls" as secured mail server and works as expected. However, I have not succeeded configuring my domains to have "mail.mydomain.tls" also secured.

The problem is that I need to migrate a lot of customer sites and domains from a non-plesk server to my new plesk server and it would be great if the customers can keep it's original mail configuration (mail.customerdomain.tls) without having to "confirm security exceptions" nor change the IMAP/SMTP addresses.

There is an article in the Knowledge Base covering exactly what I'm trying to achieve: Warning during mailbox creation in mail client: This site attempts to identify itself with invalid information

The article shows 3 possible workarounds:

1. Manually set server's hostname during mailbox creation instead of domain's name.
   - Actual configuration, works but that's not what I need.
2. Confirm Security Exception. The certificate will be applied. However, it is necessary to be sure that the certificate is secure and valid.
   - Not a solution.
3. In DNS settings of the domain set MX record value as <hostname> instead of mail.<domain>.
   - Done, but mail client still complaining about the certificate because mail.myclientdomain.tls is identifying itself as mail.serverhostname.tls

The 3rd solution seems to be the logical one but I can't get it working.
This is how I have my MX record right now:

• Host: mail.customerdomain.tls.
• Record type: MX (10)
• Value: mail.serverhostname.tls.

Can anybody tell me what I'm doing wrong?
Thanks!

 

[campsjos]

I have tested customerdomain.tls in this SSL checker site and it seems to be all correct. However, Thunderbird keeps asking to "Confirm security exception"...

 

[mr-wolf]

You forgot to blank one of the domain entries ;-)

To your question....

You may have a valid SSL-certificate, but that one is only valid for mail.xxxxx.space (just checked it). You can't use that properly for other hostnames without telling the client to make an exception for that. So that other domain you're using for it, doesn't work. Only mail.xxxxx.space

Since there is SNI (Server Name Indication) for https it's now possible to run different certificates for webservers. AFAIK this is not possible for IMAP, POP or SMTP.
The MTA has no way of knowing which hostname is used for connecting to it.
With http(s) this hostname is sent by the http-client. Both with SNI and in the page-requests.
Because it doesn't know the hostname, it therefore presents only 1 certificate.


For my firm I have solved this problem.
It does need a wildcard certificate, but these aren't that expensive anymore.
On the mailservers I have a wildcard certificate named *.wolf.com (not the real domain name)

For each client I have created a cname that points to its mail.<domain>
Because wildcards go only 1 level deep, I need to replace the <dot> with a <hyphen>

This is a cname in the company's zone. Not in the client's zone!!!

proton-space.wolf.com     IN CNAME  mail.proton.space.

This proton-space.wolf.com is what the user needs to enter in his mail program to stop having this certificate error. It matches the wildcard on the server.


I don't think the 3rd option is correct.
The MX-record's name is not being used to my knowledge at all. It can stay mail.proton.space

MTA = Message transfer agent - Wikipedia
MUA = Email client - Wikipedia

MTA's use the MX-records to connect to other MTA's, but it's quite common that these don't correspond. I have no knowledge of that being a problem when connecting.
MX-records are not being used by MUA's .

IBTW..... MX-records should be A-records. CNAMES are non RFC-compliant, but AFAIK this doesn't have any ill effect.

I have a script that automagically creates these CNAMEs for all my clients.

I also have autodiscovery mechanism that will fill in these values for our clients.
Alas, this only works for Thunderbird and Outlook. Apple Mail doesn't.

There is also RFC RFC 6186 - Use of SRV Records for Locating Email Submission/Access Services, but I don't know of any mail client that uses it.
I made some effort to get these into all my clients only to find out they are not getting used.

The (Microsoft) autodiscover record would be like this:

_autodiscover._tcp.proton.space.             IN SRV 0 1 443 proton-space.wolf.com.

You need to use the SRV-record.
You can't have an autodiscover cname as it will then use https://autodiscover.proton.space and we don't have a certificate for that.
Be aware of wildcards. Many Outlook clients will give repeated autodiscover messages because it thinks that the wildcards are autodiscover.<domain> records. The certificate on that server quite often doesn't match the domain name, so the end user is getting all kind of stuff he doesn't understand. Quite often the provider doesn't understand it as well.
Why Microsoft doesn't give precedence to an SRV-record is also strange.

The webserver at https://proton-space.wolf.com will have that same *.wolf.com wildcard certificate and will therefore work (otherwise it will give errors there as well).
Luckily the Mozilla-method is simpler as it uses plain http to http://autoconfig . proton.space

autoconfig.proton.space     IN CNAME  mail.proton.space.

Your webserver on the mailserver would still need to respond properly.


Because you don't have a wildcard certificate you can only use mail.proton.space in your MUA (I checked your actual certificate on port 25,110,143,465,993 & 995).
It's correctly configured but with a MUA only 1 domain is possible.

 

[campsjos]

Well well well, this is a really good answer, @mr-wolf ! Thank you very much!
However, it is also too good for my knowledge about DNS and mailservers, I'm the classical developer forced to deal with servers

So let me see if I understood what you explained here:

1. I forgot to blank a domain in the image. Dammit, LOL.
2. The only way to avoid the security exception error is use in the MUA the domain name that I set as mail certificate in /admin/ssl-certificate/list or buy a wildcard certificate and use it as server-wide mail cert, apply the CNAME records as you described, and even doing this, the client will have to write a URL that isn't his domain (proton-space.wolf.com instead of mail.proton.space, in your example).
3. I can make this process easier for my customers configuring autodiscover/autoconfig records. (nice one!)
4. With plesk, at this moment there's no way to use mail.customerdomain.tls without confirm security exception.

Extra: Is this feature request the solution for what we are discussing here? Or is the currently enabled "Certificate for securing mail" feature in /admin/ssl-certificate/list ?

Thank you again!

 

[mr-wolf]

1. I forgot to blank a domain in the image. Dammit, LOL.
   ;-)
2. The only way to avoid the security exception error is use in the MUA the domain name that I set as mail certificate in /admin/ssl-certificate/list or buy a wildcard certificate and use it as server-wide mail cert, apply the CNAME records as you described, and even doing this, the client will have to write a URL that isn't his domain (proton-space.wolf.com instead of mail.proton.space, in your example).
   URL is not the right name for it. Hostname is.
   Yes, that's correct.
3. I can make this process easier for my customers configuring autodiscover/autoconfig records. (nice one!)
   
4. With plesk, at this moment there's no way to use mail.customerdomain.tls without confirm security exception.
   Nothing to do with Plesk itself.
   There are no protocols that would allow you to do this.
   
   Before SNI Server Name Indication - Wikipedia it wasn't possible to use more than 1 certificate on 1 IP. The browser would first resolve the hostname and then connect to the IP. The web server could then offer only 1 certificate.
   Now the browser also supplies the hostname it was referring to. This means that the server is able to quickly lookup a certificate that belongs to that hostname and start negotiating the SSL-connection. Until the SSL-connection is established there is nothing read from that browser.
   Until then it was not possible to do "virtual hosting" for https.
   It is still NOT possible to do "virtual hosting" for stmps, pop3s and imaps

No, this is only webmail (https)
For imaps and smtps you need 1 certificate that matches the hostname.

By using the trick I came up with, I'm avoiding the problem that begins when I start moving a mail-account to another server.
When I would want to move a client from ns1.wolf.com to ns4.wolf.com I would have to phone him and tell him to change his mail client.
That's undoable.
Now he will use proton-space.wolf.com (a cname to mail.proton.space).
If I change the server and change mail.proton.space his MUA will automatically connect to the new server that also has this certificate.

I can tell you another downside of using the client's hostname (mail.proton.space).
To my dismay I noticed that Apple Mail doesn't like it if the certificate is renewed. It then suddenly wants you to reaffirm this exception.
The client will then start to call you because he's not getting any mail.
This sometimes happens a month or weeks after the certificate is renewed.
The renewal of certificate is a process that should be transparent. Apparently the programmers at Apple have other ideas about that.

When the hostname corresponds with the certificate you will not have that problem.

 

[campsjos]

Ok @mr-wolf , many thanks again for your clarifications.

When I would want to move a client from ns1.wolf.com to ns4.wolf.com I would have to phone him and tell him to change his mail client. That's undoable.

I'm at this exact point, I need to migrate a dozen of sites with their corresponding dozen of email accounts each one from one server (administrated, no plesk) to a new one (plesk, no administrated). So thats why I'm trying to make this process as transparent for the final user as possible.

So, I going to enable mail.customerdomain.tls for each domain, some users will accept the certificate, some other probably have the connection unsecured and some others will call me and I will tell them to change the hostname to mail.myserver.tls.

Thank you!

 

[mr-wolf]

3. I can make this process easier for my customers configuring autodiscover/autoconfig records. (nice one!)

I forgot to comment on this one.
The autodiscover / autoconfig DNS-records are not enough
Each Plesk server should also run a PHP-script on its website that will supply the credentials.

In the beginning I had some problems getting it to work
I was helped here:
Resolved - Enable a PHP socket for nginx for custom website outside Plesk

If there's enough interest I could write a separate thread on this.
Posting some of the scripts behind it and the concept.

I was quite happy when I had everything working.
Some disappointment came when I noticed that Apple Mail didn't make use of any of the 3 discovery methods.


Without a wildcard certificate for your own domain this isn't worth the hassle.

I also have an hourly cronjob that will create the cnames for me (and deletes them).
You need to do their DNS-hosting as well for this to work properly.

I create a DNS-record to their mail.<domain> and one to their <domain>
This way the web-server can be on another Plesk than their mail-server.

https://www-proton-space.wolf.com:8443 will give no certificate error neither would https://proton-space.wolf.com:8443