This is a 7.x backport of the parent issue.

Drupal should support RFC 5785, which establishes a .well-known URI location: https://tools.ietf.org/html/rfc5785

These URIs are registered with IANA: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

This patch whitelists the .well-known directory in Drupal's .htaccess directive which blocks access to all hidden directories.

Nginx users can allow the .well-known directory like this (above the general line to block hidden directories and other stuff):

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

sammuell created an issue. See original summary.

sammuell’s picture

Here's a 7.x patch including tests.

sammuell’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 2: htaccess-2847325-7.x.patch, failed testing.

sammuell’s picture

Hmm, the patch works locally. It seems to be an issue with the automated testing clients. Anyone has an idea?

John Morahan’s picture

Well, if the ownership and permissions are correctly configured (which I assume they are on the testing clients) they won't have write access to drupal_mkdir(DRUPAL_ROOT . '/.well-known'); so that won't work.

sammuell’s picture

Status: Needs work » Needs review
FileSize
1.16 KB

Too bad, in that case there won't be any automated tests. Here's the parent issue's patch without the tests.

John Morahan’s picture

Status: Needs review » Reviewed & tested by the community

The patch makes the same changes to .htaccess as the combined two D8 patches from the parent issue.

The regular expressions are the same as the ones that were already reviewed on the parent issue. I reviewed them again and they still look correct.

I repeated the tests that I ran locally on the parent issue, with the same successful results:

# patch -p1 < htaccess-no-tests-2847325-7.x.patch
patching file .htaccess
# check() { curl -I "http://localhost$1" 2>/dev/null | head -n 1; }
# check /
HTTP/1.1 200 OK
# check /.well-known
HTTP/1.1 403 Forbidden
# check /.well-known-not
HTTP/1.1 403 Forbidden
# mkdir -p .well-known/acme-challenge
# echo test > .well-known/acme-challenge/test
# check /.well-known/acme-challenge/test
HTTP/1.1 200 OK
# mkdir -p .well-known-not/acme-challenge
# echo test > .well-known-not/acme-challenge/test
# check /.well-known-not/acme-challenge/test
HTTP/1.1 403 Forbidden
# echo test > .some-other-name
# check /.some-other-name
HTTP/1.1 403 Forbidden

There's a separate issue #2699701: Testing RFC 5785 Support to add tests for this in D8, so I guess that would be backported separately when it's done...?

DamienMcKenna’s picture

I can confirm this helped me get the letsencrypt system working on a site.

mrconnerton’s picture

I can also confirm this worked for me + letsencrypt.

xmacinfo’s picture

I believe it's time to commit this patch.

Drupal 7 should support Let's Encrypt out of the box too.

stefan.r’s picture

Issue tags: +Drupal bugfix target
sammuell’s picture

Is there any other step missing except of the actual commit to core?

jeffschuler’s picture

This allowed me to get LetsEncrypt/Certbot working. Thank you!

stefan.r’s picture

We're aiming to get this into next week's release.

David_Rothstein’s picture

Title: [D7] Support RFC 5785 by whitelisting the .well-known directory » [D7] Support RFC 5785 on Apache by whitelisting the .well-known directory
Status: Reviewed & tested by the community » Fixed
Issue tags: +7.55 release notes

Committed to 7.x - thanks!

I added a note about this to CHANGELOG.txt. Not sure if we want a change notice also? - there is one that was written for Drupal 8 at https://www.drupal.org/node/2661732 but it was never published because it has some problems.

As far as I can see, we're still blocking this for IIS servers in web.config, but it seems fine to fix it for Apache first. We should have a followup issue for IIS.

  • David_Rothstein committed f73b791 on 7.x
    Issue #2847325 by sammuell, John Morahan, mfb, sanduhrs, D34dMan,...
David_Rothstein’s picture

Eh, I was going to file an issue about IIS, but the web.config file is pretty different for Drupal 7 and Drupal 8 and I'm not even sure if it's being blocked there or not... so I'll leave that for someone else to do if it turns out to be an issue after all.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.