• 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.

Forwarded to devs SSL It! breaks renewal and usage of Let's Encrypt wildcard certificates when subdomains are involved

We can confirm, that the problem also still exists same as mentioned in our bug report.

E.g. one client wildcard certificate, that is not renewed since some days (4th of March):

ck.png
 
We see the problem now for the first time also for a domain, that has no subdomains but one extra domain in the subscription, that is forwarded to it. The wildcard certificate is not renewed and ends up in a freezing state as described in the bug report ("continue" and "cancel" buttons).
 
@Peter Debik At the moment we only have reseller licenses. So we cannot open support tickets as mentioned before. And our reseller does also not accept support requests. Maybe we will switch one affected server to a license directly from Plesk so we can open support tickets directly. But as the problem exists on all of our servers Plesk should be easily able to trace the issue.
 
@Peter Debik At the moment we only have reseller licenses. So we cannot open support tickets as mentioned before. And our reseller does also not accept support requests. Maybe we will switch one affected server to a license directly from Plesk so we can open support tickets directly. But as the problem exists on all of our servers Plesk should be easily able to trace the issue.

Just in case you aren't aware, you don't need a full server license bought from Plesk to actually get support from Plesk. On a reseller license a support subscription (priced at 10 €) suffices. Which, depending on what your reseller charges for your Plesk license, can be a cheaper option than a full license bought from Plesk. (Also, spending 10 € to get an issue, one that you have to deal with on a daily basis, resolved faster would be a no-brainer for me.)
 
As there seems to be no progress at all by Plesk for the bugs EXTSSLIT-1879 and PPS-15436 we decided to implement our own work-around.
To share wildcard certificates among subdomains is buggy with heavy impact on our client's satisfaction.

To avoid this shameful bug of a so called "server management platform built with you in mind." the only way is to take the renewal process in your own hands. Just scan your sites and certificates with an appropriate script and renew the wildcard certificates 5 days before Plesk would do it on its own.

Not only our clients are speechless, when we have to tell them: "Sorry, but our server management platform is not able to renew your website certificates appropriately. The bug is know since 6 months, but Plesk has no technicians or time or mood to take care this issue."
 
As described previously in this bug report, we also encounter the problem, that sometimes the "SSL/TLS certificate for mail" is removed from the domain leading to warnings in the mail clients of our customers. This happens very seldom, but it occurs. The affected wildcard certificates are still in use for webmail but not for the mail server anymore.

As we do not know, what "shortly" means for this bug report, we did implement an own check routine for exactly that problem. Anyone facing the same issue can use the following SQL statement, to determine possible domains, that maybe suffer from this bug:

SQL:
SELECT
   `certificates`.`id` AS `certificate_id`,
   `certificates`.`name` AS `certificate_name`,
   `dom_param`.`dom_id` AS `domain_id`,
   `dom_param`.`val` AS `webmail_certificate_id`,
   `Parameters`.`value` AS `mail_certificate_id`
FROM
   `certificates`
   STRAIGHT_JOIN `dom_param` ON
      `dom_param`.`param` = "webmail_certificate_id" AND       
      `dom_param`.`val` = `certificates`.`id`
   LEFT JOIN `Parameters` ON
      `Parameters`.`parameter` = "mail_certificate_id" AND
      `Parameters`.`value` = `certificates`.`id`
WHERE
   `Parameters`.`value` IS NULL
 
I just opened a ticket with Plesk Support because I am experiencing this as well on all my servers. I use Let's Encrypt Wildcard certificates for all of my domains too.
 
We have taken the EXTSSLIT-1879 bug into work; unfortunately, we can't reproduce the issue with 100% confidence.

In our test environment, we can reproduce the blank confirmation issue very-very-very rarely. At the same time, all the necessary text appears on the confirmation screen after a second just after the page reloads. Also, we do not observe actual results with different certificates on the domain and subdomain. Likely, we have found another issue, but all these mean we still have an issue with reproducing the bug on our side.

Anyway, we would like to find and fix the root cause that happens more often (based on the number of reports in this thread, Facebook, via Plesk Support); or to confirm that there is only one bug and it was already found.

So we are looking for people who are experiencing this issue on their servers right now (the black confirmation banner is shown, not disappearing automatically in a minute; where different certificates are created instead of one wildcard certificate), to invite them to contact Plesk Support. Even if you do not have direct support from Plesk, let me know and I will create a ticket behalf you (I just need to know your email address, you can send it to me directly through the forum). The ticket will be passed to an engineer/developer on duty to investigate the root cause on your server (where the SSL It! has failed to reissue a certificate correctly).

If you can demonstrate/reproduce the issue on your server quickly, without the necessary wait for 60 days, let me also know, and I will help you contact Plesk Support as well.
 
I encounter this issue when the top-level domain uses a wildcard certificate, and that certificate is also applied to a forwarding subdomain.
 
The new SSL It! version has been released, it also contains a fix for EXTSSLIT-1879. It may take several hours for the update to become available through the Extension Catalog. Let us know if you have any feedback.

1.15.0 (11 June 2024)​

  • [+] Added the extension's information block to the new Home screen in Plesk.
  • [-] The "empty" pending order is now deleted as intended after renewal of a domain certificate. (EXTSSLIT-1879)
 
We did install the latest version on one of our smaller servers that is affected by this bug (only 8 domains hosted in total on that server). At the moment we still see the bug for one combination of domain + subdomain using the same SSL certificate (certificate will expire in 18 days and is in "orange" warning state for the main domain + subdomain). We will now wait for 24 hours if the certificate gets renewed correctly. On another server with 200+ domains we did stop our auto-renewal workaround script to see if certificates get renewed correctly now. Results will be visible in approximately 1 week. Thanks for the patch!
 
The affected certificate of domain + subdomain was not renewed and shows still the known buggy behavior:


Screenshot 2024-06-13 130343.png

Screenshot 2024-06-13 130436.png

Does the new version take care already "broken" renewal processes?
 
We did it but it has no effect. Looks like the bugfix does not work for our case. We did click now "Cancel". Let's wait another 24 hours if at least the certificate gets renewed.
 
We did it but it has no effect. Looks like the bugfix does not work for our case. We did click now "Cancel". Let's wait another 24 hours if at least the certificate gets renewed.
I'm afraid that it won't help in this case. Could you please contact with our support team? We need to understand your case and why these "empty" orders aren't disappeared after running of "keep-secured" task.
 
I'm afraid that it won't help in this case. Could you please contact with our support team? We need to understand your case and why these "empty" orders aren't disappeared after running of "keep-secured" task.

@Hangover2 if you are open to an investigation by our engineers on your server you can sent me or @AYamshanov your email address in a private message and we'll open a ticket on your behalf.
 
Back
Top