LE CSRs are triggered for the aliasdomain target domain on
* domain deletion
* domain creation
* domain editing when
* the aliasdomain target changes (CSR triggered both for old and new
target)
* wwwalias is disabled or enabled
* letsencrypt is disabled or enabled (domain-local)
fixes#1597
Previously setting.letsencryptreuseold determined wheter both a domain's
private key and a CSR should be re-generated.
Preparing support of alias domains in LE certificates, this is changed to
only determine the re-generation of the private key. CSRs now are always
re-generated.
Depending on the data present, the LE cronscript may cause multiple
entries per domain in domain_ssl_settings.
This is due to $updcert_stmt interfering with the outer loop
while ($certrow = $stmt->fetch()): PDO's DB cursor sees rows newly created
by $updcert_stmt within the loop. As a consequence this also leads to
superfluous CSRs, thus increasing the certificate limit counter on the LE
side.
Solution: manifest the result of @$certificates_stmt@ on the PHP side in
its entirety prior to entering the outer loop.
This reverts commit 319668d384, reversing
changes made to aa592c7369.
Conflicts:
install/froxlor.sql
install/updates/froxlor/0.9/update_0.9.inc.php
lib/version.inc.php
trusty.xml: All files in conf.d get automatically included causing the location to be out of place and nginx fails to start
cron_tasks.inc.http.30.nginx.php: Location directives should be included in a host, nginx doesn't have the concept of global location directives in the way apache does
Reworked the initial implementation by hpmewes (https://github.com/Froxlor/Froxlor/pull/233) with
- bugfixes all over
- added support for apache and lighttpd also
- added an update sequence (instead of only modifying froxlor.sql)
- added english language variables
- added missing parts in admin_vhostsettings.php
- added parameter replacements as available since PR 244
PHP scripts
Although the implemented direction protection posed a prompt when
accessing the http://...com/protectedir/
it was still possible to call http://...com/protectedir/script.php
This vulnerability emerges from the precedence order of "location"
statements. The RegEx matching the PHP script is triggered before the
directory protection is evaluated. As a result, the PHP script is
interpreted and path parsing stops due to the circumflex (see
http://nginx.org/en/docs/http/ngx_http_core_module.html#location).
The fix involves adding a PHP parsing snippet to every protected
block. In order to prevent PHP-related config params repeatedly, the
required section is referenced using a prefix.
