• 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

Resolved Let's Encrypt SSL issue on shared hosting (when using port 8443).

seqoi

Regular Pleskian
I'll try to describe my problem by describing my process (perhaps i am doing something wrong in the order).

Plesk Version 17.8.11 Update #50. Fresh install few days old, trial. Everything default. VPS edition.
‪CentOS Linux 7.6.1810 (Core)‬

I intend to use it to host three different domains. Which i already created and domains are working fine.

So i have Plesk installed on Cloud server (Hetzner). I get the server hostname and IP address.

I log in to Plesk as admin.

1. I initiate Add customer and enter all data. For domain i enter (for this example) www.domain1.com. Ok user is created successfully. If i enter http://www.domain1.com everything is fine i see that initial Plesk landing page. Still not SSL secured but ok i know what to do.

NOTE: I have my DNS zone management at cloudns.net and obviously before i even started at step 1 i made sure i added my domain1.com records there and www.domain1.com is pointing to my server hostname and IP address at Hetzner.

2. From my Plesk Admin session i log in to customer panel via "Log in as Customer" option. I am in "Websites & Domains". All fine.

3. I proceed to Let's Encrypt and there i enter email address
- Include a "www" subdomain for the domain and each selected alias" is checked
- Secure webmail on this domain - is checked

I initiate process and everything is green. It says certificate generated with success. All fine Let's Encrypt cert is installed. While still in "Websites & Domains" i go to Hosting Settings - Security just to make sure is everything fine. There i see SSL/TLS support is checked. Also i checked "Permanent SEO-safe 301 redirect from HTTP to HTTPS".
Under Certificate i see "Lets Encrypt domain1.com (domain1.com)" is selected. So all seems fine right?

4. I type https://www.domain1.com and lo and behold - it's working!!! Green lock in firefox and it says your connection is secure. I go to certificate details and i see it's issued to my domain1.com.

5. I type webmail.domain1.com in browser and it's working!!! It automatically redirects me to https probably because "Permanent SEO-safe 301 redirect from HTTP to HTTPS" is checked. All fine follow me please. Here is my issue.

6. I type https://www.domain1.com:8443/ - and Firefox gives me warning?!?? Connection is not secure!

Can anyone tell me why is that? I tried to read articles before i posted here but i couldn't find any solution. I am reading this article about SNI support SSL/TLS and Shared IP Addresses but there it says my version of Plesk have SNI enabled by default. I tried to restart server but nothing happened same issue.

Another details.

When i visit https://www.domain1.com and connection is secure - i go to certificate details and i see this:
Certificate Hierarchy:
Let's Encrypt Authority X3
domain1.com

but

When i visit https://www.domain1.com:8443/ and connection is NOT secure - i go to certificate details and i see this:
Certificate Hierarchy:
Let's Encrypt Authority X3
i see my hetzner hostname here NOT my initial domain name to which let's Encrypt cert was issued to.

It appears to me that when i am using port 8443 on domain1.com - Plesk is switching to different certificate but i don't know why is Plesk doing that? Because as i described under customer domain1.com "Websites & Domains" and hosting settings i double checked and definitely that Lets Encrypt certificate is selected and when i type https://www.domain1.com - all is fine. It just doesn't work when i add 8443 to it.

I also found this article but it may not be related: Plesk self-signed certificate is displayed instead of the one signed by a public CA: The certificate is not trusted

scroll down to the response of user Alexandr Redikultsev

In my case i have Tools & Settings > IP addresses (note my real ip address is different 111. is just for example)

IP address: 111.111.111.111. /255.255.255.255

interface: eth0
IP Type: shared
Sites: 03 (which are those three sites i mentioned above)


When i click on my IP address i see that SSL/TLS certificate value is preselected to "default certificate". Default site is set to "none". I can switch it to "Lets Encrypt" value. Which i did and i restarted server but my issue did not went away so i returned this to how it was (default certificate).

Any help?
 
It appears to me that when i am using port 8443 on domain1.com - Plesk is switching to different certificate but i don't know why is Plesk doing that? Because as i described under customer domain1.com "Websites & Domains" and hosting settings i double checked and definitely that Lets Encrypt certificate is selected and when i type https://www.domain1.com - all is fine. It just doesn't work when i add 8443 to it.
You are absolutely right. The reason for this is that content served at domain1.com and content served at domain1.com:8443 come from two different web servers.

Client pages are served by one set of nginx/apache servers, and Plesk's GUI is served by a different nginx server.

SSL certificates that are installed for domain1.com aren't automatically installed for domain1.com:8443. As it is now, all the *:8443 addresses use a single certificate. It can be configured which one under "Tools & Settings" -> "SSL/TLS Certificates" -> "Certificate for securing Plesk".

IMHO, this is a missing functionality. Customers can use Plesk by visiting any customer-domain.com:8443 address and I see no reason that certificates of all the domains couldn't be added to the admin web server on *:8443.
 
Last edited:
You are absolutely right. The reason for this is that content served at domain1.com and content served at domain1.com:8443 come from two different web servers. Client pages are served by one set of nginx/apache servers, and Plesk's GUI is served by a different nginx server
That's 100% correct, unless (see below)
SSL certificates that are installed for domain1.com aren't automatically installed for domain1.com:8443. As it is now, all the *:8443 addresses use a single certificate. It can be configured which one under "Tools & Settings" -> "SSL/TLS Certificates" -> "Certificate for securing Plesk".
That's also 100% correct, unless, again see below :)

If you are hosting a 'sensible' number of domains*** then you can use one single Let's Encrypt Multi-Domain *Wildcard SSL Certificate. This can cover all the hosted domain:8443 addresses, Plesk, Webmail and can also be replicated to be used as the 'default certificate' in the Plesk server pool for use then as the IPv4 / IPv6 addresses certificate. This is what we do. It works perfectly in all cases. The only potential drawback is the ***shown below. All the domains stlll use their own normal Let's Encrypt Certificates that are provided via the Plesk Let's Encrypt Extension. These are not affected by any of the above.

In our case, this is actually used for mail related authentication / verification configs rather than for any domain:8443 access because, we chose to re-direct any domain:8443 > host-domain:8443 and IP Address:8443 > host-domain:8443 for security reasons. The host-domain:8443 then has its own security levels applied e.g. Restricted Administrative Access / Google Authenticator etc. but if we wanted to give any of our domain customers, access to their domain:8443 then we could.

***You need to use a third party source for this (THIS is the one we use) which is fine, BUT, if it's a very large number of domains, then the 3 monthly, manual DNS verification task that's required, on each named domain, that forms part of the final Let's Encrypt Multi-Domain *Wildcard SSL Certificate that's produced, becomes quite a detailed, work intensive effort
IMHO, this is a missing functionality. Customers can use Plesk by visiting any customer-domain.com:8443 address and I see no reason that certificates of all the domains couldn't be added to the admin web server on *:8443.
Agreed (in priciple) Other than, how many Plesk users wish to give Plesk access to their hosted customers? Is that possibly the reason why it's not provided by default currently? Only Plesk know! ;) As illustrated, we don't provide that access (even though we could) but others might want to...

So... back to the original question from @seqoi :D It IS possible to do solve his https://www.domain1.com:8443/ security warnings issue, if it's really needed (and if re-directs to the host-domain:8443 alternative is not desireable) but... it's not provided by default by Plesk (as you have illustrated @Ales and it needs manual configuration / setup changes in order to achieve the end result.
 
Agreed (in priciple) Other than, how many Plesk users wish to give Plesk access to their hosted customers? Is that possibly the reason why it's not provided by default currently? Only Plesk know! As illustrated, we don't provide that access (even though we could) but others might want to...

So... back to the original question from @seqoi :D It IS possible to do solve his https://www.domain1.com:8443/ security warnings issue, if it's really needed (and if re-directs to the host-domain:8443 alternative is not desireable) but... it's not provided by default by Plesk (as you have illustrated @Ales and it needs manual configuration / setup changes in order to achieve the end result.

Before i continue i just want to say big thank you for your contribution. It really is appreciated. Thank you. I haven't tried your github script because it says it isn't compatible with CentOs - so i am affraid to mess things up. I want to do it from Plesk itself.

I don't want to be misunderstood but perhaps i can't realize what you are meaning or i just don't understand (language barrier) because your sentence "how many Plesk users wish to give Plesk access to their hosted customers? Is that possibly the reason why it's not provided by default currently?" is making big confusion in my mind. So what i will write down comes from supposed Let's encrypt perspective and its fairly straightforward and simple use.

Please tell me one reason why i wouldn't provide access to plesk interface to my customer?

From what i understand (i may be wrong) Plesk is competitive product to cPanel (just as example). One of main selling point of Plesk is ability to sell web hosting services. Or even have resellers doing it for you. It's actually advertised on their very front page.

So - case1 (i'll try to be simple):

I rent VPS or cloud server. I buy Plesk full edition. I set it up and now i want to sell some web hosting subscription to some of my clients. I find client which want to buy web hosting from me. I create my customer in Plesk (as i described above). I need and definitely want to provide him access to his web hosting area! That's normal thing for me. I never ever bought some web hosting subscription without me having at least some access to that subscription. I realize i could maintain everything for him without giving him access to Plesk area but i believe it's fair that he can use services which he paid me for in the first place. So yes i forward him to his area:

I tell him go to https://www.clientdomain1.com:8443 and use credentials i sent to you (or what he received via e-mail). But then client tell me: ok but i see security warning why is that?

I tell him what exactly? I can't tell him "aaa look this whole Plesk platform isn't constructed for subscription users only for admins" ?

Or "Look you aren't supposed to go to your Plesk area you just paid me?"
Or "look go and read article here and do it yourself How to secure a Plesk interface with an SSL certificate (Let's Encrypt / other certificate authorities)

But then he will be back to me and he will tell me what i asked in initial thread: He will tell me: i did everything by that article. My domain is properly secured but when i try to access my Plesk web hosting area i am still having security warning ? Or even worse he will tell me that he is having certificate issues with email client because obviously Outlook will pop up these warnings on each startup. Because it will not be able to find proper security certificate in SSL connection.

So what am i supposed to tell him?

With that being said i fail to understand or to believe that this is some Plesk oversight. It must be something fairly simpler. Something i missed.

I can't accept and i refuse to believe that i am the first one asking such (possibly mandatory) question?

I believe whole purpose of Plesk is that you can sell web hosting and maintain server over graphic interface.

Does anyone have any other tip or you have something else possibly?

Regards
 
Last edited:
You are absolutely right. The reason for this is that content served at domain1.com and content served at domain1.com:8443 come from two different web servers.

Client pages are served by one set of nginx/apache servers, and Plesk's GUI is served by a different nginx server.

SSL certificates that are installed for domain1.com aren't automatically installed for domain1.com:8443. As it is now, all the *:8443 addresses use a single certificate. It can be configured which one under "Tools & Settings" -> "SSL/TLS Certificates" -> "Certificate for securing Plesk".

IMHO, this is a missing functionality. Customers can use Plesk by visiting any customer-domain.com:8443 address and I see no reason that certificates of all the domains couldn't be added to the admin web server on *:8443.
Thanks. What are you suggesting that there is a solution to my problem? What do you mean when yo usay "It can be configured which one under "Tools & Settings" -> "SSL/TLS Certificates" -> "Certificate for securing Plesk". can you please clarify? There i can select only one certificate and if i am understanding correctly i did everything right and my Admin Plesk access is secured correctly. That is working. I am asking how can i solve this for my customers.

Here i am posting screenshot of my (Administrator not customer) Plesk area. Under Tools & Settings - SSL/TLS

plesk-admin-ssl.jpg


As you can see there is 1 Lets Encrypt certificate installed and selected. That "default certificate" was there right when i installed Plesk and i believe this is not one to use. That single Lets Encrypt certificate was installed to secure my own Admin Plesk access. For securing Plesk. It was done by following their article here :How to secure a Plesk interface with an SSL certificate (Let's Encrypt / other certificate authorities)

This is not customer Plesk access or their domains or subscriptions.

And this one is working just fine. Everything is working even mail services (SSL connection via outlook) are secured successfully. When i installed plesk initially i connected to it via http://myserverip:8443 but later when setting up plesk i configured my Plesk hostname (provided by hetzner) and i successfully issued Let's encrypt certificate to my server so now i am connecting to my Plesk Admin via my hostname https://static.111.111.111.111.clients.your-server.de:8443/ - and that is properly secured (111 ip is just example).

If i am understanding you correctly i am able to solve my issues somehow at this screen?

If i press change for "Certificate for securing Plesk" i then see list of five (5) certificates. One is (apparently) that which was released for securing my main Admin Plesk. It's called "Let's encrypt certificate (server pool)". It is pre-selected.

Another one is "default certificate (server pool)" which was there when Plesk installed itself. Again my understanding is that this is not one to be used.

Then there are other three certificates in the list which were issued when i was securing three domains for three different customers on their own separate subscriptions.

"Let's encrypt domain1.com"
"Let's encrypt domain2.com"
"Let's encrypt domain3.com"

From my (novice) understanding i shouldn't change this settings and that setup is right. To secure my own Plesk Admin - proper certificate is pre-selected correctly (Let's encrypt certificate (server pool))

But how can i make https://www.domain1.com:8443 secure with the same certificate which was issued by Lets Encrypt for that domain1.com in the first place?

I spent three days reading articles in Plesk documentation and as far as i can see that is not covered or i am utterly missing something really obvious.

Please help.
 
Last edited:
I don't want to be misunderstood but perhaps i can't realize what you are meaning or i just don't understand (language barrier) because your sentence "how many Plesk users wish to give Plesk access to their hosted customers? Is that possibly the reason why it's not provided by default currently?" is making big confusion in my mind
Sorry. We've no idea of the right answer to that question ourselves, so we just phrased it as an open question and then speculated that this may be / could be, one of the reasons why this is not provided by default, by Plesk. We're quite possibly wrong, which is why we later said "Only Plesk know! ;)"
Please tell me one reason why i wouldn't provide access to plesk interface to my customer?
That's a simple answer. Personal choice. You may not wish to give this level of access to customers for your own technical or security reasons / policies / experience to date etc That's the most common reason we'd guess.
From what i understand (i may be wrong) Plesk is competitive product to cPanel (just as example). One of main selling point of Plesk is ability to sell web hosting services. Or even have resellers doing it for you. It's actually advertised on their very front page
Yes that's completely correct. It also, does allow you to apply levels of your customers' control too though, to be fair plus not forgetting that you have your own options on customer access to Plesk as well (as mentioned).
So - case1 (i'll try to be simple): I rent VPS or cloud server. I buy Plesk full edition. I set it up and now i want to sell some web hosting subscription to some of my clients. I find client which want to buy web hosting from me. I create my customer in Plesk (as i described above). I need and definitely want to provide him access to his web hosting area! That's normal thing for me. I never ever bought some web hosting subscription without me having at least some access to that subscription. I realize i could maintain everything for him without giving him access to Plesk area but i believe it's fair that he can use services which he paid me for in the first place. So yes i forward him to his area: I tell him go to https://www.clientdomain1.com:8443 and use credentials i sent to you (or what he received via e-mail). But then client tell me: ok but i see security warning why is that? I tell him what exactly? I tell him "aaa look this whole Plesk platform isn't constructed for subscription users only for admins) Or "Look you aren't supposed to go to your Plesk area you just paid me?" Or look go and read article here and do it yourself How to secure a Plesk interface with an SSL certificate (Let's Encrypt / other certificate authorities) But then he will be back to me and he will tell me what i asked in initial thread: My domain is properly secured but when i try to access my Plesk web hosting area i am still having security warning ? Or even worse he will tell me that he is having certificate issues with email client because obviously Outlook will pop up these warnings on each startup. Because it will not be able to find proper certificate. So what am i supposed to tell him?
If you have a separate IP address for each domain, then what you are wanting to provide could be done very easily, but if we've understood correctly, you don't. So, as we've described, a solution exists, but is not provided (yet) by Plesk. It has to be self-created and self-managed if there are multiple domains sharing one IP Address using Plesk etc.
With that being said i fail to understand or to believe that this is some Plesk oversight. It must be something fairly simpler. Something i missed
No, it's as we said: "Only Plesk know! ;)"
I can't accept and i refuse to believe that i am the first one asking such (possibly mandatory) question? I believe whole purpose of Plesk is that you can sell web hosting and maintain server over simple interface
Yes it has been asked before, in this very forum. HERE is an old thread from last year, in which you'll see the similarities
Does anyone have any other tip?
Plesk maybe? :)
 
If you have a separate IP address for each domain, then what you are wanting to provide could be done very easily, but if we've understood correctly, you don't. So, as we've described, a solution exists, but is not provided (yet) by Plesk. It has to be self-created and self-managed if there are multiple domains sharing one IP Address using Plesk etc.
:)
Thanks for your response. No i don't have separate IP for each domain. But my case isn't exactly rare case right? Many many web hosting services use single IP on multiple domains on shared hosting.

And again thanks for your contribution. As i said i see script that you linked is not centos compatible.

I will look into another thread you linked.

I am quite shocked if what you revealed to me is really the case. That they are offering product for selling webhosting but mandatory thing like this issue is still unresolved. To be fair i am still that expecting Plesk people will answer something useful. But they are on holiday today (my guess).

Regards

p.s. i am aware that https://myserverHost:8443 gives access to all my customer domains and works perfectly. My clients can visit https://myserverHost:8443 and log in with their user Plesk access credentials i get that but i don't want this i want my customer can access their area via their own domain like it's been said it's possible to do. https://www.domain1.com:8443/
 
Last edited:
Thanks. What are you suggesting that there is a solution to my problem? What do you mean when yo usay "It can be configured which one under "Tools & Settings" -> "SSL/TLS Certificates" -> "Certificate for securing Plesk". can you please clarify? There i can select only one certificate and if i am understanding correctly i did everything right and my Admin Plesk access is secured correctly. That is working. I am asking how can i solve this for my customers.

Here i am posting screenshot of my (Administrator not customer) Plesk area. Under Tools & Settings - SSL/TLS

plesk-admin-ssl.jpg


As you can see there is 1 Lets Encrypt certificate installed and selected. That "default certificate" was there right when i installed Plesk and i believe this is not one to use. That single Lets Encrypt certificate was installed to secure my own Admin Plesk access. For securing Plesk. It was done by following their article here :How to secure a Plesk interface with an SSL certificate (Let's Encrypt / other certificate authorities)

This is not customer Plesk access or their domains or subscriptions.

And this one is working just fine. Everything is working even mail services (SSL connection via outlook) are secured successfully. When i installed plesk initially i connected to it via http://myserverip:8443 but later when setting up plesk i configured my Plesk hostname (provided by hetzner) and i successfully issued Let's encrypt certificate to my server so now i am connecting to my Plesk Admin via my hostname https://static.111.111.111.111.clients.your-server.de:8443/ - and that is properly secured (111 ip is just example).

If i am understanding you correctly i am able to solve my issues somehow at this screen?

If i press change for "Certificate for securing Plesk" i then see list of five (5) certificates. One is (apparently) that which was released for securing my main Admin Plesk. It's called "Let's encrypt certificate (server pool)". It is pre-selected.

Another one is "default certificate (server pool)" which was there when Plesk installed itself. Again my understanding is that this is not one to be used.

Then there are other three certificates in the list which were issued when i was securing three domains for three different customers on their own separate subscriptions.

"Let's encrypt domain1.com"
"Let's encrypt domain2.com"
"Let's encrypt domain3.com"

From my (novice) understanding i shouldn't change this settings and that setup is right. To secure my own Plesk Admin - proper certificate is pre-selected correctly (Let's encrypt certificate (server pool))

But how can i make https://www.domain1.com:8443 secure with the same certificate which was issued by Lets Encrypt for that domain1.com in the first place?

I spent three days reading articles in Plesk documentation and as far as i can see that is not covered or i am utterly missing something really obvious.

Please help.
We're sure @Ales will reply to your questions in due course. FWIW meantime, the reference / link we posted to another thread in post #2 (in this thread) will possibly answer some of these ^^ questions (it's down to configuration / setup) and then the answer to this question:
"...But how can i make https://www.domain1.com:8443 secure with the same certificate which was issued by Lets Encrypt for that domain1.com in the first place?"
We think is shown in post #5 of the reference / link that we posted in post #7 (in this thread)
 
Thanks for your response
You're welcome. Hope you can find a workable solution :)
No i don't have separate IP for each domain. But my case isn't exactly rare case right? Many many web hosting services use single IP on multiple domains on shared hosting
Yes indeed, we'd guess the vast majority! Like you, we also have many domains > One IP address setups, but all are on cloud servers with full root access, so in our case, there's no shared hosting with others (like VPS) so it's a slightly easier challenge (by comparison) to yours but... those same basic Plesk rules still apply to us too.
p.s. i am aware that https://myserverHost:8443 gives access to all my customer domains and works perfectly. My clients can visit https://myserverHost:8443 and log in with their user Plesk access credentials i get that but i don't want this i want my customer can access their area via their own domain like it's been said it's possible to do https://www.domain1.com:8443/
Yes, (we think) that's possibly been answered now? It's currently down to Full Root Access Y/N / Number Of IP Addresses / Number Of Domains / Then... If there's a desire to invoke the described workaround OR... just wait until Plesk revise their policy that governs this etc. @Ales may add more to this in his reply too ;)
 
Yes, (we think) that's possibly been answered now?

No it's not. This issue goes deeper then just not being able to access Plesk user area over their own Lets Encrypt certificate. I mean this goes deeper then not being able to use https://www.domain1.com:8443 even though Lets Encrypt is PROPERLY installed and assigned.

Let me give you another example. In this version of my issue posted in this thread my clients can't use their Lets Encrypt SSL certificates, issued for their domains to secure their POP or IMAP servers in their subscriptions via SSL. They can use it for https://webmail.domain1.com that is working but not for secure email connection with email client. I just tried it's not working.

In other words my clients in their Outlook or any other email client can not use secure SSL via"mail.domain1.com" or "domain1.com" as their own incoming or outgoing servers. Even though Lets Encrypt is properly assigned (it's working at https://www.domain1.com). If they try to use "domain1.com" as being suggested here ( How to add a Plesk email account in Outlook ) each time they are getting Security error in Outlook about certificate not being valid.

To be able to use secure SSL in Outlook as described in their article for incoming and outgoing they must use my server hostname "static.111.111.111.111.clients.your-server.de" instead with their email username and passwords - if they don't want SSL warning. I just tried it and i am right. When using their domain it's not working when using my server hostname it's working.

That is not good thing to do. If Lets Encrypt is successfully released for their domain they should be able to use that same certificate for
a: to access their Plesk dashboard OVER their domain via https://www.domain1.com:8443/
b: to be able to use that same certificate for their own secure mail server connection via their own domain

I am still scratching my head how come no one at Plesk, not a single product designer think about that. Actually i am sure i am not right and that they have solution for that. This can be oversight because it's not that rare to have one IP hosting multiple domains. It's not first iteration of Plesk there must be some solution.

And now i am thinking even deeper and asking myself if i have 20 domains on single IP and they all need to use my server hostname instead of their domain to be able to connect via SSL with their email clients - how is my server counting emails and and managing email sending limits per hour if they are all using my server hostname to send emails instead of their own domains?!? The more i think about this the more i shake my head and believe i must be doing something wrong.

I mean... this can't be right..

Regards
 
Last edited:
That is not good thing to do. If Lets Encrypt is successfully released for their domain they should be able to use that same certificate for
a: to access their Plesk dashboard OVER their domain via https://www.domain1.com:8443/
b: to be able to use that same certificate for their own secure mail server connection via their own domain

Regarding b: This is not a limitation of Plesk but rather a limitation of Postfix. Postfix 3.4.0 with SNI support was only released a couple of weeks ago and it will take some time until your OS vendor (and Plesk) support this new Postfix version.
See also:
Resolved - I'm stuck in mail hell. How do I fix server verification issues?
Resolved - Certificate Outlook
 
... If Lets Encrypt is successfully released for their domain they should be able to use that same certificate for
a: to access their Plesk dashboard OVER their domain via https://www.domain1.com:8443/
b: to be able to use that same certificate for their own secure mail server connection via their own domain

I am still scratching my head how come no one at Plesk, not a single product designer think about that. Actually i am sure i am not right and that they have solution for that. This can be oversight because it's not that rare to have one IP hosting multiple domains. It's not first iteration of Plesk there must be some solution.

And now i am thinking even deeper and asking myself if i have 20 domains on single IP and they all need to use my server hostname instead of their domain to be able to connect via SSL with their email clients - how is my server counting emails and and managing email sending limits per hour if they are all using my server hostname to send emails instead of their own domains?!? The more i think about this the more i shake my head and believe i must be doing something wrong.

I mean... this can't be right..

Regards
Your expectations are completely understandable. Your assessment that most if not all of these issues are circumvented if using the hostname of the server to connect rather than the individual customer domains is also correct.

BTW, this approach doesn't interfere with the email sending limits, the limits will work regardless.

Basically, all I can really tell you is that we're in the same boat.

I do believe that Plesk product designers are aware of the problems, I'm just not sure how much importance are they assigning to them. These problems are completely solvable though, it's a matter of investing developers time and deciding whether something else is more important or not.

That being said:

- Plesk interface on the port 8443 could be secured with client's certificates, there are no technical obstacles
- IMAP when using Dovecot could be secured with client's certificates, the support has been available for quite some time
- IMAP when using Courier IMAP could be secured with client's certificates, apparently the support has been available for quite some time
- securing Postfix could apparently be achieved since recently
- securing Qmail is a bit more tricky but in the worst case, it could be achieved by using an intermediate such as stunnel. or ucspi-ssl.
 
No it's not
At the time we posted that reply, you hadn't mentioned the issue with e-mail ;)
This issue goes deeper then just not being able to access Plesk user area over their own Lets Encrypt certificate. I mean this goes deeper then not being able to use https://www.domain1.com:8443 even though Lets Encrypt is PROPERLY installed and assigned
With regard to e-mail issues, see the other posts made above, since you raised it and then...
In this version of my issue posted in this thread my clients can't use their Lets Encrypt SSL certificates, issued for their domains to secure their POP or IMAP servers in their subscriptions via SSL...
You can now possibly understand why we previously said "...this is actually used for mail related authentication / verification configs...". We can and we already do, what you are wanting to do, in your e-mail illustration, without any big issues, other than those provided by the current Postfix release as mentioned by @Monty Again this has been achieved, by using the previoulsy described workaround plus, all the required configuration & setup changes to mail etc that are needed. You'll have seen this is mentioned at the end in HERE (the old thread posted previoulsy). As a result, we do not have the security issues that you've mentioned when using mail via Plesk. The other challenge is... both Outlook and G-Mail are infamous for being over zealous with classing incoming mail as spam :rolleyes: and that feature applies to many e-mail setups besides those made when using Plesk o_O For further reference, THIS Plesk article give's you further insights into the mail issue you've mentioned
 
Guys...Monty, Ales and learning curve (haha what a great username) - thank you all. Really valuable info. I just read these articles you linked. Until this is resolved by Plesk itself i guess i'll have to deal it by myself (like you did)

I haven't realized Postfix was without SNI until recently. I just saw their changelog and yes you are right (Postfix stable release 3.4.0)

Until time being what can we do to at least support case A (customer should be able to login to plesk area over 8443 via their domain and lets encrypt certificate). Or even B?

Is there some "importance" chart for Plesk developers where we could add this, bump or upvote?

I just read some articles you linked here. Drinking early coffee and laughing by reading comments in these support articles but i guess people lost patience ( "Plesk is ONLY for hosting website without any emails boxes !")

Once again thanks...This is a good thread to learn (for me at least). Very friendly atmosphere here i really like it.

Regarding my case B do you guys have any less painful solution for changing or shortening (routing perhaps) my server hostname with case b in mind? So my customers don't have to to add something as "static.111.111.111.111.clients.your-server.de" but something shorter in their email client until Plesk solve this? It's not critical i am just asking. Or i simply convince them not to use SSL for email (haha)

As i understanding by reading responses from Plesk developers in support articles they are working on this but this will happen maybe in Q4 2019 but from my experience it will take at least until 2020.
 
Last edited:
Btw i am interested to hear your opinion about multidomain Lets Encrypt certificate. What do you think about this? Wouldn't that solve case B issue until Plesk deal with it.

So my theory is that when i am creating Let's Encrypt certificate at my Plesk - Tools and Settings, SSL/TLS for securing my mail server i simply list all domains upon certificate creation.

Then i assume that should work for email clients and customers using their own domains in email clients? I mean that's my idea i don't know would that work. On top of that when i initiate Lets Encrypt certificate creation from that area (Plesk - Tools and Settings, SSL/TLS) i can add only one domain. Is it possible to add more domains somehow, separated with some sign.
 
...what can we do to at least support case A (customer should be able to login to plesk area over 8443 via their domain and lets encrypt certificate)
The easiest current option for your case A (assuming you want to avoid making a lot of detailed setup changes for case A) is to accept that these customers can only login to their Plesk area via https://hostname.tld:8443. However, you could make this a little easier for them by using re-direct as per the extract, which is taken from a Plesk article that's posted below. This would mean the url that they would actually type (to gain access to Plesk) would be https://customer-hosted-domain:8443: which is probably a bit easier than your example of "https://static.111.111.111.111.clients.your-server.de:8443"

"...it's possible to redirect all *my.hosted-domain.com*:8443 connections to https://hostname.tld:8443 by following these steps:
- Connect to the server via SSH.
- Add the following rule in /etc/sw-cp-server/conf.d/plesk.conf:

Code:
set $test "0";
if ( $host = '$hostname' ) {
set $test "1";
}
if ( $test = "0" ) {
rewrite ^/(.*)$ https://$hostname:8443/$1 permanent;
}
- Restart sw-cp-server and sw-engine services:
Code:
# service sw-cp-server restart
# service sw-engine restart
Or even B?
We think the solution for your case A is also the easiest solution for your case B as well - currently anyway.
So my theory is that when i am creating Let's Encrypt certificate at my Plesk - Tools and Settings, SSL/TLS for securing my mail server i simply list all domains upon certificate creation...... ~
This won't work the way you want it to - currently. If it did, it would have been common knowledge sometime ago :)
...Is it possible to add more domains somehow, separated with some sign.
There's a complete thread HERE on the use of the Plesk Let's Encrypt Extension. It's a detailed long read, but by the very end of it, you'll see that sadly, it's not quite a simple as just adding domains "..separated with some sign" ;)

If you decide to go for the workaround that we have previoulsy described and that we use currently, there's quite a lot of work required to achieve it o_O Perhaps... therefore before taking this option, you should maybe consider asking Plesk Support (this is assuming that you already have a subscription account or if not - you would need to buy one) if they could / would advise you on the step by step process required, as you'll then have great, knowledgable technical suport as an instant back up too.
 
The easiest current option for your case A (assuming you want to avoid making a lot of detailed setup changes for case A) is to accept that these customers can only login to their Plesk area via https://hostname.tld:8443. However, you could make this a little easier for them by using re-direct as per the extract, which is taken from a Plesk article that's posted below. This would mean the url that they would actually type (to gain access to Plesk) would be https://customer-hosted-domain:8443: which is probably a bit easier than your example of "https://static.111.111.111.111.clients.your-server.de:8443"

"...it's possible to redirect all *my.hosted-domain.com*:8443 connections to https://hostname.tld:8443 by following these steps:
- Connect to the server via SSH.
- Add the following rule in /etc/sw-cp-server/conf.d/plesk.conf:

Code:
set $test "0";
if ( $host = '$hostname' ) {
set $test "1";
}
if ( $test = "0" ) {
rewrite ^/(.*)$ https://$hostname:8443/$1 permanent;
}
- Restart sw-cp-server and sw-engine services:
Code:
# service sw-cp-server restart
# service sw-engine restart
We think the solution for your case A is also the easiest solution for your case B as well - currently anyway.
This won't work the way you want it to - currently. If it did, it would have been common knowledge sometime ago :)
There's a complete thread HERE on the use of the Plesk Let's Encrypt Extension. It's a detailed long read, but by the very end of it, you'll see that sadly, it's not quite a simple as just adding domains "..separated with some sign" ;)

If you decide to go for the workaround that we have previoulsy described and that we use currently, there's quite a lot of work required to achieve it o_O Perhaps... therefore before taking this option, you should maybe consider asking Plesk Support (this is assuming that you already have a subscription account or if not - you would need to buy one) if they could / would advise you on the step by step process required, as you'll then have great, knowledgable technical suport as an instant back up too.

Thanks for your valuable input. Greatly appreciated. I am going to stay away from deep digging solutions (solutions you posted initially above). Not because i wouldn't know how to do it (i can easily restore complete server snapshot if i mess something on the server) but because from my experience such solutions need constant monitoring and i am alone so i probably can't provide needed treatment - and perhaps they could collide in the future when Plesk solve this within Plesk itself (hopefully i make sense my english is bad).

But i will definitely use your re-direct trick. That doesn't seem to be bad at all.

Thank you learning curve. That some learning curve for me :) (i really wish i could name you differently you are so great).

Thank you everyone else.

Regards

(i will mark this thread as being solved even though we actually wait for Plesk to do it)
 
Back
Top