• 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

Thanks @trialotto Yes, agree with the Plesk Admin / Plesk End-Users difference. That makes perfect sense. We were slightly blindsided there as we only have Plesk Admin. All of our "users" (i.e. not all usual public domain vistors / customers etc ) are completely outside of Plesk anyway and must submit requests for setup changes via messging etc. Most Plesk users will be in the situation that you've mentioned we think. In terms of BOTH RSA and ECDSA certificates, your "...by stating : yes, please!" is enough :D We've mentioned this quite a few times before and would be very pleased if / when Plesk finally add this by default.
 
I just noticed that I'm unable to renew/issue staging certificates using the CLI with Let's Encrypt version 2.8.0-518:

Code:
# plesk bin extension --exec letsencrypt cli.php -d "www.mydomain.tld" --staging                
[2019-05-31 16:26:30.540] ERR [extension/letsencrypt] Execution of /usr/local/psa/admin/plib/modules/letsencrypt/scripts/cli.php failed with exit code 1 and the output:
Resource not found in directory: 'newAccount'.
Execution of /usr/local/psa/admin/plib/modules/letsencrypt/scripts/cli.php failed with exit code 1 and the output:
Resource not found in directory: 'newAccount'.

This used to work with previous versions of Let's Encrypt.

Can anybody confirm this?

Note: It also doesn't work when I remove the "--staging" parameter.
 
Try to remove the line containing "https://acme-v01.api.letsencrypt.org/directory" in file /usr/local/psa/admin/conf/panel.ini or in /usr/local/psa/var/modules/letsencrypt/cli.ini

Thanks @IgorG for the reply. I checked those files, no such line exists in both of the files. In fact, cli.ini doesn't exist, so everything is at default values.
I also removed and re-installed the Let's Encrypt extension, the result is still the same.
 
Good to see wildcard certificates now supported by the extension, thank you.

2.8.0 (28 May 2019)

[*] ACMEv2 is now used by default. It makes issuing wildcard certificates also available by default with no need to additionally configure the extension to support ACMEv2.​

In my scenario, it does not work as anticipated. My setup:

example.com (subscription)
- example.com (web hosting)
- *.example.com (web hosting)
- foo.com (alias for example.com)
- bar.com (alias for example.com)

With the following options ticked:

Include the "www" subdomain for the domain and each selected alias​

And all the aliases moved into the Selected domain aliases column, the resulting Certificate Subject Alt Name field of the certificate listed:

Not Critical
DNS Name: bar.com
DNS Name: example.com
DNS Name: foo.com
DNS Name: www.bar.com
DNS Name: www.example.com
DNS Name: www.foo.com

After the new extension version with the following options ticked:

Include the "www" subdomain for the domain and each selected alias (greyed out)
Secure webmail on this domain (greyed out)
Issue a wildcard SSL/TLS certificate​

And all the aliases moved into the Selected domain aliases column, the resulting Certificate Subject Alt Name field of the certificate lists:

Not Critical
DNS Name: *.example.com
DNS Name: bar.com
DNS Name: example.com
DNS Name: foo.com​

I am expecting to see listed www. on all my aliased domains. Consequently the web browser issues a security warning if a www. alias is requested.
 
Hi all. We've released the next version of the Let's Encrypt extension.

The full changelog: https://docs.plesk.com/release-notes/onyx/change-log/#17811-mu20190528

Let’s Encrypt 2.8.0
Let's Encrypt - Plesk Extensions

Highlights:
  • Stability improvements (especially for ECDSA)
  • ACME v2 is set by default (the previous default was ACME v1)
    • What’s this?
      • ACME is a protocol (API) for communication with Let’s Encrypt servers, i.e., the extension uses this protocol to issue SSL certificates
    • Why we changed the default version of the protocol?
      • Let’s Encrypt consider v1 as deprecated and recommends using v2
    • What does it mean for end-users?
      • wildcard option will be enabled by default (before admin should set ACME v2 in panel.ini)
    • How can I return it back?

Also, I'd recommend you to take a look on the SSL It! extension: Important - SSL It! Extension
 
This is a small issue, for consideration before the next Plesk Extention upgrade (maybe) @Ruslan Kosolapov

We use the Plesk Extension, not for all, but for the majority of the domains that we host. Where we see differences or potential issues, we use ACME.SH instead. The latest Plesk Extension release is great and has many improvements. We've experienced some of them already :) This small issue is to do with a domains that have conditional re-directs applied (i.e. re-direct apart from certain IPv4 and/or IPv6 addresses).

A) If this conditional re-direct is applied by .htacess (and/or other method probably) and Nginx is running as proxy for Apache, there are no issues. The certificates are sucessfully auto-renewed by the Plesk Extention.

B) If this conditional re-direct is applied directly by Nginx and Apache is NOT running at all (by choice), there are issues. The certificates are NOT sucessfully auto-renewed by the Plesk Extention.

A no sub-domains example domain, is shown below. First, the extract from the e-mail notification:
Could not renew Let's Encrypt certificates for *** *** (login admin). Please log in to Plesk and renew the certificates listed below manually. Renewal of the following Let's Encrypt certificates has failed:

* 'Lets Encrypt ***.com' [days to expire: 29]
[-] ***.com
[-] webmail.***.com
[-] www.***.com

Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz/8***long sequential number***
Details:
Type: urn:ietf: params:acme:error:unauthorized
Status: 403
Detail: Invalid response from https://###.com/[**IPv6** address]: "<!DOCTYPE html>\n<html lang=\"en\" prefix=\"og: Open Graph protocol fb: http://ogp.me/ns/fb#\">\n \n<head>\n \n<base href=\"https://###.com"
The ***.com is the domain with the conditional re-direct applied and the ###.com is the re-direct target.

Extract from .htaccess file:
Code:
<IfModule mod_rewrite.c>
  Options +FollowSymlinks
  RewriteEngine On
  RewriteBase /
  RewriteCond %{REMOTE_ADDR} !=**.***.***.**
  RewriteCond %{REMOTE_ADDR} !=****:****:****:****:****:****:****:****
  RewriteRule ^(.*)$ https://###.com [R=301,L]
</IfModule>
Nginx re-direct data:
Code:
if ($remote_addr !~ "^**\.***1\.***\.**$"){
    set $rule_0 1$rule_0;
}
if ($remote_addr !~ "^****\:****\:****\:****\:****\:****\:****\:****\$"){
    set $rule_0 2$rule_0;
}
if ($rule_0 = "21"){
    rewrite /.? https://###.com/ last;
}
To solve this particular example (as the .htaccess file remains in place regardless) we switched the domain from Nginx only back to Apache c/w Nginx proxy and at the next auto-attempt, the certificate was sucessfully auto-renewed by the Plesk Extention. We then, reverted the domain back to Nginx only and have noted this specific 'requirement' will be needed just BEFORE the next Let's Encrypt Certificate auto-renewal date.

This is not a big issue (for us) as it affects a very small number of our domains, but we've posted it as it might also affect other Plesk users' Nginx only domains, where a Nginx direct, conditional re-direct is in place.
 
I've set the following to set a key size of 4096 on my Letsencrypt certificates;

/usr/local/psa/admin/conf/panel.ini

[ext-letsencrypt]

renew-before-expiration = 45
rsa-key-size = 4096
check-domain-cert-authority = true
According to the manual nothing has to be restarted but the key size does not change on renewal. When I manually do a /usr/local/psa/var/modules/letsencrypt/venv/bin/certbot command then I can set the key size to 4096 but if I do a renewal after this it changes back to the default 2048.

Does anybody know how to configure the letsencrypt extension to set a 4096 key size?
 
I configured
[ext-letsencrypt] renew-before-expiration 45
[ext-letsencrypt] rsa-key-size 4096
in panel.ini
Until a few weeks it worked like a charm for the last years, but now only 2048 certs are created.

Why it isn't possible to create 4096 certs? What do I have to do to create 4096 certs.

Greets
 
Hi! Small update:

2.8.1 (4 July 2019)
  • [-] Securing Plesk with SSL/TLS certificates from Let's Encrypt is now again available in Tools & Settings > SSL/TLS certificates. (EXTLETSENC-699)
  • [-] It is now possible to issue wildcard SSL/TLS certificates from Let's Encrypt if the DNS server component is not installed. (EXTLETSENC-558)
 
Can confirm, same problem here with certificates issuing only with 2048 instead of the defined 4096 Key-size. (Oldest certificate is from start of june so the problem seems to be older, maybe with the Let’s Encrypt 2.8.0 update or earlier? )
 
We confirm the bug about key size. The fix is scheduled to the next release of Let's Encrypt Extension (no ETA for now, sorry).

For the moment, I'd recommend trying ECDSA (it's more secure and faster than 4k RSA). The only issue with ECDSA is mail certificate.
 
The only issue with ECDSA is mail certificate

in the change log it says
Extension Updates
Let’s Encrypt 2.8.0
The Plesk mail server can now be secured with ECDSA certificates. (EXTLETSENC-650)

Can you elaborate on what exactly isn't working?

Some time after you (as Plesk) anounced the availability of ECDSA certs, we switched to them. Which broke mail delivery. As no-one then knew about the bug that became EXTLETSENC-650, it took some hours to find and resolve the issue. Also caused a bunch of - understandibly - irate clients.

Before switching to ECDSA certs again, I want to know 110% that it's working. Which according to you is not.

Cheers, Tom
 
Hi @Dukemaster. We'll check this issue on our test servers.

Thanks a lot PLESK TEAM. Today the Let's encrypt update was published over Plesk update/upgrade panel. Afterwards I renewed all of my own certificates and customers too, so I'm happy and satisfied that all domains have again RSA 4096 certs. Great job, PLESK Team, well done...
<3 Plesk :)
 
Hi.

Actually, @Dukemaster has already announced this ;) but still: we’ve released Let’s Encrypt Extension 2.8.2, this is a bugfix release.

Changelog:

2.8.2 (18 July 2019)
  • [-] The 'rsa-key-size' setting in the 'panel.ini' file now again sets an RSA key size. (EXTLETSENC-714)
  • [-] The webmail client of an add-on domain is no longer changed to the client of the main domain (or even disabled if webmail was disabled for the main domain) when any of the following actions are done to the SSL/TLS certificate of the main domain: issuing, manual or automatic renewal, enabling "Keep websites secured", or unassigning. (EXTLETSENC-603)
 
Back
Top