Let's Encrypt extension

[learning_curve]

....

4. you can also assign that certificate to another domain (if this action makes sense)
5. autorenewal feature will renew the certificate on all those websites, i.e. on the domains and on the subdomains​

.....

Thank you! These ^^ items are the two items specific to our question (reference the bold text)

We asked about a *Wildcard certificate covering MULTIPLE domains, as well as MULTIPLE sub-domains.

If we've understood your post correctly then we CAN do this now, using the LE Extension? In addition, if we wait until the new LE Extension is released, that will then also remove the manual step currently needed for sub-domain(s). However, it will NOT remove the manual step needed, for any other domains that the certificate is applied to and/or their own sub-domain(s)?

i.e. Take the specific case we've mentioned previously, but now use the LE Extension and the guidance in your reply. So we would issue a *Wildcard certificate against Domain A and its Sub-Domain(s) but, then add the same certificate to cover Domains B, C, D, E, F. etc all of which, have their own sub-domain(s)? There's no limit to the number of domains (or sub-domains) that this will work with presumably? There's no limit mentioned so far, but we are assuming that the default, standard LE number of requests per day will apply anyway?

This process ^^ is exactly what we are doing without the LE Extension at present, because the LE certificates are generated external to Plesk (or in a foreign land as you prefer to say ) but... as mentioned, this is always without any auto-renewal facility. A certificate renewal always has to be made manually if/when we use this external setup.

 

[Ruslan Kosolapov]

So we would issue a *Wildcard certificate against Domain A and its Sub-Domain(s) but, then add the same certificate to cover Domains B, C, D, E, F. etc all of which, have their own sub-domain(s)?

You can assign the same SSL certificate to different domains, but I still don't get the idea
If you have domainA.com with subdomains and domainB.com with subdomains you can't secure all domains and subdomains with the same wildcard certificate, because:
1. to secure domainA.com and domainB.com with wildcard, your wildcard should be issued for *.com, at that you are not the owner of .com zone and you can't get *.com certificate; if you talking about third-level domains, e.g., domA.myhost.com and domB.myhost.com, you can issue *.myhost.com (you have to create myhost.com in Plesk to use LE) and secure domA.myhost.com and domB.myhost.com, but see the next issue:
2. wildcard certificate secures only one level, i.e., *.domain.com will secure abs.domain.com, but will not secure zxc.abs.domain.com, so, it's impossible to secure subdomains of domainA.com and domainB.com even you are the owner of .com zone

 

[Ruslan Kosolapov]

Hi. We've released an update for Let's Encrypt Extension: Let's Encrypt - Plesk Extensions

Changelog:

2.7.1 (29 November 2018)

• Added integration with the SSL It! extension.
• Updated the list of trusted root certificates with those from Mozilla CA bundle.
• Updated the information about the limit of certificates that can be issued per a registered domain, per a week. Now the messages show the limit of 50 certificates.

 

[learning_curve]

You can assign the same SSL certificate to different domains, but I still don't get the idea

The idea? The idea is simplicity when covering domains AND mail setups properly. 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, that unless lots of other more detailed setup work is completed elsewhere, there will always be a mis-match involved which is shown and reported if... domains are using their own mailservers, which are then 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

If you have domainA.com with subdomains and domainB.com with subdomains you can't secure all domains and subdomains with the same wildcard certificate

This is incorrect, because we already have this setup and it works pefectly
To confirm, it's ONE *WLE Certifcate, which cover's multiple domians, all of which have sub-domains. However, your statement may be correct if / when only using the Plesk Extension, which is why we asked the previous questions

because:
1. to secure domainA.com and domainB.com with wildcard, your wildcard should be issued for *.com, at that you are not the owner of .com zone and you can't get *.com certificate; if you talking about third-level domains, e.g., domA.myhost.com and domB.myhost.com, you can issue *.myhost.com (you have to create myhost.com in Plesk to use LE) and secure domA.myhost.com and domB.myhost.com, but see the next issue:
2. wildcard certificate secures only one level, i.e., *.domain.com will secure abs.domain.com, but will not secure zxc.abs.domain.com, so, it's impossible to secure subdomains of domainA.com and domainB.com even you are the owner of .com zone

See above, but for more reference, the single *WLE Certificate is issued against the same FQDN that Plesk is setup on, so... This then covers: Host / Plesk (Host:8443) / Mail Server / WWW / Webmail / All Host Sub-Domains PLUS... All Named Domains / All Named Domains' Sub-Domains etc. etc. By default, this ALSO covers all Named Domains:8443 too... (although we have all Named Domains:8443 re-directed to Host:8443 (for security / admin control etc) but other Plesk users don't use any re-direct, because they specifically want this access (but we're not sure why)

 

[Ruslan Kosolapov]

I guess, the SAN part contains several *.<domain> records, am I right?

 

[learning_curve]

I guess, the SAN part contains several *.<domain> records, am I right?

Technically speaking, we guess yes, you are correct! It's not a SAN certificate in the usual / traditional sense, it is just a genuine multi-domain *wildcard Let's Encrypt single certificate (and free - which we all like!)

The easiest way to see how easy / detailed / applicable this may be, is to perhaps try it, on your test server c/w test domains. The provider we use (for reference) is HERE (there are many other providers / methods as you know). Using a test server / test domains, you'll be able to duplicate exactly as we have described. There's nothing wrong with the Plesk Extention, we're obviously just looking for extra+ if we can find it within the extention Note: The usability of this depends on the number of domains on one single IP etc as they all have to be individually validated via DNS... We'd say any that any more than 50 domains, equates to a lot of tedious repetitive work to achieve the complete validation and may not be worth all the effort involved.

 

[Ruslan Kosolapov]

Ok, thanks for the case, very interesting

I still think that "Keep secured" feature could be quite convenient for your case - you just say "hey, Plesk, keep my websites secured" and forget about it
The only issue I see here - if you have a lot of subdomains, you can reach LE limits. Maybe, we should implement "keep secured with wildcard certificate" feature

 

[Ruslan Kosolapov]

Hi.

We’ve released Let’s Encrypt Extension 2.7.2: Let's Encrypt - Plesk Extensions

Changelog:
2.7.2 (17 January 2019)

• In Plesk for Linux 17.8 and later, the extension now supports issuing ECDSA certificates. To have the extension issue certificates signed with ECDSA, add the following lines to the panel.ini file:

[ext-letsencrypt]
key-algorithm = ECDSA
ecdsa-curve-name = prime256v1 ; can be omitted

• [-] Improved the "Adding Your Own Subscription" screen: the "Secure the domain with Let's Encrypt" section is now placed correctly. (EXTLETSENC-633)

Note that the RSA/ECDSA switch is global for the server, and it doesn’t affect existing certificates.


Regarding ECDSA, what’s this and why it matters, in short: ECDSA is a way how to encrypt the certificate. The “old” way called RSA, it’s still in use, and it isn’t “bad”, but ECDSA is better because ECDSA is more effective in terms of CPU load. In other words, ECDSA improves the performance of webserver and web browser with even better security (ECDSA default key size is 256, RSA default key size is 2048, at that 256 ECDSA roughly equal to 3072 RCA).

On my machine (I’ve used ‘openssl speed rsa2048 ecdsap256’ command to measure the performance):

sign/s verify/s algorithm
28.5 605.0 rsa 2048 bits
1532.0 339.9 256 bit ecdsa (nistp256)

Note that ECDSA improves TLS handshake only, the other parts of communications will not get the performance boost.

For the real websites, there are reports about 10-50% performance boost (in terms of requests per second, don’t confuse this with response time).

So, if the website has a lot of visitors or if the Plesk server has a lot of websites, I’d recommend using ECDSA. If the website’s load isn’t high – RSA is still ok, but ECDSA can be recommended because of security (remember, default ECDSA is more secure than default RSA).

And one more note – there is an abbreviation “ECC”, it’s more general term than ECDSA (ECC is the family of algorithms, ECDSA is one of those algorithms), but in the scope of Let’s Encrypt and SSL Certificates you can consider these terms as synonyms

 

[learning_curve]

That's a great positive change It was posted in Plesk Suggestions some time ago: Plesk Let's Encrypt and support for ECDSA certificates which was then commented on, inline with this forum post: Input - Plesk / Let's Encrypt > Support for ECDSA Certificates after which, many extra votes were added to the suggestion. Now the working model is here!

Now, it's a choice between an RSA OR an ECDSA Certificate that's generated, which is great progress. In the previous data / discussions (links above) an additional option of both certificates being generated is mentioned; i.e. generate both RSA AND ECDSA Certificates, but, this COULD only be supported within Plesk via Plesk ammending the standard templates, if it's going to be easy to use both certificates, otherwise, it means custom templates being self-generated and used etc.

Why both certificates? Because...both certifcates are already supported by Apache AND Nginx later releases, which allow recognition / switching between the two certificates by default

So the only question now, is...Within the next or future release of this Plesk extension, will the current OR certificate choice soon be appended with a BOTH certificates choice as well?

 

[Ruslan Kosolapov]

Hi!

We’ve released Let’s Encrypt Extension 2.7.3 with a couple of bugfixes.

Changelog:

2.7.3 (24 January 2019)

• Increased stability of issuing ECDSA certificates.
• The "Keep your websites secured with free SSL/TLS certificates" option no longer occasionally incorrectly prolongs an issued SSL/TLS certificate.

 

[Ruslan Kosolapov]

So the only question now, is...Within the next or future release of this Plesk extension, will the current OR certificate choice soon be appended with a BOTH certificates choice as well?

The plan was to do it in this release
But there are technical troubles - certificate management is Plesk Core responsibility. The extension can issue two certificates, but it can't install them on the same domain - Plesk Core supports only one certificate per vhost. The extension can influence on configs generation, but in very limited scope, and this scope isn't enough. Moreover, there are a lot of small minor issues with ECDSA in Plesk Core, and, I think, there will be another hotfix release soon

It's similar to Mail SNI support - to support Mail SNI we have to wait for Postfix, then wait for Plesk Core, and only then we can implement it in the Let's Encrypt Extension.

At that the importance of ECDSA is not so clear, at least for now.

So, not in the nearest future.

 

[learning_curve]

Ahh well, best laid plans etc

....Plesk Core supports only one certificate per vhost....

Yep, that's the current limiter we meant, when we mentioned "...Plesk ammending the standard templates..." which to be fair, is NOT difficult, or complex, but is obviously not near the top of the "things to do list" looking at this:

So, not in the nearest future.

Both Apache and Nginx have had the functionality to recognize and switch between RSA/ECDSA for some time now, but if anybody needs this meantime, creating custom templates should be able to support both as a workaround

 

[Bitpalast]

@Ruslan Kosolapov
Please see ECDSA prohibits using Let's Encrypt certificate to protect mail server
The ECDSA certificates break mail server security setting. They cannot be applied to it. If you try to apply such a certificate to the mail server security, the software reverts to the default certificate instead. It even writes the .pem files, but uses the default certificate for their content, not the ECDSA Let's Encrypt certificate.

 

[learning_curve]

Our next question, may or may not be related to the post by @Peter Debik above...
For all single domains, we used the Plesk Extension 2.7.3 (24 January 2019) to issue ECDSA certificates.

In the 2.7.2 release post above by @Ruslan Kosolapov the panel.ini mod is shown as:

[ext-letsencrypt]
key-algorithm = ECDSA
ecdsa-curve-name = prime256v1 ; can be omitted

but... in the Official Plesk Changelog for the 2.7.2 release, the panel.ini mod is shown as:

[ext-letsencrypt]
  key-algorithm = ECDSA
  ecdsa-curve-name = prime256v1

The difference is the appendix to the last line >> ; can be omitted

We used the mod from the Official Plesk Changlog but @Peter Debik has used the mod from the post above.
Is there a difference in terms of the end result and if so, which is actually correct?
There's no further guide, with either the release of 2.7.3 either in this thread, or in the Official Plesk Changelog...

We're asking the question, because although in our case all the new ECDSA certificates do work perfectly and pass all tests** we have the following raised as warnings in several tests:

The ECDSA certificate provided has not been signed using the proper algorithm according to HIPAA guidance

and

The ECDSA certificate provided has not been signed using the proper algorithm according to NIST guidelines

Do you think, that this is part of the Plesk Extension's "work in progress" @Ruslan Kosolapov or is it an issue (somewhere) with our own setup?

**For ref @Peter Debik Currently, we have an RSA not ECDSA multi-domain *wildcard Let's Encrypt certificate for the host FQDN which we use for securing Plesk and securing mail. For each domain that now has it's own ECDSA certificate, this existing RSA certifcate always overrides the ECDSA certificate that's been applied to the domain via mail settings for that domain. We ran the tests you showed in your linked thread but the correct .pem certificate content, coming from Lets Encrypt certificate ^^ is always provided (via Postfix etc). This may change... when we renew the multi-domain *wildcard Let's Encrypt certificate and change that to ECDSA. We'll be double cheking for sure!

 

[learning_curve]

There's been no answer to the above posted yet, but we've found it ourselves elsewhere @Ruslan Kosolapov The HIPAA / NIST issues are not Plesk related. The next two Let's Encrypt certificates (in the full certificate path) are RSA not ECDSA and this (apparently) is the reason for the 'issue' warnings being given. There's no issues at all with the certificate's performance or validity. As/when Let's Encrypt do change that (they are working on it) the 'issues' will disappear. We're guessing therefore, that the online Plesk posted inconsistencies (above) are also irrelevant / make no difference so we've just ignored them now.

Finally @Peter Debik we've now replaced our RSA multi-domain multi *wildcard Let's Encrypt certificate for the host FQDN which we use for securing Plesk and securing mail and other domains etc etc with a new ECDSA one, using acme.sh via CLI. It's fine and works perfectly. As/when the Plesk Extension can also produce exactly the same combination certificate (see earlier posts on this thread) we'll very happily use that instead for this certificate, as well as all the individual domain certificates that we use if for now. However, FWIW even after this top level change, we still have none of the issues that you posted above (wrong certificate use / wrong pem file content etc) despite everything now being ECDSA and no RSA involvment at all, at Plesk level (only above Plesk via Let's Encrypt as mentioned ^^).

 

[Bitpalast]

Yes, thank you for your feedback. I did not go into this further as Igor had confirmed that it is a known bug EXTLETSENC-650. So we will simpyl live without ECDSA version for now. It is now really influencing anything on speed for all the existing customers anyway.

 

[Ruslan Kosolapov]

@Ruslan Kosolapov
Please see ECDSA prohibits using Let's Encrypt certificate to protect mail server
The ECDSA certificates break mail server security setting. They cannot be applied to it. If you try to apply such a certificate to the mail server security, the software reverts to the default certificate instead. It even writes the .pem files, but uses the default certificate for their content, not the ECDSA Let's Encrypt certificate.

This is that very issue with Plesk Core I've mentioned above. We're working on it now. Most probably, the only solution we can offer here is to ignore ECDSA option for panel/mail-server certificate.

 

[trialotto]

This is that very issue with Plesk Core I've mentioned above. We're working on it now. Most probably, the only solution we can offer here is to ignore ECDSA option for panel/mail-server certificate.

That would also be a good idea from the perspective of security : the main purpose of certificates is enhancing security and not performance related to security certificates.

This whole discussion is a bit odd, it is comparing apples with pears: ECDSA is "young" and still "doubtful" for many reasons, including political and technical reasons, primarily the technical reason of proper implementation (which can still not be guaranteed at all !!) - RSA is "old" and "reliable" (even in the sense that flaws are known and solvable).

Nevertheless, the "comparing apples with pears" statement becomes immediately clear when reminding that ECDSA implementation on the 256-bit level in Plesk is a bit odd and very incomparable to basic RSA implementation in Plesk : Plesk uses RSA at a 2048-bit level as a starting point, whereas ECDSA at the 256-bit level would be essentially the equivalent of a RSA implementation at the 3072-bit level.

Sure, ECDSA 256-bits certificates would be more performant (since "shorter certificates") than RSA 3072-bit certificates - but not necessarily more secure : in fact, they are equivalently secure in terms of the security level of 128 bits - but then we are not taking into account the (known and still unknown) pitfalls of ECDSA.

Sure, ECDSA 256-bits certificates would be more performant (since "shorter certificates") than RSA 4096-bit certificates - but not more secure : in fact, the RSA 4096-bit certificate is more secure - and on a modern server, the (considerable) "certificate length" would not be an issue at all.

In short, I am stating that we are drifting away from what this discussion should be about : security!

It is not a good thing to hammer on ECDSA at the 256-bits level : one should not focus on certificate performance alone.

It is a good thing to focus on security levels as opposed to certificate performance : just implement RSA at 4096-bit level by default and allow the ECDSA (at 256-bit level) only as an option to speed up certificate related processes if and only if the application is safe and secure enough to do so.

@Ruslan Kosolapov ........ please do not make ECDSA a default or one of the defaults in the Plesk eco-environment - for many reasons that you are probably aware of.

Regards.........

 

[learning_curve]

Some interesting good points there @trialotto Thank you. In our case / setup, currently, we're fine with ECDSA only.

The present release of the Plesk Let's Encrypt Extension does offer the choice of RSA OR ECDSA with RSA being the default, whilst ECDSA requires a mod via panel.ini etc. So users do already have the choice as to which way they wish to proceed. Giving users a choice is a good thing (in our opinion) but in this case, you may disagree of course

Working on what you have posted, would you support the Plesk mod that we have mentioned above, where BOTH RSA and ECDSA certificates could be provided and are then invoked via Plesk standard Templates? Users could still opt only for RSA OR ECDSA certifcates regardless, when using this method... As posted already, Apache AND Nginx have supported dual certificates types for a long time now. It is possible to provide support within Plesk too, if, users are willing to create and utilise their own custom templates. A few people we know (albeit non Plesk users) do this already, because it allows broader security coverage in terms of browers / ages / releases / preferences / performances etc. Just a thought...

 

[trialotto]

@learning_curve

With respect to your statement

The present release of the Plesk Let's Encrypt Extension does offer the choice of RSA OR ECDSA with RSA being the default, whilst ECDSA requires a mod via panel.ini etc. So users do already have the choice as to which way they wish to proceed. Giving users a choice is a good thing (in our opinion) but in this case, you may disagree of course

I have to emphasize that I do not agree or disagree : the "freedom of choice" is valuable, but in every way this freedom should be limited to a range of settings that is always associated with some decent level of security - the minimum of the before mentioned range should be resulting in decent security for the entire Plesk instance.

Simply stated, Plesk (end-)users should only have the freedom allowed by a (secure) range that is configured by a well-seasoned sysadmin maintaining the Plesk instance.

In essence, the Plesk eco-environment allows any Plesk admin to set some security level with some mechanism - RSA or ECDSA.

In short, the Plesk eco-environment is far away from allowing the valued "freedom of choice", given that

1 - for Plesk admins, a choice has to be made between either RSA (default) or ECDSA : a Plesk admin can use panel.ini - this is sufficient for selecting one of both
2 - for Plesk end-users, a choice cannot be made between either RSA (default) or ECDSA Plesk (end-users) : no "switch" available through the Plesk Panel

and hence it is not a matter of agreeing or disagreeing : the current Plesk eco-environment is too limited with respect to certificate protocols (RSA/ECDSA) or security levels.

Given my response above, I can now easily respond to your statement

Working on what you have posted, would you support the Plesk mod that we have mentioned above, where BOTH RSA and ECDSA certificates could be provided and are then invoked via Plesk standard Templates? ..

by stating : yes, please!

It will require a very simple set of adjustments in Plesk, amongst others being :

a) adding lines to the Nginx default config (as shipped with Plesk) - these lines can contain reference to ECDSA based certificates
b) adding config variables to panel.ini to set the server-wide required security level - the Plesk admin can control minimum security level, applying to both RSA as ECDSA
c) adding a "switch" box to Plesk Panel - Plesk (end-)users can select the certificate of preference at a security level greater then or equal to the server-wide security level
d) adding a cipher suite that allows a sequence of ciphers that is aligned with both points b and c

and please note that it does not make any sense to make the same adjustments on the Apache level - when talking about performance and security, one should stay away from the resource ineffective Apache and simply let Nginx do the work : close external access to ports 7080 and 7081 (which are accessible by default) and add a low security level for SSL/TLS handshakes for any communication between Nginx and the (back-end) Apache server, in order to improve security and performance.

The latter note also makes clear why I had my (reasonable) doubts about any discussion with respect to "security" and "performance of security" - at this moment, it is often forgotten that we are talking about scenario's in which we have either Apache or Apache + Nginx, with both scenario's having the burden of the relatively ineffective Apache and the Nginx + Apache scenario also having the burden of open ports 7080 and 7081 : it might make sense to (one the hand) improve security or (on the other hand) to improve performance of certificate related processes, but that would be the wrong approach if security loopholes and resource inefficiency still remain in the Apache setup.

Hope that the above is some food for thought....... or just a blatant suggestion to Plesk Team to improve Plesk or the Plesk Let's Encrypt extension.

Regards...........