Problem using webroot on redirected non-www website

I've three domains running. Every domain redirects to it's non-www https-site. Now I want to set up a mailserver and so I tried:

./letsencrypt-auto certonly --webroot -w /var/www/domain.com/public_html -d www.domain.com -d domain.com -w /var/www/mysite.net/public_html -d www.mysite.net -d mysite.net -w /var/www/nicepage.org/public_html -d www.nicepage.org -d nicepage.org

but all I get is this error for each domain (www and non-www):

Domain: mysite.net
Type: connection
Detail: Could not connect to http://domain.com/.well-known/acme-challenge/53K6nhTF2Cn-yYaDv7seAsKSG5yOP0aLMG9-uHXOIuo

The DNS is configured correctly and my Apache should handle hidden directories (./foobar) as well. So, before I change s.th.: Might this error occur because of this permanent redirection to non-www https or is there another problem?

Redirection shouldn’t result in this kind of error as far as I know.

Just found this comment of user bmw. https://github.com/letsencrypt/letsencrypt/issues/2150#issuecomment-170989343

So, it’s not possible to use --webroot on HTTPS-only sites? And what should I do now? can I use the standalone-command to get one cert for every domain?

Your site isn’t HTTPS-only. In that ticket, there’s no server listening on port 80. Yours is. It’s just redirecting to HTTPS, which is another scenario and should be supported.

Okay, then maybe Apache isn’t allowed to serve hidden directories/files. Will try to troubleshoot this. If you know, how I easily can check this, I would appriciate this.

“Could not connect to” suggests Boulder can’t connect to the IP on port 80 entirely… Make 100% sure your server is connectable from the outside world.

If you’d post (or private message) the hostname(s) of the server, it’s easier to debug the problem.

It definitely is. Just pinged it and visited with diffrerent browsers to prevent cache-issues. If I visit http://www.domain.com it redirects me to https://domain.com. Tried it with every domain, but as it’s the same server/IP it works of course, too.

Okay, it seems there is s.th. wrong with my rewrite-engine-code. I created a hidden folder and copied a picture into it (http://www.domain.com/.test/picture.png). If I try to visit the picture with my browser it redirects me to https://domain.com.test/picture.png. Here are my .conf files for Apache2:

domain.com.conf

<VirtualHost *:80>
ServerName domain.com
ServerAlias www.domain.com
ServerAdmin contact@domain.com
DocumentRoot /var/www/domain.com/public_html
Redirect permanent / https://domain.com

<Directory /var/www/domain.com/public_html>
Options FollowSymLinks
AllowOverride all
Require all granted
</Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

domain.com-le-ssl.conf

LoadModule headers_module modules/mod_headers.so

<IfModule mod_ssl.c>
<VirtualHost *:443>
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always append X-Frame-Options DENY
Header always set X-Xss-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header set Content-Security-Policy "default-src 'self'; frame-src 'self' https://youtube.com/ https://www.youtube.com/; ch$

ServerName domain.com
ServerAlias www.domain.com
ServerAdmin contact@domain.com
DocumentRoot /var/www/domain.com/public_html

<Directory /var/www/domain.com/public_html>
Options FollowSymLinks
AllowOverride all
Require all granted

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^\w+$ index.php?page=$0 [L]
RewriteCond %{THE_REQUEST} index\.php
RewriteCond %{QUERY_STRING} ^page=(\w+)$
RewriteRule ^index\.php$ /%1? [R=301,L]

</Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

RewriteEngine on
SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]
</VirtualHost>
</IfModule>

Well, you’ve already answered your own question, right? :slight_smile:

Redirect directive

1 Like

But I’ve no idea how to fix it, because I’m a total noob on this rewrite-thing. I asked others for this special stuff. It’s like chinese to me and I live far away from China. :wink:

I can see one very clear difference between both URL's in your post above. I can also read very clear many parts about the thingy that is different between the two URL's in the documentation I provided earlier..

No, I'm not going to tell you exactly what it is, you should be able to find out yourself :wink:

OK OK, fair enough, the problem isn't really literally mentioned in the documentation. Another tip: the thingy you "search" for in your Redirect (first argument) should match every "thingy" in the second argument (i.e.: destination) and that's not matching in your configuration right now.

1 Like

The slash at the end is the solution? It’s working now… but that’s all?

domain.com.conf

Redirect permanent / https://domain.com/

That was it. :wink:  

The directive takes the whole path from the original request, strips the first argument of the Redirect directive and replaces that argument with whatever you’ve put behind it. By not adding the slash to your second argument, you’re replacing the single slash with a value without it.

1 Like

Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/domain.com/fullchain.pem

Am I right, that this way I can use the certificate for as many domains as I want? I only have to add the domains and fire up the command (see below) again?

./letsencrypt-auto certonly --webroot -w 
/var/www/domain.com/public_html -d www.domain.com -d domain.com -w 
/var/www/mysite.net/public_html -d www.mysite.net -d mysite.net -w 
/var/www/nicepage.org/public_html -d www.nicepage.org -d nicepage.org

Thanks! :wink:

Yes, you can.

But if you’re still in your testing phase, you should watch out for the rate limits. When testing, use the --staging option. This will do all the normal stuff, but generate a non-trusted certificate. Once everything is in order, you should only once remove the --staging switch for the real deal.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.