The documentation indicates that /.well-known/acme-challenge/ should remain accessible via HTTP, without forced redirection to HTTPS:

Test the challenge directory

Create a file e.g. called index.html in /var/aegir/config/letsencrypt.d/well-known/acme-challenge/ and test if you can access it over http via http://www.example.com/.well-known/acme-challenge/index.html

If your request is redirected to a https url then that could pose a problem when the certificate there is either invalid or expired. Try to remove the redirects.

At the moment, if for a site "my.site.com" we choose HTTPS Required (which seems to be generally a sensible choice), then ALL http requests get rewritten to https through the following mod_rewrite block in the site's apache config:

$ cat /var/aegir/config/server_master/apache/vhost.d/my.site.com
[...]
 # Redirect aliases in non-ssl to the same alias on ssl.
 RewriteRule ^/*(.*)$ https://%{HTTP_HOST}/$1 [NE,L,R=301]
[...]

Would that make sense to exclude /.well-known/acme-challenge to that rewrite so that we can safely choose HTTPS Required with Let's Encrypt?

I have tried the following configuration which seemed to do it:

$ cat /var/aegir/config/server_master/apache/vhost.d/my.site.com
[...]
  # Redirect aliases in non-ssl to the same alias on ssl, except for /.well-known/acme-challenge/ URIs
 RewriteCond %{REQUEST_URI} "!/.well-known/acme-challenge/"
 RewriteRule ^/*(.*)$ https://%{HTTP_HOST}/$1 [NE,L,R=301]
[...]

I looked for the piece of code that inserted that block in the configuration, to test it further and suggest a patch, but I could not find it anywhere.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

antoine.guichard created an issue. See original summary.

helmo’s picture

That's in the http/Provision/Config/Apache/vhost.tpl.php file in the provision repo. It's included from submodules/apache_https/drush/Provision/Config/Apache/Https/vhost_https.tpl.php in the hosting_https repo.

Are you seeing errors from this? As far as I know redirecting is os as long as it's on the same hostname.

agaq’s picture

I have not yet seen errors on this.

The documentation says that redirecting /.well-known/acme-challenge/index.html from http to https causes problem, so I just wanted to make using the safest configuration "HTTPS required" less prone to potential problems.

It does not seem to be in submodules/apache_https/drush/Provision/Config/Apache/Https/vhost_https.tpl.php though.

Setting a site to "HTTPS required" inserts in the site config the two lines

# Redirect aliases in non-ssl to the same alias on ssl.
 RewriteRule ^/*(.*)$ https://%{HTTP_HOST}/$1 [NE,L,R=301]

While what we have in vhost_https.tpl.php shows a different comment line:

if ($this->redirection) {
  print " # Redirect all aliases to the selected alias.\n";
  print " # RewriteRule ^/*(.*)$ https://{$this->redirection}/$1 [NE,L,R=301]\n";
}

I have searched for the text "non-ssl" in scripts but could not find any occurrence.

agaq’s picture

Status: Active » Needs review
FileSize
735 bytes

I am a bit slow but I finally figured out I had to look at provision, not hosting_https...

Here is a proposed patch.

But I don't know how to transfer that issue from hosting_https to provision.

helmo’s picture

Project: Aegir HTTPS » Provision

moving... looks good at first glance.

helmo’s picture

I havn't yet fully verified it, but it seems to me that the same RewriteCond would also be needed in two other places.

memtkmcc’s picture

Note that we have fixed this problem in BOA (which still depends on legacy `hosting_le` project), a long time ago, and this code is present in Provision both in plain HTTP and HTTPS vhosts templates, where we are conditionally adding BOA specific location alias just before any redirect is triggered, like this:

    if ($satellite_mode == 'boa') {
      print "\n";
      print "  ###\n";
      print "  ### Allow access to letsencrypt.org ACME challenges directory.\n";
      print "  ###\n";
      print "  location ^~ /.well-known/acme-challenge {\n";
      print "    alias {$aegir_root}/tools/le/.acme-challenges;\n";
      print "    try_files \$uri 404;\n";
      print "  }\n";
      print "\n";
    }
    print "  return 301 \$scheme://{$this->redirection}\$request_uri;\n";

This could be easily extended for non-BOA Nginx based Aegir with simple `else {}` alternative, I guess?

helmo’s picture

I'm leaning towards rtbc here ... but it would be nice to have a matching nginx patch.

memtkmcc’s picture

Trying to figure out how to replicate the same logic in Nginx without creating duplicate location here, since simple conversion from RewriteCond to if {} in Nginx is not really the best idea, but perhaps the only actually working.

helmo’s picture

Status: Needs review » Reviewed & tested by the community

It might be better to focus on matching nginx support in a separate issue... rtbc

helmo’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
1.8 KB

In #2975116: Disabled Sites are reachable via SSL but not renewable valkum mentions that we also need to look at disabled sites.

Here's an updated provision patch.

  • helmo committed 6c9b940 on 7.x-3.x
    Issue #2952366 by helmo, antoine.guichard, memtkmcc: Exclude /.well-...
helmo’s picture

Status: Needs review » Fixed

I've nog committed #11 and the hosting_https patch from #6

Status: Fixed » Closed (fixed)

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