Facebook
Twitter
Plesk 12.5.30, latest update
CentOS 7.2 64-Bit
Let's Encrypt extension 1.6
Nginx as frontend server activated
Issue:
A customer managed to break the Nginx configuration, bringing down the web server for all customers hosted on the same machine by installing several Let's Encrypt certificates in a row.
Reproduce like this:
Have three or more domains, each with a Let's Encrypt certificate without the "www."-option checked in place. Then decide that you want the "www."-option. Click on the Let's Encrypt icon of your first domain, check the option and click "Install". Then do NOT WAIT on the process to finish, but open a second tab and do the same for the second domain. Again do not wait on the process to finish, but open a third tab and do the same for the third domain. The situation you need is that several Let's Encrypt installation processes are running at the same time.
This is what happens:
The first "install" process finishes and will restart Nginx for the new configuration to become active. However, at this time the second process or third have deleted the old certificate but not yet installed the new certificate. Nginx restart that was initialized by the first process will fail, because now Nginx cannot find the certs that are still listed in the second or third domains' configuration files.
Why is this a real issue that needs to be fixed?
Even when a single customer does not behave like described, it can very well happen, that two or three customers make changes to their certificates at the same time, which would lead to the same issue as Nginx will not find cert files of the installation that is not yet completed when it restarts the installation that was completed.
Suggested solution:
a) Nginx should not be restarted immediately after a new certificate has been installed, but it should wait for e.g. a minute or two. This will make sure that customers who are impatient and are re-creating/re-issueing certs without waiting on a previous install to complete cannot break the configuration by their behavior.
b) Obsolete certificate files should be left on the server until the new cert files have been installed in the cert directory. Currently, the obsolete, old files are being deleted BEFORE the new cert files are in place and the Nginx configuration files are updated.
CentOS 7.2 64-Bit
Let's Encrypt extension 1.6
Nginx as frontend server activated
Issue:
A customer managed to break the Nginx configuration, bringing down the web server for all customers hosted on the same machine by installing several Let's Encrypt certificates in a row.
Reproduce like this:
Have three or more domains, each with a Let's Encrypt certificate without the "www."-option checked in place. Then decide that you want the "www."-option. Click on the Let's Encrypt icon of your first domain, check the option and click "Install". Then do NOT WAIT on the process to finish, but open a second tab and do the same for the second domain. Again do not wait on the process to finish, but open a third tab and do the same for the third domain. The situation you need is that several Let's Encrypt installation processes are running at the same time.
This is what happens:
The first "install" process finishes and will restart Nginx for the new configuration to become active. However, at this time the second process or third have deleted the old certificate but not yet installed the new certificate. Nginx restart that was initialized by the first process will fail, because now Nginx cannot find the certs that are still listed in the second or third domains' configuration files.
Why is this a real issue that needs to be fixed?
Even when a single customer does not behave like described, it can very well happen, that two or three customers make changes to their certificates at the same time, which would lead to the same issue as Nginx will not find cert files of the installation that is not yet completed when it restarts the installation that was completed.
Suggested solution:
a) Nginx should not be restarted immediately after a new certificate has been installed, but it should wait for e.g. a minute or two. This will make sure that customers who are impatient and are re-creating/re-issueing certs without waiting on a previous install to complete cannot break the configuration by their behavior.
b) Obsolete certificate files should be left on the server until the new cert files have been installed in the cert directory. Currently, the obsolete, old files are being deleted BEFORE the new cert files are in place and the Nginx configuration files are updated.