Question Letsencrypt, webmail en Pleks panel

[mr-wolf]

Now Plesk makes it so easy for us to get Letsencrypt for our customer's website, we would also like that for out webmail and the Plesk panel.

These certificates don't work for other subdomains, but they would work for an URL

For the Plesk-panel I now made a solution by automatically creating a cname within our own domain for each client. On the Plesk panel I have a wildcard-certificate and that way all these cnames are valid.
If for some reason that client switches to another server of ours, they don't need to be notified as that cname always points to the A-record of that domain.

But it could be done more elegant even.
If nginx would be configured in a way that the URL /psa for each secure website would point to https://127.0.0.1:8443 then they would have their plesk panel using their own domainname in https

The same could be done for webmail with the URL /webmail
This would have to point to http://127.0.0.1:7080
The URL needs to be stripped and the subdomain changed, so https://domain.com/webmail becomes http://webmail.domain.com/ pointed to 127.0.0.1:7080

I think I could write this by harvesting the files in /etc/nginx/plesk.conf.d/webmails and /etc/nginx/plesk.conf.d/vhosts and creating an extra configs in /etc/nginx/urls.d which I include with a file in /etc/nginx/conf.d/zz090_url.conf

I could write a proof of concept....

I would prefer a solution from Plesk of course.....

 

[UFHH01]

Hi mr-wolf,

there will be soon a new, improved Plesk Let's Encrypt version, as announced by Plesk-Team-Members for Plesk Onyx, which is now stable. Consider to upgrade to Plesk Onyx and wait a few days and you will see that Plesk and the developpers don't sleep.

If you still desire to suggest features for Plesk, pls. consider to request them at: => http://plesk.uservoice.com/

 

[mr-wolf]

I can of course wait....
Am a bit exhausted as well for getting that autodiscovery in combination with automatic DNS-records ready.

Are they using URL's or are they ordering extra LetsEncrypt subdomains???

BTW... I'm already on Onyx with most of my servers.

 

[UFHH01]

Hi mr-wolf,

BTW... I'm already on Onyx with most of my servers.

May I ask, why do you write if the Plesk 12.5 - Forum then? ^^

Are they using URL's or are they ordering extra LetsEncrypt subdomains???

Sorry, I don't understand your question here.... could you ask the question with more details to which situation? And who are "they" ?

 

[mr-wolf]

Hi mr-wolf,


May I ask, why do you write if the Plesk 12.5 - Forum then? ^^

Honest mistake...
I should have posted in Onyx thread.
Sorry

Sorry, I don't understand your question here.... could you ask the question with more details to which situation? And who are "they" ?

With "They", I mean the Plesk team.
They are in fact taking care of the certificates with Letsencrypt.

The difference with an URL as opposed to a subdomain is that one needs another or a more wider certificate for a subdomain.
So https://domain.com/webmail can work with the same certificate as that of domain.com, but https://webmail.domain.com would need another certificate than what they are using now.

Because you appear to be better informed I wanted to ask you how they are doing it for webmail. (a URL in normal domain, a subdomain webmail with certificates that have an extra CN or with a seperate certificate?

 

[UFHH01]

Hi mr-wolf,

I'm pretty sure, that the feature to use subdomains for "webmail" and the "hostname" for your Plesk Control Panel will not change, as it is a long-term standart now. There is nothing wrong with it, using this method, even if that means, that you have to click a few more times, because you will have different certifcates for different subdomains. But (!!! - and here comes the clue ), the Plesk - developers could even choose to use the "-expand" - command for the Let's Encrypt certbot, which offers the possibilty to expand a previous installed certificate with several other (sub)domain - names. You still have to WAIT to get some decent answers here, because I'm not a Plesk developer and therefore can only guess, how they are going to improve the extension.

Because you appear to be better informed...

I just may just READ more posts and threads here in the forum, mr-wolf, just because I'm very interested in Plesk and it's components and often enough, I use as well the SEARCH option from the forum, to inform myself.

 

[mr-wolf]

Hi mr-wolf,

I'm pretty sure, that the feature to use subdomains for "webmail" and the "hostname" for your Plesk Control Panel will not change, as it is a long-term standart now.

I only know of a standard for webmail.
Access to the plesk panel thus far for me would be "https://clientdomain.com:8443" and ignore the certificate error.
That's ugly, but the alternative "https://server3.provider.com:8443" in combination with a wildcard certificate has another downside.
If I choose to change the clientdomain.com to another server of ours (moved from server3.provider.com to server8.provider.com), they would be going to the old server instead of the new one.
I would have to tell them to access https://server8.provider.com:8443 instead of https://server3.domain.com:8443. I don't want that.

To escape this I've written a cronjob that will create cnames for all the domains I'm hosting.

As an example:

The provider's domain name is: provider.com
On the Pleks interface there's a wildcard certificate: *.provider.com
The client's name is: client.com

The scipt will create the cname: client-com.provider.com and points that to client.com

The Plesk interface can now be accessed by using https://client-com.provider.com:8443 without getting a certificate error and with a guarantee that it will continue to work after if has moved from server3.provider.com to server8.provider.com

Another idea would be using https://client.com/psa for all certificate enabled sites and redirect that to https://127.0.0.1:8443 using nginx
Because the latter would be more elegant than the one creating a cname in my provider.com zone I'm still in doubt to communicate the first one to my users.

It IS working though.
I can already use https://client-com.provider.com:8443 for all my clients to access the panel without a certificate error. It is however dependent of the hourly cronjob that will write all the cnames for me. It is good enough for me, but if the URL-method has a chance to be implemented in an elegant way, I would prefer that.

The URL rewrite would need to be incorporated in the apache configs. Something I don't want to touch (yet). I believe there's a way to customize it in an elegant way, but I didn't examine it.
I could also have a cronjob to patch all new nginx configs that are created in /etc/nginx/plesk.conf.d/vhosts/
I could add a new location entry to rewrite /psa and redirect it to https://127.0.0.1:8443 with its url /psa stripped.

All in all I would prefer a standard for Plesk access coming from Plesk themselves.

There is no standard for Plesk access yet, is there?