• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Securing webmail.domain.tld

Chrisa

Basic Pleskian
I'm looking for a way to specify 2 different ssl certificates for 2 different webmail accounts (webmail.domainA.tld & webmail.domainB.tld) BUT the default certificate always seems to apply


Tools & Settings | SSL Certificates | 1 Self-signed Cert for webmail.domainA.tld & 1 for webmail.domainB.tld

Tools & Settings | SSL Certificates | default certificate = webmail.domainA.tld

(A & B have 2 different IP addresses)
Tools & Settings | IP Addresses | IP for domainA.tld | ssl cert = webmail.domainA.tld
Tools & Settings | IP Addresses | IP for domainB.tld | ssl cert = webmail.domainB.tld

domainA.tld | Web Hosting Access | IP for domainA.tld
domainA.tld | Hosting | ssl = Let's Encrypt for domainA.tld, www.domainA.tld
domainA.tld | SSL Certificates = No effect on webmail.domainA.tld


domainB.tld | Web Hosting Access | IP for domainB.tld
domainB.tld | Hosting | ssl = Let's Encrypt for domainB.tld, www.domainB.tld
domainB.tld | SSL Certificates = No effect on webmail.domainB.tld

When I browse to https://webmail.domainA.tld & https://webmail.domainB.tld I can see the default ssl cert listed. If I change the default it changes for both webmail sites.

Thanks
 
hello,
its normal let's encrypt is not supported with wildcard unlimited sub-domain, need to use wildcard ssl for doing that without more config
 
Last edited by a moderator:
After a couple of days of research I'm not sure that this can be done. I would appreciate a confirmation from someone more knowledgeable about securing multiple webmail.domain.tld within a single plesk account.

At the end of this thread (https://talk.plesk.com/threads/roundcube-webmail-ssl.310916/#post-743043) the conclusion seems to be that if there is more than one domain only one certificate will be visible for all the webmail.domain.tld domains in the plesk account.
"I don't think we have individual options to secure the webmail domains."
"No we don't. I find the best option is to tell all customers to use the main url, same with Plesk itself."

I found a possible alternate solution, redirect from webmail.domain.tld to https://domain.tld/webmail and then the webmail would fall under the Let's Encrypt cert but just like the poster, I had the same errors and the thread did not end in a resolution.
(https://talk.plesk.com/threads/webmail-question.326784/#post-780422)

So to summarize here is my two part question:
Is it possible to have 2 different domains load 2 different certificates for https://webmail.domain.tld ?
AND/OR
Is it possible to redirect from webmail.domain.tld to https://domain.tld/webmail ?

Thanks in advance for any help.
Chrisa

I forget to put this in at the start
Details:
Plesk 12.5.30
OS Ubuntu 14.04.4 LTS
# apache2 -v
Server version: Apache/2.4.7 (Ubuntu)
 
Hi Chrisa,

Is it possible to have 2 different domains load 2 different certificates for https://webmail.domain.tld ?
AND/OR
Is it possible to redirect from webmail.domain.tld to https://domain.tld/webmail ?

This IS possible, if you have different IPs for each domain, but you have to manually edit "/etc/nginx/plesk.conf.d/webmail.conf" and "/etc/apache2/plesk.conf.d/roundcube.conf" ( or "horde.conf" if you use Horde ).

Example for nginx:

For each IP, you have parts like :
Code:
server {
    listen XXX.XXX.XXX.XXX:443 ssl;
    server_name roundcube.webmail horde.webmail atmail.webmail;
    server_name webmail.* roundcube.webmail.* horde.webmail.* atmail.webmail.*;
    include "/etc/nginx/plesk.conf.d/webmails/*.conf";

... where the depending certificates are defined :

Code:
    ssl_certificate             /opt/psa/var/certificates/cert-XXXXXX1;
    ssl_certificate_key         /opt/psa/var/certificates/cert-XXXXXX1;
    ssl_client_certificate      /opt/psa/var/certificates/cert-XXXXXX2;

If you now follow the suggestions from @Lloyd_mcse , he changed as well the certificate - location ( see : https://talk.plesk.com/threads/roundcube-webmail-ssl.310916/#post-743046 ), which will lead to having one certifiate for all IPs.
You can certainly leave out this part and edit "/etc/nginx/plesk.conf.d/webmail.conf" manually, with the desired locations of your domain - specific certificates :

Code:
    ssl_certificate             /YOUR/LOCATION/TO/YOUR/WEBMAIL-CERTIFICATE;
    ssl_certificate_key         /YOUR/LOCATION/TO/YOUR/WEBMAIL-CERTIFICATE-KEY;
    ssl_client_certificate      /YOUR/LOCATION/TO/YOUR/WEBMAIL-ROOT-AND-INTERMEDIATE-CERTIFICATE;

You don't need any redirects, but you should now control your modifications in case of updates/upgrades/patches and in case that you add/modify your DNS - settings, which may lead to the command "/usr/local/psa/admin/bin/httpdmng --reconfigure-all" being executed ( and your manual modifications will be lost ).


Your goal is not possible to achieve, if the different domains use the same IP.
 
Hi UFHH01,
Thank you very much. That's very helpful information. I have one quick follow up question. Is the 2nd part of my question a possible solution?
Is it possible to redirect from webmail.domain.tld to https://domain.tld/webmail ? (If this is possible it might be a better choice)
Thanks again.
Chrisa
 
Hi UFHH01,
I'm working on your instruction above and have a question:
.., but you have to manually edit "/etc/nginx/plesk.conf.d/webmail.conf" and "/etc/apache2/plesk.conf.d/roundcube.conf" ( or "horde.conf" if you use Horde ).

Both the files /etc/nginx/plesk.conf.d/webmail.conf & /etc/apache2/plesk.conf.d/roundcube.conf have a warning that the files will be overwritten.

Should I create a custom directory under plesk.conf.d and cp webmail.conf & roundcube.conf and edit there?

Thanks Chris
 
@Chrisa,

There are simpler ways to achieve what you want, by simply using Nginx.

However, I am aware of some pitfalls in the Plesk setup and Nginx configuration with respect to webmail, so it is not as straight forward as it should be.

But I am fairly sure (understatement) that you do not want or need to modify Apache related files: you should want to use Nginx to point to the Apache "domain" containing webmail.

In short, do NOT change anything on the Apache side, that would be equivalent to creating additional problems or, in the best case scenario, doing unnecessary work.

Moreover, you should note that the whole concept might not even be possible, due to the nature of Plesk configuration, mainly Nginx configuration, unless you want loops.

But there is always the (less desirable) option to create some Nginx directives, pointing to the roundcube default location, but I am not in favour of this approach.

As a final remark, I am following this thread for some time now, being rather curious about the final endresult.

One thing that amazes me is the lack of contribution by other forum members, those from Plesk Team in particular.

Give me a couple of days (due to limited time available) and I will test the one (less desirable) option that I know of, hopefully I can present this and another option to you.

If I do forget, please send me a PM (hover over my profile and start a personal conversation) and remind me.

Regards.....
 
Hi trialotto,

Thanks for your response. I did manage to get individual domains to see a certificates other than the default SSL after UFHH01 was kind enough to point out each domain will need it's own IP for this to happen.

My original hope was to be able to redirect https://webmail.domain.tld to https://domain.tld/webmail as this would be covered under the Let's Encrypt certificate but I don't this is practical based on UFHH01's last comment [https://talk.plesk.com/threads/change-webmail-domain-com-to-domain-com-mail.338156/#post-802563]

I'm going to recap my steps here so others can easily follow this:

How to specify 2 different ssl certificates for 2 different webmail accounts
Prerequisite = 1 IP per domain

Step 1: Creating manual certificates or uploading external certificates (startsll.com has free certs for personal use)
Tools & Settings | SSL Certificates | Add Certificate | Select create Self-Signed (or optionally select Buy SSL Certificate)

Step 2: Assign new certificate to IP for the domain in question
Tools & Settings | IP Addresses | Select IP | Select SSL Certificate from drop down
NOTE: local certs at the domain level are not available in this list

Step 3: Repeat steps 1 & 2 for each domain that requires a unique ssl certificate


Regards...
 
@Chrisa,

I am a little bit confused here, for many reasons. And I believe that I am not the only one.

Moreover, there are multiple threads, with multiple original questions, that have lead to many new questions, slightly different from the original ones.

Let´s return back to basics.

I will try to post some of the before mentioned questions (in my own words), to answer them and to create "assumptions", that can take us one step further.

a) is it relevant that there are one, two or more IPs? No, not at all, it is irrelevant.

b) is it possible to assign a certificate to one, two or more domains? Yes, via Let´s Encrypt, the default certificate and paid-for certificate.

Assumption: we want Let´s Encrypt (henceforth: le or LE) certificates. Note that is assumption is resulting in a more "flexible endresult", a proof of concept.

c) is it relevant that there are one, twor or more domains or subdomains? Well, no, it should not be relevant, but it is actually.

Assumption: we want to have one domain.tld and one subdomain (sub.domain.tld) and this is already a challenge, due to the default configuration of Plesk.

Note: as a result of the default configuration of Plesk, it might be required to use two domains (domainA.tld and domainB.tld) instead. We will work this out in due time.

d) is it relevant to use https instead of http? No, completely irrelevant, it should work in both scenario´s.

Note: we will not make any assumption here, but it has to be stated that https redirection makes life a little bit easier, but the challenge a little less challenging.

e) do we want to edit or change default config files like webmail.conf or roundcube.conf? No, not at all.

Assumption: we want to keep it clean and use the default Nginx configuration structure, without any danger of automatic overwriting of config files at update time.

Note: this seems to be easy, but it actually is not, the default Nginx configuration is rather messy and has its (completely unnecessary) limits (that we have to deal with).


The goal would be: "Create the URL domain.tld/webmail that resolves to the Roundcube Panel".

My question to you is the following: is the goal and are the before mentioned "assumptions" in lign with what you want to achieve?

Just let me know.


As a final remark, note that achieving the goal would imply that the questions in

Is it possible to have 2 different domains load 2 different certificates for https://webmail.domain.tld ?
AND/OR
Is it possible to redirect from webmail.domain.tld to https://domain.tld/webmail ?

would be answered with a (practical) solution, ready to be implemented.


Hope to hear from you,

Regards.....
 
Hi trialotto,

I am a little bit confused here, for many reasons. And I believe that I am not the only one.

I agree, there are several threads with multiple possible solutions and many dead ends. Let me clarify the original goal. Once these threads are resolved, a summary will help future readers find the appropriate solution without getting lost in the details. (This is what I was attempting to do with the note above: How to specify 2 different ssl certificates for 2 different webmail accounts)

Original Goal: Secure entire domain using Let's Encrypt (including webmail and external email programs like Thunderbird).

Result: I was able to secure https://domain.tld with Let's Encrypt and even achieve an A rating at https://www.ssllabs.com in an effort to make the domain PCI DSS compliant.

Problem: I thought I was done and then realized that although https://domain.tld was secure https://webmail.domain.tld was not.

In my research I came to the conclusion that the free Let's Encrypt certificate does not cover subdomains like https://webmail.domain.tld so an additional solution was needed for this.

I found a thread that seemed to cover that and tried to implement the solution:

Webmail question
https://talk.plesk.com/threads/webmail-question.326784/#post-780422
Result: No resolution to thread. In the final entry omexlu12 indicated the tasks were performed as required but there was no further response from anyone.

As a result I created a new but similar thread:

change webmail.domain.com to domain.com/mail
https://talk.plesk.com/threads/change-webmail-domain-com-to-domain-com-mail.338156/
Result: This approach did not work and even if it did it would make future support more difficult as it required customization of files which is not recommended.

Based on this it seemed that an additional certificate would be needed to secure https://webmail.domain.tld.
1. In my initial testing I discovered that all https://webmail.domain.tld domains in a single plesk account read the default ssl certificate [Tools & Settings | SSL Certificates]
2. In a discussion with UFHH01 it seemed the solution to prevent each https://webmail.domain.tld in the plesk account from reading the default ssl certificate was individual IPs for each domain. (This does work)

Chrisa - Is it possible to have 2 different domains load 2 different certificates for https://webmail.domain.tld ?
UFHH01 -This IS possible, if you have different IPs for each domain

I tested using different IPs for each domain and discovered I could use two different self signed certificates for two different domains provided that they had different IP addresses.
When that was confirmed I posted the solution above How to specify 2 different ssl certificates for 2 different webmail accounts

My summary so far:
1. Let's encrypt will secure https://domain.tld & https://www.domain.tld but NOT https://webmail.domain.tld
2. With a single IP, all webmail domains (https://webmail.domainA.tld, https://webmail.domainB.tld, etc) always use the default ssl certificate [Tools & Settings | SSL Certificates]
3. With an IP per domain, it is possible to have each webmail domain load a separate ssl certificate (see above: How to specify 2 different ssl certificates for 2 different webmail accounts)

If it was possible to have Let's encrypt cover the https://webmail.domain.tld as well that would be the ideal solution. The solution would need to cover email programs like thunderbird as well as https://webmail.domain.tld.

(From the point of view of a non-technical website owner they would want a secure domain, secure webmail and a secure email program. Thunderbird [& webmail] generate a 'scary' warning when using the parallels cert or self signed cert so providing an option for the customer to purchase a 3rd party certificate to remove the 'scary' warning seemed like a reasonable approach. Some customers will want to purchase the additional cert, others when faced with the option of spending more money may decide the self signed cert is ok;))

NOTE: When I refer to domainA.tld & domainB.tld I am referring to two completely different customers (i.e plesk.com & cpanel.com would be good examples)

I hope this helps clarify that tasks at hand.

Thank you for your interest in this thread.

Have a good day:)
Chris
 
@Chrisa, Chris,

Thanks for the excellent and elaborate feedback. It certainly is valuable, even though I only had a quick view at it.

Let me explain a bit about the difficulties, associated with Plesk and its default configuration for Nginx and Apache.

Apache "runs the show", when it comes to webmail: in short, it is pointing to "/usr/share/psa-roundcube".

All "normal" configuration for webmail is actually done on the Apache side, which causes some problems due to the particular construction of the "main" roundcube config file, that (on its turn) is difficult to change manually (given the automated generation of these files) AND is problematic in the sense of the ServerAlias used (default format: webmail.<domain>.<tld>).

Nginx, as a reverse proxy, would be able to provide some options to "work-around" the Apache issues related to automated config generation and chosen ServerAlias.

In fact, it is "would", not "can", in the case of Plesk.

A simple explanation exists: in short, the concerning Apache configuration is more or less copied to (read: translated to) Nginx configuration.

In essence, some of the Apache side flaws are also present on the Nginx side, implying that a very drastic "work-around" on the Nginx side would be required.

In addition, the default Nginx configuration is an "odd ball" and contains many peculiar config settings and even obsolete config files.

This is rather important in your case.

Consider the config files in the directory "/etc/nginx/plesk.conf.d/webmails" and move one .conf file to a file with extension .conf.bak (so Nginx will not recognize it as config), restart Nginx and you will see that actually nothing happens: the webmail can still be opened with the url webmail.<domain>.<tld>.

I made a lot of comments to Plesk Team about the strange or incorrect design structure of Nginx, but to no avail. I have given up.

Anyway, the above mentioned (remarkable) endresult is an illustration, that clearly indicates the problem we are facing:

1 - it is not wise or easy to change something on the Apache side, amongst others for the sake of security and performance,
2 - it is not "good practice" to point Nginx directly to "/usr/share/psa-roundcube" (read: possible, easy to implement, but certainly not wise to do so)
3 - it is not really easy or even possible to achieve all your goals with some simple Nginx directives (read: a complex set of Nginx directives is required)

Point 3 follows from the facts that

a) the server_name directive, starting with webmail.*, in the /etc/nginx/plesk.conf.d/webmail.conf file is making sure that

- any (Nginx based) redirect, from <domain>.<tld>/<name> to the Nginx handled domain webmail.<domain>.<tld>, will result in a forward of requests to the Apache handled "domain" (read: ServerAlias) webmail.<domain>.<tld>, which is good, (and)
- a forward of responses from the Apache handled "domain" to the client, which is bad, since the response header contains webmail.<domain>.<tld>,

b) the creation of an Apache handled domain, being the subdomain webmail.<domain>.<tld>, can rule out the "bad" behaviour, as mentioned in point a,

c) the creation of the (sub-)domain, as mentioned in point b, will make roundcube unavailable on both the domain and subdomain, as a result of default configuration,

and even though point c is an illustration of "good practice" (with undesirable consequences), point c hints a solution.

Nevertheless, the before mentioned solution is a solution involving a dedicated domain for webmail and other domains that allow (Nginx based) redirection to the webmail domain.

Even though this solution does not seem to fit your wishlist, it actually does: all webmail.<domain>.<tld> point to the same, being "/usr/share/psa-roundcube".

Only problem is that I do not want a "fuzz" with two domains, that is not practical and potentially dangerous in terms of management and security.

In short and in conclusion, to satisfy your wishlist, one has to battle some elemental flaws in the default Plesk configuration, in particular that of Nginx.

Why only Nginx? Well, there is not that much wrong with the configuration on the Apache side, it is only inconvenient, in the sense that

- Nginx has to be used to create a "location based solution" (read: "location" as in the Nginx directive), when wanting to have webmail on an URL similar to <domain>.<tld>/<name>
- Nginx has to be used when wanting to keep (Apache and Nginx) default config files intact, whenever possible

and the inconvenience on the Apache side only follows from the fact mentioned in point c above.

As a final remark, I have been testing some of the settings on the Apache and Nginx side and...........available time suddenly did not exist anymore, due to other tasks/jobs.

Apologies for the late response!

Ciao!
 
@Chrisa,

In retrospect, I have to comment to

I tested using different IPs for each domain and discovered I could use two different self signed certificates for two different domains provided that they had different IP addresses.
When that was confirmed I posted the solution above How to specify 2 different ssl certificates for 2 different webmail accounts

My summary so far:
1. Let's encrypt will secure https://domain.tld & https://www.domain.tld but NOT https://webmail.domain.tld
2. With a single IP, all webmail domains (https://webmail.domainA.tld, https://webmail.domainB.tld, etc) always use the default ssl certificate [Tools & Settings | SSL Certificates]
3. With an IP per domain, it is possible to have each webmail domain load a separate ssl certificate (see above: How to specify 2 different ssl certificates for 2 different webmail accounts)

and, with all due respect, state that it is a tiny bit of humbug: not correct at all.

In essence, one does not need different IP addresses: everything can be done in a "regular" way, at least in theory.

Again, I have to illustrate the above by pointing out some design flaws in the default Plesk configuration.

For the sake of simplicity, I will illustrate the scenario in which a Nginx proxy is active.

This scenario and illustration more or less applies to the scenario without an Nginx proxy, just remember the statement that "the concerning Apache configuration is more or less copied to (read: translated to) Nginx configuration".

Anyway, let´s continue with the Nginx based scenario.

Nginx handles all incoming (including internal) requests for webmail.<domain>.<tld> with the server blocks from the /etc/nginx/plesk.conf.d/webmail.conf file.

The above implies that all webmail (clients) for all domains are using the (same) ssl certificate, as specified with the corresponding Nginx directive in webmail.conf.

This also implies that one can manually add a letsencrypt based to webmail.conf (or one of the included *.conf files), but again, the "flaw" of (on the one hand) autogenerated config files and (on the other hand) obsolete config files (read: the included *.conf files) is present.

At best, one would be able to edit webmail.conf, until some future (micro-)update changes webmail.conf.

Another "flaw" is present, which is related to (on the one hand) the Plesk Let´s Encrypt extension, that is not able to allow definition of letsencrypt certificates via the Plesk Panel for any domain with an URL structure of the nature webmail.<domain>.<tld> and (on the other hand) the fact that webmail is not available on the (entire) domain, if a subdomain of the kind webmail.<domain>.<tld> exists.

However, letsencrypt binary and, if I am not mistaken, the Plesk Let´s Encrypt command line utility are (both) able to create (and automatically renew!) letsencrypt certificates for any domain of the kind<sub>.<domain>.<tld>, including the domains where <sub> equals "webmail".

In short, it is possible, but one has to dig deep (in code and persistent methods) to allow for letsencrypt automation of (different!) ssl certificates for each (sub-)domain.

Again, I mentioned the potential issues with the Plesk Let´s Encrypt extension, even before it was formally included as a package, but to no avail. Again, I have given up.

Anyway, all of the above indicates that an usual and exceptional combination of "flaws" (sounds a little bit more friendly) is getting in the way.

In fact, the root cause of the problem (here) is that webmail is absent, if a subdomain webmail.<domain>.<tld> exists.

However, each domain and correspondings subdomains can be secured with individual (read: different!) ssl certificates (read: letsencrypt based certificates), that are not equal to the default Plesk certificate.

If only we had an update of the Plesk Let´s Encrypt extension AND a possibility to allow webmail on subdomains of the kind webmail.<domain>.<tld>!

In short and in conclusion, no particular relevance for IPs in the whole story, only relevance for an usual and exceptional combination of "(design) flaws".

Sure, a solution can be found with a Nginx based redirection OR an entire new server block, with custom handling for specific webmail clients (the latter solution did not test very well, given that one really is stuck to the default webmail.conf configuration).

Again, work in progress, but with a lack of available time, it is a hard nut to crack (and I am getting nuts, given some peculiar config files).

Regards.......
 
Last edited:
Has there been any progress on this? This thread has not seen a response in nearly a year. Could it really take that long for Let's Encrypt to get their sh*t together and fix this so that wildcards are covered for each domain? Can someone update me on where this issue stands because the way Google has started warning visitors of sites with self signed certs has impacted my traffic and reputation.
 
@Heath,

It is possible to secure the webmail subdomain of a specific domain.

Just go to the domain in question and

1) Let´s Encrypt (click) > Secure webmail on this domain (check the checkbox) > OK or Enter (click),

and

2) Hosting Settings (click) > Permanent SEO-safe 301 redirect from HTTP to HTTPS (check the checkbox) > OK (click)

and that should be all.

Note that you can encounter some issues when not typing the https:// prefix in a browser, for instance when you previously opened the site in the same browser (without having executed the two steps above).

Just type the https:// prefix and you can verify that the green lock is there, implying that the webmail subdomain has been assigned Let´s Encrypt certificates.

Regards..............
 
I guess they must have updated Let's Encrypt after I posted that message. It was not there last time I checked. In any case that works fine for the webmail. But I am still having an issue with mail clients. In Outlook I am getting an "Internet Security Warning" that reads "The server you are connected to is using a security certificate that cannot be verified. The target principal is incorrect." If you view the certificate, it is default the Plesk cert, and not the let's encrypt cert. So you have to click yes to continue, but it just keeps popping up every time there is a send/receive.

Any idea how I can get it to read the correct cert in Outlook 2013?

149twlk.jpg

1zx2x6o.jpg
 
Make sure that you have installed a certificate for the mail server (Tools & Settings > SSL certificates), then use the host name in Outlook to connect to the mail server, not the domain name. If you have not installed a certificate for the mail server, only the default certificate will be available and Outlook will display just that.
 
Back
Top