• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Let's Encrypt extension

Hello

Since last night we have display errors on all our Plesk 12.5 servers on the Let's Encrypt extension.

* Steps to reproduce:
1) Logon to Plesk
2) Pick a domain
3) Click on "Let's Encrypt"

The page is then display as follows:
LE-Error.png

OS: CentOS 7.4.1708
Plesk version: 12.5.30 Update #74
Let's Encrypt version: 2.5.1 Release 344

We don't see this issue with our Plesk Onyx 17.5 servers.

Anybody else having the same issue?
 
Since last night we have display errors on all our Plesk 12.5 servers on the Let's Encrypt extension.

The page is then display as follows:
View attachment 14082

Anybody else having the same issue?

I can confirm this issue with the same specs:

OS: CentOS 7.4.1708
Plesk version: 12.5.30 Update #74
Let's Encrypt version: 2.5.1 Release 344

After removing and re-installing the Plesk extension it appears that only the previous version of the extension (2.5.0) is provided. Am I correct in assuming that Plesk is blocking the latest version until this issue has been fixed?
 
Today I saw that there's an update to version 2.5.2 Release 346. I installed the update and now the extension works fine again.

Thanks to the Plesk team for the quick fix!
 
Yep, we’ve released Let’s Encrypt Extension 2.5.2: Let's Encrypt - Plesk Extensions

Changes:
[-] Fixed the issue where, in Plesk 12.5, the Let’s Encrypt form displayed locale messages incorrectly. (EXTLETSENC-473)
Thank you, Ruslan.

Unfortunately the Plesk 12.5 Extensions Catalog still shows Let's Encrypt 2.5.1 with an Upgrade button (under "Installed"). When pressing the Upgrade button Plesk says "Information: The selected extension was installed.", but still has Let's Encrypt 2.5.0 release 270.
When manually removing the extension and re-installing it through the Extensions Catalog it still installs 2.5.0 release 270.

When will the latest 2.5.2 be available through the Extensions Catalog or automatic extension updates?
 
Hi @Visnet

AFAIR there is a cache for Extension Catalog feed, maybe it's the reason.
Try "Extensions > Settings > check for upgrades now" (it's for Plesk 12.5).

On our test servers I see 2.5.2 version.
 
Suggestion / Feature Request

By default, the Let's Encrypt extension pre-selects all alias domains of a domain to be included in the Let's Encrypt certificate. This can lead to some unwanted results, for example when one of the alias domains is removed from the DNS at a later stage (because it was only used for testing) which would result in Let's Encrypt being unable to renew the certificate.

It would be nice if there was an option that allows us to configure that alias domains should _not_ be selected by default in the Let's Encrypt extension.

Thanks for considering this.
 
....this feature request as described by you will be obsolete in January 2018, when Let's Encrypt wildcards certificates will be available => Wildcard Certificates Coming January 2018 - Let's Encrypt - Free SSL/TLS Certificates The choice to secure domains with a pre-selection of subdomains is still on the roadmap though, but without any ETA.
We've watched this closely and it's now been officially released and is live

Plesk is shown under the Projects integrating with Let's Encrypt section of the support data provided by Let's Encrypt. We currently run the Let's Encrypt Extension (version 2.5.2-346) for all our non *.wildcard domains without any problems. Is there an ETA for presumably (?)... a Plesk Extension update? Our interest is because we have some *.wildcard certificate renewals approaching very shortly and it would be very nice to switch all these over to Let's Encrypt too ;)
 
Hello.

We’ve just released Let’s Encrypt Extension 2.5.3 (Let's Encrypt - Plesk Extensions )

The changes:

2.5.3 (14 March 2018)
[-] Fixed the issue where the text on the "Secure domain" page was displayed in English regardless of the user's chosen interface language. (EXTLETSENC-481)
[-] Fixed the localization issue with locales except en-US. In this issue the message about a failed challenge ended with a placeholder instead of failure details. (EXTLETSENC-480)
[-] Fixed the link to the Let's Encrypt website on the "Secure domain" page. (EXTLETSENC-482)
 
Regarding the wildcard certificates:
  1. first of all, we should implement ACME v2 support and DNS challenges support in our extension
  2. the extension should be refactored, the amount of the refactoring is quite massive
  3. we have other features in our roadmap, that features also require a refactoring
  4. the stability of extensions is important for us, so, we're doing the refactoring in a safe manner
That's why I can't provide an ETA, sorry.

But yes, we're working on it.
 
By default, the Let's Encrypt extension pre-selects all alias domains of a domain to be included in the Let's Encrypt certificate. This can lead to some unwanted results, for example when one of the alias domains is removed from the DNS at a later stage (because it was only used for testing) which would result in Let's Encrypt being unable to renew the certificate.
It would be nice if there was an option that allows us to configure that alias domains should _not_ be selected by default in the Let's Encrypt extension.

Could you clarify the following points:
1. there is a domain alias, but there is no DNS records for it, am I correct?
2. if you know that the alias will be removed soon, why don't you just remove it from pre-selected list at first certificate issuing? :)

btw, "Keep secured" feature should try to issue/renew the certificate without "bad" domain alias.

UPD: there is a nuance - if current certificate is valid (not expired), "keep secured" feature will not replace it (because the new certificate doesn't contain a "bad" domain alias, so, replacing considered as degradation). But if the current certificate is expired, the new certificate (without "bad" domain alias) will be issued and installed on the domain.
 
Last edited:
Could you clarify the following points:
1. there is a domain alias, but there is no DNS records for it, am I correct?
2. if you know that the alias will be removed soon, why don't you just remove it from pre-selected list at first certificate issuing? :)

1. Yes, we provide all customers with an alias <customerdomain.tld>.<ourhostingdomain.tld> to allow them access to their new hosting even when DNS for <customerdomain.tld> is not yet pointing to our services. Some customers decide to remove the alias <customerdomain.tld>.<ourhostingdomain.tld> from the DNS (external server, not managed by Plesk) after they went online with their new hosting. From this point on, renewal of their Let's Encrypt certificate will fail if the customer has included the alias domain in the certificate.

2. It's the customers who don't remove the alias domain from the pre-selected list. We have it in our manuals that they should remove it before installing the certificate, but some of them will still keep it in the pre-selected list. That's why we'd like to change the defaults of the Let's Encrypt extension to _NOT_ include the alias domain by default.

It would be nice if there was an option to change the default behaviour of the extension :)
 
Regarding the wildcard certificates:
  1. first of all, we should implement ACME v2 support and DNS challenges support in our extension
  2. the extension should be refactored, the amount of the refactoring is quite massive
  3. we have other features in our roadmap, that features also require a refactoring
  4. the stability of extensions is important for us, so, we're doing the refactoring in a safe manner
That's why I can't provide an ETA, sorry. But yes, we're working on it.

A hypothetical question for @Ruslan Kosolapov Whilst we are waiting for the Plesk Extension to be refactored, tested and then released as an upgrade, what would prevent any Plesk user from producting *.wildcard Let's Encrypt certificates via another route e.g. any simple, Acme v2 compatible browser client like this one and then manually adding the new *.wildcard Let's Encrypt certificate to a domain via the Plesk GUI (but outside of the Plesk Extension > **mydomain**:8443/admin/ssl-certificate/list) We ask in advance in case this would / may cause issues for the current Let's Encrypt Plesk Extension. In theory, it shouldn't as the current *.wildcard certificates don't cause any issues, but... they are not issued by Let's Encrypt, hence the advance hypothetical question ;)
 
You cannot test the SSL mail subscription by opening the subdomain mail. in a web browser. That is something completely different. The SSL protection for the mail server is entered into configuration files on the server and is invisible on the WWW service. If you want to add SSL to the WWW service of the mail. subdomain you need a separate setting for that. You will need to add the mail-subdomain to the subscription or server enironment and finally to the certificate that you are using for the www service.
 
Yes you are right. Mailservice is working. But i used Nextcloud to authenticate against smtp by {mail.domain.com:143/imap/tls} which worked with Plesk 17.5.3. I was able to open https://mail.domain.com:443/ too. I now use {mail.domain.com:993/imap/ssl/secure/readonly} and Nextcloud works again.


Ok i found my problem:
The IP address is distributed as: shared instead of dedicated solved https://mail.domain.com:443/ being accessible again
 
Last edited:
Back
Top