• 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

When a domain with enabled/installed SSL certificate is deactivated, in many cases the webserver configuration becomes broken

Bitpalast

Plesk addicted!
Plesk Guru
Username:

TITLE

When a domain with enabled/installed SSL certificate is deactivated, in many cases the webserver configuration becomes broken

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

CentOS 7.9, Obsidian since 18.0.37 at least

PROBLEM DESCRIPTION

On many servers and occasions we have observed that when a subscriber deactivates a domain that previously used an SSL certificate, the certificate file goes missing while the web server configuration file remains in place with the full non-disabled content. It seems that "later" (whenever that is, we don't know), the configuration is changed so that the web server configuration files no longer have the full content, but the "disabled" marker so that the missing certificates are no longer referenced.

The problem: During the phase when the SSL certificate files are missing (or maybe the references in the web server configuration files are simply wrong to non-existent files) and the update of the web server configuration file Apache and Nginx both report false syntax of their configurations. If for any reason a web server reload or restart becomes necessary, for example if other subscribers update their configuration, during that phase, the web server(s) fail to restart and all sites go offline.

STEPS TO REPRODUCE

We could not reliably reproduce the issue, but we have definitely seen it across at least three different machines during the past month.

1) Have a subscription with a Let's Encrypt SSL certificate in place. (Using SSLIt extension).
2) Login in as subsriber.
3) Set the domain to "deactivated".

Then run apachectl -t or nginx -t to see the result. Many a times the web server configuration becomes broken.

ACTUAL RESULT

First the SSL certificate name or reference is changed or the certificate files are removed, then the web server configuration is updated.

EXPECTED RESULT

First update the webserver configuration files to no longer reference the certificate files, then remove the certificates.

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
I can add to this that mainly the usage of the certificate(s) for webmail is affected:

Typical Apache ssl cert file error in this situation:
Code:
Unable to generate the web server configuration file on the host <hostname> because of the following errors:

Template_Exception: AH00526: Syntax error on line 50 of /etc/httpd/conf/plesk.conf.d/webmails/<domainname>_webmail.conf:
SSLCertificateFile: file '/usr/local/psa/var/certificates/scfK8FqIH' does not exist or is empty

file: /usr/local/psa/admin/plib/Template/Writer/Webserver/Abstract.php
line: 75
code: 0

Please resolve the errors in web server configuration templates and generate the file again.

Typical nginx cert file error in this situation:
Code:
Unable to generate the web server configuration file on the host <hostname> because of the following errors:

Template_Exception: nginx: [emerg] cannot load certificate "/usr/local/psa/var/certificates/scfAP7yzE": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/usr/local/psa/var/certificates/scfAP7yzE','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

file: /usr/local/psa/admin/plib/Template/Writer/Webserver/Abstract.php
line: 75
code: 0

Please resolve the errors in web server configuration templates and generate the file again.

The solution so far is to set the web server and webmail configuration to "no ssl" (no certificate usage), then open the certificate list and remove the now "unused" certificate from there. In another case the solution was to create a new certificate for both, because the certificate list did not show any certificates while the configuration checks of the webservers referenced entries to the (missing) certificate.
 
Back
Top