Drupal version's 7 and 8 (I haven't checked others) contain a line in the default htaccess file that blocks hidden files and folders (beginning with a dot), this results in authentication attempts to the .well-known folder for the webroot authentication method. I was seeing unauthoized (403) failures when running letsencrypt-auto.
The specific line from the Drupal .htaccess is:
RewriteRule "(^|/)." - [F]
If I comment this line out I am able to complete the webroot authentication fine. I suspect there is an override to this possible. I like the additional security provided by this line (keeps people from poking around in my git repositories and protects htaccess itself, so I don't want to leave this line commented.
Curious if anyone has found a work around for this issue.
Found a possible solution. I created a new .htaccess file and placed it in the .well-known subdirectory containing:
#
# Override overly protective .htaccess in webroot
#
RewriteEngine On
Satisfy Any
With the above .htaccess rules in place webroot authentication works flawlessly. I'm unsure at this point if this opens up any possible security issues.
2 Likes
The Satisfy Any above may work in many cases, but it does require first creating the directory and getting the permissions correct. It’s not a silver bullet for all Apache + Drupal configurations.
For example, Apache servers using AllowOverride None and explicit Include(s) of .htaccess files in their Apache .conf files, for the performance benefit, would totally ignore the .well-known/.htaccess
Temporarily moving or renaming the Drupal .htaccess file, reloading Apache, running the letsencrypt client, moving Drupal .htaccess back, and reloading Apache again should always work. Albeit, if that is done on a production website the site would be broken for a brief period, so test first or run during a maintenance window.
Something like this should work on CentOS / RedHat 6 + Drupal 7 or 8 + Apache 2 stack
cd /{putYOURdirectoryhere}/public_html && mv .htaccess .htaccess.disabled && /etc/init.d/httpd reload && {put YOUR letsencrypt-auto command here} && mv .htaccess.disabled .htaccess && /etc/init.d/httpd reload
Then you may still need to install the SSL certificates manually if you’re not using an installer plugin, in which case you’d need to do another Apache reload after the certificates are installed.
If you add in your drupal .htaccess just above
RewriteRule “(^|/).” - [F]
the following rule:
RewriteRule “^.well-known/acme-challenge” - [L]
Then automated letsencrypt works on our cPanel install.
3 Likes
The problem with this method is that every time Drupal core updates it will overwrite your current .htaccess with the default, breaking your cert renewal process (which is hopefully scripted/automated).
True, but if you agree this works and letsencrypt becomes so popular as I guess, this might become part of drupal core.
And hopefully people will have a process to apply other .htaccess changes to a drupal core update, because it is quite normal that it can change. (.htaccess is not seen as part of the “do not ever hack core” system).
The upgrade process of drupal also mentions .htaccess as a file to give special care. (https://www.drupal.org/node/1223018)
Agree with catorghans comments about .htaccess for Drupal being special. I’ve always used a custom Drupal core upgrade script that prevents .htaccess being override. Do core updates using drush preserve the main .htaccess?
Allowing scripts to change the .htaccess file is pretty much the most annoying thing about Wordpress and it’s plugins. Luckily Drupal is much more aware of screwing with the .htaccess.
The Drupal community is working on a patch for this https://www.drupal.org/node/2408321
3 Likes