• 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

Calm down. I was just saying that there's restrictions on how plesk is used. None of the plesk templates are used (for subscriptions, resellers, etc.) when they provision.
And they control the IP address pool too.
But I don't care or want to deal with OBAS.
I'm trying to get it working in plesk with the restrictions applied by OBAS so it won't break them.

So I know I need a dedicated IP so OBAS won't share it with other subscriptions.
 
We’ve released Let's Encrypt 2.2 and Security Advisor 1.4.1.

Full changelog: Change Log for Plesk

Highlights:
  • Plesk Panel can now be secured with a Let’s Encrypt certificate. The corresponding setting is now available at the SSL/TLS Certificates page.
  • Upon installing (either at Plesk installation or separately), the Let’s Encrypt extension automatically attempts to obtain a certificate and secure the Plesk Panel. Thus, in most cases, a fresh installation of Plesk Panel is secured since the first login.
 
That's great! Got that working.

What would be the process for creating a new "default certificate" for sites that don't already have or need a certificate?
The current default certificate has expired.
 
We’ve released Let's Encrypt 2.2 and Security Advisor 1.4.1.

Full changelog: Change Log for Plesk

Highlights:
  • Plesk Panel can now be secured with a Let’s Encrypt certificate. The corresponding setting is now available at the SSL/TLS Certificates page.
  • Upon installing (either at Plesk installation or separately), the Let’s Encrypt extension automatically attempts to obtain a certificate and secure the Plesk Panel. Thus, in most cases, a fresh installation of Plesk Panel is secured since the first login.

That's really great to be able to secure Plesk Panel without having to create a subdomain.
 
Hi everyone,

FYI, we've released Let's Encrypt 2.2.1 update which fixes an annoying bug that could prevent the extension from working properly. Changelog:

[-] The extension incorrectly handled errors when communicating with Plesk Panel, which disrupted the functioning of the extension itself. Now it correctly handles such errors, shows an explaining message and continues working when possible. (EXTLETSENC-221)
 
One more Let's Encrypt extension update (v.2.2.2) was released yesterday:
  • To prevent Let’s Encrypt extension from automatically securing Plesk Panel on installation, add the following setting in panel.ini before installing or updating the extension: [ext-letsencrypt] disable-panel-auto-securing = false
  • [-] Setting the verify option to true in panel.ini config section for Let’s Encrypt extension resulted in inability to connect to the Let’s Encrypt CA servers. (EXTLETSENC-223)
  • [-] The command line interface did not allow to issue certificates for domains with www prefix. (EXTLETSENC-226)
  • [-] In certain cases, when installing or upgrading the extension, a valid certificate used for securing Plesk Panel was detected as insecure and replaced with Let’s Encrypt certificate. Now the extension automatically replaces only self-signed certificates. (EXTLETSENC-222)
 
I think we've found a bug in the LE 2.2.2 extension for Plesk 12.5. When domain aliases are added to plesk in all uppercase, the can still be added successfully to the actual working LE cert, but on reloading the LE UI, the uppercase domains still show in the "Available domain aliases:" selector column instead of the "Selected domain aliases" column. It seems to me the extension is likely doing a case sensitive match when determining which domains to show in the "Selected" column on page load.

Hope this helps somebody else be less confused. The easy workaround is to completely remove the domain aliases that were added in all uppercases, and readd them in lower case.

Great Extension, thanks!
 
I would like to share my experiences with this extension. I run some 40 different websites (including subdomains) on a dedicated Ubuntu 14.04 server and decided to secure most of them with LE. In the early stages I noticed that it was important to have well functioning AAAA links in my DNS. As I had moved this Plesk installation from an older server most of the domains hadn't defined those so I had to add them manually for the domains that I wanted to use LE with.
A second challenge was the securing of the Plesk main page. It took a while before I found the trick to do this: call one of my main domains on port 8443 so the corresponding LE certificate was used. This works fine now.
My main problem now is that some domains refuse to use their specific domain name in the certificate upon generation but are using the server's default certificate that I set up using LE. When generating a new certificate (after setting Certificate to 'Not selected' in Hosting Settings) it says it installed it successfully and the new certificate "Let's Encrypt domain.name" shows up again in the Hosting Settings window. But the Digicert Certificate Utility shows my server's default certificate and not the domain's one and the domain's site shows 'Not secure'. I also tried using the CLI Certbot command to generate the certificate without success. Anyone having a suggestion how to fix this?
 
Hi WielM,

But the Digicert Certificate Utility shows my server's default certificate and not the domain's one
Sorry, but we can't investigate a third party software / utility. Pls. use for example: => SSL Server Test (Powered by Qualys SSL Labs and provide the result - URL for investigations.

I also tried using the CLI Certbot command to generate the certificate without success. Anyone having a suggestion how to fix this?
Pls. check your HOSTING SETTINGS at => HOME > Subscriptions > YOUR-DOMAIN.COM > Hosting Settings and tell us ( or show us with a screenshot at your next post ) what your "Security" settings look like.

If you used the CLI commands, then the Plesk Let's Encrypt Extension will document all relevant informations at your "panel.log". Pls. post the corresponding entries for investigations.
 
Hi WielM,


Sorry, but we can't investigate a third party software / utility. Pls. use for example: => SSL Server Test (Powered by Qualys SSL Labs and provide the result - URL for investigations.


Pls. check your HOSTING SETTINGS at => HOME > Subscriptions > YOUR-DOMAIN.COM > Hosting Settings and tell us ( or show us with a screenshot at your next post ) what your "Security" settings look like.

If you used the CLI commands, then the Plesk Let's Encrypt Extension will document all relevant informations at your "panel.log". Pls. post the corresponding entries for investigations.

Thanks for responding!

The panel.log does not really provide interesting information:

Invalid response from https://acme-v01.api.letsencrypt.org/acme/new-reg: Error creating new registration :: not a valid e-mail address.

(I forgot the -m switch)

Would be great if you could help...

Cheers,
\Wiel
 

Attachments

  • Qualys.jpg
    Qualys.jpg
    88.1 KB · Views: 2
  • Hosting.jpg
    Hosting.jpg
    80.4 KB · Views: 2
Hi WielM,

pls. try to use the Plesk Repair Utility ( => Plesk Repair Utility ), as your screenshots point to different webserver configurations.

Example command ( logged in as user "root" over SSH ):
Code:
plesk repair web -y -v

Pls. investigate again your "panel.log" for possible new entries, after you used the Plesk Repair Utility and keep in mind, that the utility logs as well into a separate log - file, located at "/var/log/plesk" ( "repair-XXXXX.log" ).

Pls. try as well, to CHANGE the depending "wsvalem.nl" - certificate to "NONE" and afterwards backwards to the Let's Encrypt certificate for this domain.​


Additional informations:

Sometimes, it is as well a good idea to change the log - level ( TEMPORARILY! ), to get more informations in Plesk - log - files:

 
Hi WielM,

pls. try to use the Plesk Repair Utility ( => Plesk Repair Utility ), as your screenshots point to different webserver configurations.

Example command ( logged in as user "root" over SSH ):
Code:
plesk repair web -y -v

Pls. investigate again your "panel.log" for possible new entries, after you used the Plesk Repair Utility and keep in mind, that the utility logs as well into a separate log - file, located at "/var/log/plesk" ( "repair-XXXXX.log" ).

Pls. try as well, to CHANGE the depending "wsvalem.nl" - certificate to "NONE" and afterwards backwards to the Let's Encrypt certificate for this domain.​


Additional informations:

Sometimes, it is as well a good idea to change the log - level ( TEMPORARILY! ), to get more informations in Plesk - log - files:


Oops!
plesk repair failing:

Code:
igure-server'] with exit code [1] 
[FAILED]
    - httpdmng failed: [2017-08-06 22:48:54] ERR [util_exec]
      proc_close() failed
      ['/opt/psa/admin/bin/apache_control_adapter' '--restart'
      '--restart-interval' '300' '--http-port' '7080' '--https-port'
      '7081'] with exit code [255] 
      Error occured while sending feedback. HTTP code returned: 502
      [2017-08-06 22:49:02] ERR [panel] Apache config
      (15020523430.34000700) generation failed: Template_Exception:
      Can not restart web server: httpd stop failed
      10 /usr/sbin/apache2 processes are killed
     
      file: /opt/psa/admin/plib/Service/Driver/Web/Server/Apache.php
      line: 108
      code: 0
      Can not restart web server: httpd stop failed
      10 /usr/sbin/apache2 processes are killed
    Updating the file of sharing passwords and permissions of users  
    according to actual information ................................. [OK]
    Repairing web server configuration for all domains. This aspect  
    can be used with individual domains ("plesk repair web            
    example.com"), and on the server level ("plesk repair web") ..... [2017-08-06 22:50:41] ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/httpdmng' '--reconfigure-all'] with exit code [1] 
Error occured while sending feedback. HTTP code returned: 502
[FAILED]
    - httpdmng failed: Error occured while sending feedback. HTTP
      code returned: 502
      Error occured while sending feedback. HTTP code returned: 502
      Execution failed.
      Command: httpdmng
      Arguments: Array
      (
          [0] => --reconfigure-domains
          [1] =>
      admin.crooijmansplant.nl,admin.fancycars.nl,admin.hexspoortuinplan.nl,admin.mobiletruckwash.nl,admin.tabakja.nl,alemserakkers.nl,amberstruijk.eu,antibrains.com,ar.nosysoft.net,archive.smokersclubinternational.com,beklederijmaasenwaal.nl,bekledingsspecialist.nl,bigpharma.nl,bn.nosysoft.net,botenbekleding.nl,bpprice.org,bst.nosysoft.net,buurtwinkelheerewaarden.nl,camera.nosysoft.net,caravanbekleding.nl,critical-scientists.net,crooijmansplant.nl,eetcafedemaas.com,fancycars.nl,fedcaf.nosysoft.net,files.bpprice.org,forces-nl.org,forces.org,forum.freedom2choose.info,forum.mooitenerife.nl,forum.smokersclubinternational.com,freedom2choose.info,goedsanitair.nl,hexspoortuinplan.nl,horecaclaim.eu,horecaclaim.info,i-s-i-s.net,jachtwerfcapelleaandenijssel.nl,jouwkeuze.nu,kleinehoreca.info,mobiletruckwash.nl,mooitenerife.nl,natuurgidsencursus-ml.nl,new.fancycars.nl,new.forces.org,new.wsvalem.nl,new.zien-is-kennen.nl,nosysoft.net,notofctc.org,owncloud.bpprice.org,pasan.thetruthisalie.com,piratenpartij.nl,pp.nosysoft.net,ppeu2014.nosysoft.net,ppeukand.nosysoft.net,programma.piratenpartij.nl,psa.nosysoft.net,psademo.nosysoft.net,shop.nosysoft.net,siremis.nosysoft.net,smokerhub.net,smokersclub.smokersclubinternational.com,smokersclubinternational.com,staleigenwijs.nl,staleigenwijz.nl,stoffeerderijsmits.nl,tabakja.nl,tctactics.org,test.horecaclaim.info,test.nosysoft.net,test.thetruthisalie.com,thetruthisalie.com,wp.forces-nl.org,wp.nosysoft.net,wsvalem.nl,zien-is-kennen.nl
      )
     
      Details: [2017-08-06 22:50:38] ERR [util_exec] proc_close()
      failed ['/opt/psa/admin/bin/nginx_control' '--restart'] with
      exit code [6] 
      Error occured while sending feedback. HTTP code returned: 502
      Error occured while sending feedback. HTTP code returned: 502
      Can not reload proxy server:

Checking the usage of PHP handlers .................................. [OK]
Error messages: 0; Warnings: 0; Errors resolved: 0


exit status 1
 
Code:
> /opt/psa/admin/logs# sysv-rc-conf --list apache2
apache2      0:off      1:off   2:on    3:on    4:on    5:on    6:off
>:/opt/psa/admin/logs# sysv-rc-conf --list nginx
nginx        0:off      1:off   2:on    3:on    4:on    5:on    6:off

Looks ok to me?

\Wiel

BTW, in a parallel session I can start apache2 without problems while the plesk repair utility executes.
 
Hi WielM,

pls. consider to use the Plesk component "Webserver Configurations Troubleshooter", to be able to configure/check/rebuild webserver configuration files with the help of your Plesk Control Panel.
Code:
plesk installer --select-product-id plesk --select-release-current --install-component config-troubleshooter

=> HOME > Extensions > Webserver Configurations Troubleshooter


Pls. note, that "Plesk Repair Utility" has several MORE options, which you are able to use in case of issues/errors/problems. Pls. follow the above mentioned link, to read the documentation, as for example:
Code:
plesk repair web example.com -y -v


... and pls. check current webserver configuration files over the command line with the example commands:

Code:
apachectl -t

or

nginx -t

... and make sure, that the depending services are running:
Code:
service NAME-OF-THE-SERVICE status

or/and

service NAME-OF-THE-SERVICE restart
 
I've been using this extension for some time already. All buttons for all config files are green.
But I indeed have the feeling that something is wrong with nginx, not apache:

> nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] bind() to 172.16.0.1:80 failed (99: Cannot assign requested address)
nginx: configuration file /etc/nginx/nginx.conf test failed

That ip address points to the tap0 interface.

But I allso found some nginx config problems in /etc/nginx/plesk.conf.d/server.conf, where wrong ip-addresses are defined (when I added ipv6 report I used the Strato instructions' example ipv6 address (2a01:238:40ab:cd12:dead:beef:dead:beef) in stead of the actually assigned ipv6 address. Both new and old ipv6 addresses are defined in that conf file:

Code:
plesk.conf.d/server.conf:       listen [2a01:238:40ab:cd12:dead:beef:dead:beef]:80 ipv6only=on;
plesk.conf.d/server.conf:       listen [2a01:238:4374:e600:82f6:5ac8:d282:f195]:80 ipv6only=on;
plesk.conf.d/server.conf:       listen [2a01:238:40ab:cd12:dead:beef:dead:beef]:443 ipv6only=on ssl;
plesk.conf.d/server.conf:       listen [2a01:238:4374:e600:82f6:5ac8:d282:f195]:443 ipv6only=on ssl;

I have been trying to remove that address using Plesk IP Adresses but it says that this address is still used for hosting, although I removed the fake address from all IP definitions. Even checked in the psa database table dns_recs if any domain was still using it. The fake address still appears in some other psa tables though but those seem related to the address still being known in the IP addresses Plesk page.

Because Let's Encrypt uses the IPV6 address for checking, this old addresse hanging around in the Plesk system might cause these problems?

Thanks for all the help, BTW. It seems that I am getting closer to the core of this problem.

Grüsse,
\Wiel
 
One step forward again! I managed to remove the fake IPV6 address out of the list with Plesk IP Adresses and out of the Ubuntu interface definitions.. But for some reason, the Webserver Configurations Troubleshooter still uses the old fake IPV6 address to rebuild the nginx .conf files. Where else can I remove or change the IPV6 address that rebuild uses?
 
More info: the only places where I can find the fake IPV6 address in the psa database is in the Configurations, exp_event and log_components tables. Where in the Plesk GUI can I alter these tables?
 
Hi WielM,

Where in the Plesk GUI can I alter these tables?
Could you pls. explain, what makes you think, that altering the "psa" - tables "exp_event" and "log_components" ( which both have got absolute nothing to do with configuration settings! ) could solve your issue?

"Altering" a "psa" - database - entry is never recommended and you do this without Plesk support.


I have been trying to remove that address using Plesk IP Adresses but it says that this address is still used for hosting
Your root cause is here, as you still use one of your misconfigured IPv6 - addresses at one of your hosting settings ( otherwise Plesk would never point you to this fact, which makes it impossible for Plesk to completely remove the depending IPv4/IPv6 ).


Pls. check as well your network settings on your server, to solve your issue(s). ;)
 
Back
Top