• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • 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.

Issue Is it possible to set the Plesk default certificate as a Let's Encrypt wildcard cert which can also be used to preview URLs?

bbeckford

New Pleskian
I can add a wildcard cert to a domain, but how do I get it to show up in the "Server Pool" under Tools & Settings > SSL/TLS Certificates?

I've looked through the psa database and file structure and I can't seem to figure out what makes a certificate part of the "Server Pool" vs belonging to a domain.

If I managed to get it to show up there could I set it as the default cert and therefore automatically make all my preview URLs secure?

This would make preview URLs REALLY useful for my workflow.

Thanks!
 
I can add a wildcard cert to a domain, but how do I get it to show up in the "Server Pool" under Tools & Settings > SSL/TLS Certificates?
I've looked through the psa database and file structure and I can't seem to figure out what makes a certificate part of the "Server Pool" vs belonging to a domain.
If I managed to get it to show up there could I set it as the default cert and therefore automatically make all my preview URLs secure?
This would make preview URLs REALLY useful for my workflow.
Thanks!
AFAIK - The "Preview" option uses a url that utilises your server IP address. i.e. something that there is (normally) no SSL Certificate for... It is NOT the domain url address. Have a look at the actual Plesk preview url and/or say the Firefox advance section when you get the insecure notice for more detail. Depending on the access levels that you're providing e.g. IF it's NOT actually a site under construction / no public access etc Could you not just use use the "Open in web" option instead?
 
I have modified the preview domain to include the hostname of a given server, ie where my hostname is server001.mydomain.com, the preview URL is: https://testdomain.com.123-456-789-123.preview.server001.mydomain.com (where I have a DNS A record for *.server001.mydomain.com that points to my server's public IP)

So then adding a website to Plesk that's just server001.mydomain.com and securing that with a wildcard certificate, would mean that that certificate should function perfectly well to secure any preview URL on that server.

When it is a site under construction our current workflow is this:
  1. Create a new website in Plesk, include the hostname as a suffix, so for eg: myclientsnewwebsite.com.server001.mydomain.com
  2. Run Let's Encrypt on that domain
  3. Create a new config in developer's local SFTP config that points to /var/www/vhosts/myclientsnewwebsite.com.server001.mydomain.com/httpdocs/
  4. Build and test the website
  5. When ready to launch, remove the hostname suffix server001.mydomain.com from the domain
  6. Let's Encrypt the new domain
  7. Alter config in developer's local SFTP config so it now points to /var/www/vhosts/myclientsnewwebsite.com/httpdocs/
With Plesk Preview URLs it could be as simple as:
  1. Create a new website in Plesk, eg: myclientsnewwebsite.com
  2. Develop the website using the preview URL (automatically secured by wildcard LE cert)
  3. Create a new config in developer's local SFTP config that points to /var/www/vhosts/myclientsnewwebsite.com/httpdocs/
  4. Build and test the website
  5. When ready to launch and DNS is mapped, Let's Encrypt the new domain
I just see SO much potential in preview URLs and it's such a shame that it falls down when it comes to wildcards!
 
@bbeckford Can't fault the intention, but honestly, have no idea if the current demand for that functionality is sufficient for Plesk to develop / extend it. Plesk do have a process where suggestions are documented online / receive sufficient votes / become a function etc as you're no doubt already aware. That might be a possible route for you to follow?

Just as a random suggestion as a possible alternative, whilst waiting for the above to happen, you could, temporarily modify your workflow as follows:

With a site under construction, your workflow could be as simple as; (major steps only listed here, more small detail required but the concept is absolutely fine)
  1. Create a new website in Plesk, eg: myclientsnewwebsite.com, Map DNS and Let's Encrypt the new domain
  2. Create a new config in developer's local SFTP config that points to /var/www/vhosts/myclientsnewwebsite.com/httpdocs/
  3. Develop the website, but, only whilst using re-directs, with all of YOUR OWN IP addresses listed as exceptions.
  4. #Re-Direct - This example is a setup for Apache2 that we've successfully used in the past with no problems or issues;
    Options +FollowSymlinks
    RewriteCond %{REMOTE_ADDR} !^**\.***\.**\.***$
    RewriteCond %{REMOTE_ADDR} !^***\.***\.***\.***$
    RewriteCond expr "! %{REMOTE_ADDR} -ipmatch '****:****:****:****::/64'"
    RewriteCond expr "! %{REMOTE_ADDR} -ipmatch '****:****:****:****::/64'"
    RewriteRule ^(.*)$ https://yourholdingpage / otherwebsite [R=301,L]
  5. For reference; You can provide the same re-direct functions in Nginx, if you're not using .htaccess and/or Apache2 at all
  6. Build and test the website
  7. When ready to launch, remove the #Re-Direct and go...
If you've followed the correct setups, your SSH, SFTP, DNS, Let's Encrypt etc etc will all work exactly as intended & meantime, you're still in total control of any access to myclientsnewwebsite.com until it's launched / handed over to your client etc
 
Thanks for the reply @learning_curve, that makes sense but only for brand new websites - if there's already a site on that domain we can't remap the DNS / overwrite it if it already resides on this server.

We have suggested it on their suggestion site but as you say, it has to get significant upvotes and even if it does that doesn't help me right now.

I guess what I'm after is info on whether there is some hacky way to do it, ie get the wildcard LE cert to show up in the "Server Pool" so I can set it as the default for preview URLs. Feels like it should be simple but I can't find any info on what makes a cert part of the "Server Pool" vs just being attached to a domain.
 
...if there's already a site on that domain we can't remap the DNS / overwrite it if it already resides on this server
To try and understand this ^^ properly, did you mean; if site A is live, but it will be replaced by Site B (once it's tested and complete), the isssue, is that you want them to both use the same URL / domain at the same time? Thus the issue with public access etc? If so, yes, that's more complicated as you've mentioned, although temporary use of a sub-domain and/or temporary use of another domain, could solve that issue if you're very fastidious with all of the setup work
We have suggested it on their suggestion site but as you say, it has to get significant upvotes and even if it does that doesn't help me right now.
Yep, unfortunately it's usually not a fast process once it's accepted, either...
I guess what I'm after is info on whether there is some hacky way to do it, ie get the wildcard LE cert to show up in the "Server Pool" so I can set it as the default for preview URLs. Feels like it should be simple but I can't find any info on what makes a cert part of the "Server Pool" vs just being attached to a domain
We have a Multi-Domain / All Wildcard / Let's Encrypt SSL that covers the Plesk hosting domain and several others too. We create that and renew it using a Non-Plesk application i.e. THIS (acme.sh) which is excellent. The resultant certificate (effectively a SAN) appears in the server pool as expected. What we don't do though, is modify the "Preview" URL (like you do) meaning that it's always the default IP address URL (with a suffix) that's generated by Plesk, which :D is why, we don't use Preview! However, it's not a hacky way :D or secret process to generate that certificate and/or store it in the server pool, but, that's assuming... that the domain you are using to host Plesk is the same domain that you are trying to issue the certificate for and thus have it visible in the server pool. What is the specific issue, that you encountered that's stopped you from doing just that, as that bit is not clear so far?
 
I guess what I'm after is info on whether there is some hacky way to do it, ie get the wildcard LE cert to show up in the "Server Pool" so I can set it as the default for preview URLs. Feels like it should be simple but I can't find any info on what makes a cert part of the "Server Pool" vs just being attached to a domain.
This is something that will never work anyway, as a wildcard ssl certificate does only cover one level of subdomains.

So let's say you have a wildcard cert *.mydomain.com, then this this will be valid for something like aaa.mydomain.com or bbb.mydomain.com, but not ccc.aaa.mydomain.com
 
Hello,

I agree with Christoph, but a solution would be that Plesk change the preview url by replacing the dots in the domain name by a "-".
This way you would have for example https://test-fr.<ip>.domain.com and a wild card on *.<ip>.domain.com would work.
 
Back
Top