@Daka,
You stated:
yes, the Hoster has got a valid Comodo Certificate!!! But its only for HIS Domain. If i want to use my Domain it wont work.
Well, this is a "problem" that is known: if you only have a reseller account, you are using the setup as configured by the hosting provider, with all associated disadvantages.
In your case, the particular disadvantage is that you cannot simply change the hostname (set by the provider) and/or simply add some custom domain with a valid SSL certificate in Plesk (after all, when pointing DNS records to this custom domain, traffic is routed to the custom domain as created in Plesk and not routed to the Plesk panel interface itself).
First note that
- you actually need the 8443 port in the URL for accessing Plesk panel, at least in the current default Plesk configuration
- you can easily implement a custom URL for the Plesk panel, if (and only if) you have SSH access (in order to change configuration files)
and the problem is that your hosting provider is not very likely to adjust it´s Plesk configuration in order to allow you a custom URL for your Plesk panel.
As a result, we have to rely on a more elaborate solution.
Now you have to note that Plesk panel is relying on some Nginx directives for URL redirection to the https address of the panel: we can "build" on that setup AND we have to take care at the same time that before mentioned default Plesk directives are not interfering with our solution (otherwise, some requests would end up on the hostname URL for the Plesk panel).
The most "convenient" work-around is the following, at least in theory (I did not test it completely, but it should work).
a) get or use a (custom) domain that you own and
- create an A record pointing to the IP assigned to your server,
- create a wildcard A record (i.e. *.<domain>.<tld>) pointing to the IP assigned to your server,
and note that this is the FIRST part of the solution: any https request with some name and a port extension 8443 can be typed into the browser and you are at your Plesk panel.
For instance,
https://<custome name>:8443 will result in the login pages for the Plesk panel interface on your server.
Now we can address the SECOND part of the solution: to assure that ALL requests are served via https without losing the custom name.
b) go to Plesk Panel and
- create hosting for the (custom) domain
- create an empty directory (for the sake of convenience, I will use "panel" henceforth)
- go to the (custom) domain and go to "Apache & nginx Settings"
- enter in the "Additional nginx directives" textbox:
location = /panel {
return 301
https://<name>:8443;
}
and note that the value for <name> can be anything of the form <subdomain>.<custom domain>.<tld> or <custom domain>.<tld>, as long as proper A records do exist.
For instance, panel.domain.tld is possible, as well as domain.tld (the latter is not adviceable).
Also note that I did have to create an empty directory, in this case called "panel", with this empty directory being necessary to allow Nginx to override the Nginx settings and directives, as provided by default for the Plesk panel interface.
Plesk uses the following directive by default for the Plesk panel: error_page 497
https://$hostname:$server_port$request_uri;
This directive should be magical, according to Plesk, but in the real world, this directive becomes a problem, since there is no way of overriding the default directives if one does not have SSH access or sysadmin rights to change configuration files (and, moreover, manually editing config files is not really adviceable).
In essence, my directive does the same and a little bit more, when compared to the default Plesk directive: just rerouting all traffic for the panel to a standard https port.
Finally note that this is the SECOND part of the solution.
There should be some good news by now: if I am not mistaken, you do not get any SSL related errors at this stage, since the SSL certificate of the hosting provider should be used.
However, you still have the minor issue that you do not apply or implement valid SSL certificates for your (custom) domain (even though the SSL certificates actually used are valid).
Well, let´s proceed to the third an final part of the solution.
c) in order to use your own valid SSL certificates (as opposed to using the certificates from the hosting provider), you should simply
- buy them, if necessary
- upload them to (i.e. apply them in) the (custom) domain.
To be honest, this is the part that I did not test.
However, it should be the case that there is a tiny chance that it works: instead of using an error_page directive (i.e. returning pages from a https request with $hostname), the return directive (i.e. returning pages from a https request with the correct domain name) has been used within the domain itself.
I am not pretty sure, but it could work.
On the other hand, I personally should not bother to buy SSL certificates, if the certificates of the hosting provider remove all error notifications concerning these certificates.
In summary, I sincerely hope the above helps, but I would even more appreciate feedback from you, especially with respect to section c).
Regards and let me know!
PS To respond to your last post: you can use any kind of certificate, but at this moment letsencrypt is not the best choice: it is still in (public) beta.
Facebook
Twitter
