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

Let's Encrypt extension

Hi,
I've got a question concerning the setting "send-notifications-interval" in panel.ini.
The documentation (https://docs.plesk.com/en-US/onyx/administrator-guide/plesk-administration/managing-let’s-encrypt-settings.78586/) says the default value is "1 day", however it's not very clear on the formating of the value. The result I want to achieve is, that the mail is sent once a week.
How do I have to write it into the file?

send-notifications-interval = 7 day
send-notifications-interval = 7 days
send-notifications-interval = "7 day"
send-notifications-interval = "7 days"
Or without space?
 
You mean the notification mail interval. For the renew period you have to set only the naked number without anything in panel editor.
Don't know, but usually it should be same for all other time specifications.
 
The thing is, that in the documentation, the column for default value explicitly contains the string "1 day" and not just a number.
I tried setting a single number, but it looks like this is invalid, or equivalent to the (mentioned) value 0, which sends a message every time.
 
Let's encrypt is very new and it was made to shake up the status quo.

As for making certs yourself, that kinda defeats the purpose. Certs create a chain of trust. If a big authority trusts you, and your clients trust the big authority, then your clients can trust you by extension. Look up how PKI schemes work. 9Apps VidMate 9Appsapk

Let's encrypt keeps things pretty simple and just makes sure that you actually own the site you're getting a cert for. This is to prevent people from generating fake certificates for MITM attacks. Some major authorities are worth paying for because they go a step further, and can actually verify that you are a legit business.
 
Last edited:
Does anyone know whether meanwhile it is possible to hide the "wildcard" certificate option from customers? Our customers keep checking the box and create support requests for DNS settings, but we don't want to offer wildcard support. We'd like to reduce the number of support requests where customers run into the DNS update request after they attempt to create a wildcard certificate. Instead they shall only see the normal certificate options for non-wildcard certificates.
 
Hello,
Does anyone know how to create an LE certificate using the plesk API for a domain?
Unfortunately, I did not find a suitable method in the documentation.
I want to install LE SSL for all domains, but it will be too slow via the web interface.
 
@Extor Out of interest, using the Plesk LE Extension via the Plesk Panel (which is what we assume you mean when you say "...via the web interface" ) does work well for us and isn't slow when using it on many domains.

However, an alternative that is not "...using the Plesk Api" but can be used via CLI (and is free) so you might like it :D is this: ACME SH

Acme SH will produce (almost) anything you want with regard to LE Certificates. We regularly use it where we can't use the Plesk LE Extension (yet) e.g. For a Multi-Domain | Multi-Wildcard LE SSL Certificate.
 
BTW, we have a system, where the directory /var/www/vhosts/default/htdocs/.well-known/acme-challenge contains several thousand files.
Doesn't the extension clean up it's files after a successful validation?
 
I can confirm this, I just checked some of our Plesk instances and there is a lot of leftover challenge files. A lot!

Looks like a bug.
 
Thank you for bringing this up. I checked on our systems and see the directory filled will well over 100,000 files. I'll file a short report an direct to this thread.
 
Having read the last few posts re: thousand of old files in /var/www/vhosts/default/htdocs/.well-known/acme-challenge obviously, we then checked our own ;)

We have exactly the same number of files (c/w recent dates), as the number of SSL certified domains that we currenty host, no more. That seems very different than the last few posts, all of which have far greater numbers of files...

So, assuming that there is indeed a bug (for others), is it a bug that's specific to certain OS and/or Plesk versions and/or is it a bug that's only related to the Plesk SSLit Extension, which we don't use?
 
BTW, we have a system, where the directory /var/www/vhosts/default/htdocs/.well-known/acme-challenge contains several thousand files.
Doesn't the extension clean up it's files after a successful validation?

This bug is also on Plesk Obsidian 18.17
 
Hey,

I recently upgraded to Plesk Obsidian (Ubuntu 18.04) and configured the new SNI feature for my domains (How to secure a Plesk mail server with different SSL certificates (SNI support)).

I now noticed that the Let's Encrypt certificate was no longer valid and expired. Apparently the renewed certificate was not used for the mail server.
Only when you go to the mail server settings and hit apply the renewed certificate is used.

To check this I manually renewed the certificate and verified the expire date of the mail server certificate, which was the date of the "old" certificate.

Did you already noticed that behavior? Is it possible to automatically refresh the mail server certificate after a renewal?
 
Last edited:
Yesterday Let’s Encrypt announced that today, March 4, they will revoke 3mln certificates.

See details here: Revoking certain certificates on March 4

In short: there was a bug in Let’s Encrypt service. If a certificate is affected by that bug, it will be revoked by Let’s Encrypt; it means that site visitors will receive security error. The revoking process will start today, March 4, at 20:00 UTC. So, according to that post, users have to check and renew the affected certificates manually.

Let’s Encrypt have sent an email notification for the owners of the affected certificates, but if there are a lot of domains, manual checking and manual renewal don’t look convenient and effective :)

Also, the email notification can be easily missed.

That’s why we’ve released an urgent update for the SSL It! extension: SSL It! - Plesk Extensions

The update should solve the issue automatically (actually, semi-automatically, see details below).

How it works:
  1. SSL It! already has autorenewal task which runs every hour by default
  2. this task goes through the domains and check the expiration date of the certificate, and, if it’s required, autorenew the certificate
  3. we’ve added an additional check for the domain using the LE service: Check whether a host's certificate needs replacement , so, if the certificate affected, SSL It! runs the autorenew procedure.
  4. if the certificate isn’t affected, SSL It! remembers that and don’t check it next time
Nuances:
  1. most of the affected certificates are wildcard certificates. It means if DNS isn’t powered by Plesk, a customer has to manually add (update in this case) the required info into the domain’s DNS zone. If DNS is powered by Plesk, the renewal should pass automatically.
  2. We don’t fix the Panel certificate. It should be renewed manually.
If smth goes wrong, it’s possible to turn off this functionality, see the changelog below.

The changelog:
Let's Encrypt has found a bug and revokes some of its SSL/TLS certificates on March 4. This improvement solves the issue. The SSL IT! extension will check domains as a part of the "Autorenew" feature, then will renew and replace affected Let's Encrypt certificates. Future autorenew tasks will be done as usual when SSL/TLS certificates are about to expire.

To turn off the check and replacement of Let's Encrypt certificates affected by the bug, add the following lines to the panel.ini file:

[ext-sslit]
renewLetsEncryptRevokedCertificates = false

Note that the Let’s Encrypt extension is not updated yet – this extension is quite more complex because of Plesk 12.5 and Plesk 17.0 support. We’re working on this.
 
Let’s Encrypt 2.8.7 is also released: Let's Encrypt - Plesk Extensions

Changelog:

[*] Let's Encrypt has found a bug and revokes some of its SSL/TLS certificates on March 4. This improvement solves the issue. The Let's Encrypt extension will check domains as a part of the "Autorenew" feature, then will renew and replace affected Let's Encrypt certificates. Future autorenew tasks will be done as usual when SSL/TLS certificates are about to expire.

To turn off the check and replacement of Let's Encrypt certificates affected by the bug, add the following lines to the panel.ini file:

[ext-letsencrypt]
renew-lets-encrypt-revoked-certificates = false
 
Hello,

Does anyone know why on Plesk for Windows, Let's Encrypt does the validation via DNS records for some domains but prefers http validation for other domains?
How can I control this?
Is it possible to set validation to DNS only?
Usually HTTP validations fail due to custom web.config rules or http to https redirects.
I would prefer to set all domains to use DNS validation instead because it works flawlessly.


Regards,
Adrian
 
Does anyone know whether meanwhile it is possible to hide the "wildcard" certificate option from customers? Our customers keep checking the box and create support requests for DNS settings, but we don't want to offer wildcard support. We'd like to reduce the number of support requests where customers run into the DNS update request after they attempt to create a wildcard certificate. Instead they shall only see the normal certificate options for non-wildcard certificates.
@Peter Debik

What is the reason for not wanting to support the wildcard certificate?
Maybe it's because your webservers are not running the authoritative DNS.
If that's the reason, you may be interested in my solution for that:
DNS-01 delegated to webserver

If that is not the reason, I am interested in what is.
 
Back
Top