• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question Domains with port 8443 login ssl

Jmz

New Pleskian
Moin,

i would like to encrypt not only the domain for the plesk server host.de:8443, but i would also like to have access to all domains to the customers, for example: customer1.com:8443 or customer2.com:8443, that they should not log in under host.de:8443.

how can I set this?

thx
 
To get a free SSL/TLS certificate from Let's Encrypt:
  1. Go to Websites & Domains > Let's Encrypt.
  2. Specify the email address that will be used for urgent notices and lost key recovery. By default, the email address of the subscription owner is used.
  3. Specify if you want to include an alternative domain name for the domain and each selected alias, for example: www.example.com for example.com. We recommend that you select this checkbox.
  4. Specify if you want to include webmail, for example: webmail.example.com.
  5. If there are domain aliases, select the ones that you want to include in the certificate.
  6. Click Install to get and install the Let's Encrypt certificate for the subscription.
 
Yes, it is possible, just secure the domain with let's encrypt to get https://example.com:8443

I may be wrong, but to the best of my knowledge, this is NOT possible.
Yes you can secure all the domains with lets encrypt, however if you attempt to connect for any domain on port 8443 (the plesk server login), it will show an error / a warning as the security certificate is for plesks host server alone.
To allow https://customer1.com:8443 to work properly, the servers certificate would have to include all customer domains as aliases on the cert. Which I don't think is possible right now.

I'd be happy to be proven wrong. :)

Cheers, Tom
 
I may be wrong, but to the best of my knowledge, this is NOT possible....
It is possible. We use a *Wildcard Let's Encrypt Certificate for the host, but it also covers ALL of our hosted domains too.

Host - *Wildcard Let's Encrypt Certificate - This covers: Host / Plesk (Host:8443) / Mail Server / WWW / Webmail / All Host Sub-Domains PLUS All Named Domains / All Named Domains' Sub-Domains etc. This ALSO covers all Named Domains:8443 :) You can both see and test this very easily with Mozilla and/or any other tests you like. The *Wildcard Let's Encrypt Certificate we created HERE outside of Plesk, so it is not an automatic renewal process, it needs to be manually renewed etc.

Domains - Let's Encrypt Certificates - In each case, this covers: Domain / WWW / Webmail etc but not Domain:8443 which is covered by the above. All these normal Let's Encrypt Certificates are created within Plesk via the Plesk Let's Encrypt Extension and they all renew automatically.

The *Wildcard Let's Encrypt Certificate for the host requires a bit of extra work. You need to validate all the entries (domains) on it via two separate DNS entries for each before you create the certificate itself. If you want to (not sure why you would...) you could also omit the WWW too on any domain. The Plesk Let's Encrypt Extension will also create *Wildcard Let's Encrypt Certificates now (we've tried it) but it is still being improved. At the moment, for us anyway, the external option is still quicker and easier to use when creating *Wildcard Let's Encrypt Certificates.

Test it yourself @TomBoB You can delete / re-issue any certificates (with either the Extension or external) if you get them wrong
 
Hi lerning_curve,

Thanks for the detailed explanation! Something new every day :)
And possibly a good solution for @Jmz who's asking for it.

Had a quick look into it, but unfortunately wouldn't work for us. Having ~150 domains hosted per server, we'd hit the 100 hostname per certificate limit of lets encrypt, even when using wildcard ones; not to mention the work invoilved creating those the way you discribed.
We'll stick to have our clients log into server3.theservershostname.com:8443 :)

Thanks again ! :)

Tom
 
...And possibly a good solution for @Jmz who's asking for it...
Yes if it can help them, that's great.

We're less that 100 domains per IP address, but even if we weren't, you're right about the amount of work involved v time taken, when doing it this way, because it does need a lot of patience once you're above 50 or so domains o_O:D
 
Assuming you control DNS for all the domains :rolleyes:

Seems like a headache to me. What's the purpose?
 
Assuming you control DNS for all the domains :rolleyes:
In our case, yes we do. Host and all domains use external DNS which is easy to configure
Seems like a headache to me
If.. you have zillions of domains, yes, as we have said already, but otherwise, no, just a lot of patience required that's all.
What's the purpose?

We never need to login to Domain:8443 anyway, but... we can if we want to, without any certificate problems :D Host:8443 gives access to all domains and works perfectly, which is why we don't bother. The reason that @Jmz wants to do this? You would need to ask him why i.e. what he wants to do, once he achieves this.

The purpose for us, FWIW is different. It's to do with accuracy of domain mail / host verification. Securing the host with a *WLE Certifcate that includes all the hosted domains/subdomains, means that this becomes much easier. As far as we're aware, Plesk don't have their own solution for this (other than the obvious multiple IP's) meaning, there will always be a mis-match involved and reported (somewhere) if... domains are using their own mailservers, which are handled by the host / host IP. As you know better than us, you can use many, different, but all very accurate online tests e.g. Secure Email for verification checks etc. All of these will provide results showing any issues like this, very quickly
 
Last edited:
Back
Top