Seafile and LetsEncrypt 3.0.0

**Pimbo** · Jan 4th 2017

IMSCP 1.3.14
Letsencrypt 2.0.5
Seafile 6.0.7
Debian Jessie 64 bit

I have a similar problem with my letsencrypt and seafile configuration:

HTML

Saving debug log to /var/log/letsencrypt/letsencrypt.logStarting new HTTPS connection (1): acme-v01.api.letsencrypt.orgObtaining a new certificatePerforming the following challenges:http-01 challenge for cloud.***.dehttp-01 challenge for www.cloud.***.deUsing the webroot path /var/www/virtual/LetsEncrypt for all unmatched domains.Waiting for verification...Cleaning up challengesFailed authorization procedure. www.cloud.***.de (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.cloud.***.de/.well-known/acme-challenge/KBCLDbx3AqlORK6h2zR5YEmAe8Pf__AdDrkfo7oz-hY: "<!DOCTYPE html><html lang="en"><head><title>Private Seafile</title><meta http-equiv="Content-type" content="text/html; ch", cloud.***.de (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://cloud.***.de/.well-known/acme-challenge/JZ6TEnIaXGlbAJtWT-3I1PGoPqUo38_cEn_DLIflKNg: "<!DOCTYPE html><html lang="en"><head><title>Private Seafile</title><meta http-equiv="Content-type" content="text/html; ch"

Apache CONF

Code

Alias /media /home/seafile/haiwen/seafile-server-latest/seahub/media
RewriteEngine On
<Location /media>
Require all granted
</Location>
#
# seafile fileserver
#
ProxyPass /seafhttp http://127.0.0.1:8082
ProxyPassReverse /seafhttp http://127.0.0.1:8082
RewriteRule ^/seafhttp - [QSA,L]
#
# seahub
#
SetEnvIf Request_URI . proxy-fcgi-pathinfo=unescape
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
ProxyPass / fcgi://127.0.0.1:8000/

Display More

**Pimbo** · Jan 4th 2017

My solution:

Code

ProxyPass "/.well-known/acme-challenge" "!"
ProxyPass /seafhttp http://127.0.0.1:8082
ProxyPassReverse /seafhttp http://127.0.0.1:8082
RewriteRule ^/seafhttp - [QSA,L]

is this a good solution?

**Nuxwin** · Jan 4th 2017

@Pimbo

This should works. For instance, we do the following for the PanelRedirect plugin

Code

ProxyErrorOverride Off
ProxyPassMatch ^/((?!\.well-known/acme-challenge/).*) http://<panel.hostname.tld>:8880/$1 retry=0 timeout=7200
ProxyPassReverse / http://<panel.hostname.tld>:8880/

This is almost the same thing.

**Pimbo** · Mar 29th 2017

Did anything change here? regarding to errata imscp included well known in every webfolder skeleton, domain alias, subdomain. I was using letsencrypt with the change in apache2 conf you can see above. Since the update to letsencrypt 3.0.0 and IMSCP 1.4.1 the browser are not automatically leading me to the https page, which itself works fine. HSTS is active

PHP 5.6-FPM
Debian 8

**Nuxwin** · Mar 29th 2017

@Pimbo

The .well-known directory has nothing to do with HSTS feature.

For the concerned domain, does the HSTS feature is enabled in SSL management page?
For the concerned domain, show us the vhost file which you can find at /etc/apache2/sites-available/<domain.tld>.conf

**Pimbo** · Mar 29th 2017

1. Yes

2.

Code

<VirtualHost ***:80> ServerAdmin webmaster@cloud.***.de ServerName cloud.***.de ServerAlias www.cloud.***.de vu2004.controlpanel.***.de DocumentRoot /var/www/virtual/cloud.***.de/htdocs DirectoryIndex index.html index.xhtml index.htm LogLevel error ErrorLog /var/log/apache2/cloud.***.de/error.log Alias /errors/ /var/www/virtual/cloud.***.de/errors/ <Directory /var/www/virtual/cloud.***.de/htdocs> AllowOverride AuthConfig Indexes Limit Options=Indexes \ Fileinfo=RewriteEngine,RewriteOptions,RewriteBase,RewriteCond,Rewri$ Require all granted </Directory> RedirectMatch 301 ^/((?!(?:errors|\.well-known)/).*) https://cloud.***.d$ <Location /stats> ProxyPreserveHost Off ProxyPass http://127.0.0.1:8889/stats/cloud.***.de retry=1 acquire=3$ ProxyPassReverse http://127.0.0.1:8889/stats/cloud.***.de </Location> Include /etc/apache2/imscp/cloud.***.de.conf</VirtualHost>

3. /apache2/imscp/cloud.***.conf

Code

# Custom Apache configuration for cloud.***.de
#
# Any changes made to this file will be preserved on update.
# i-MSCP doesn't check the contents of this file.
#
# This file should NOT be deleted.
Alias /media /home/seafile/haiwen/seafile-server-latest/seahub/media
RewriteEngine On
<Location /media>
Require all granted
</Location>
#
# seafile fileserver
#
ProxyPass /seafhttp http://127.0.0.1:8082
ProxyPassReverse /seafhttp http://127.0.0.1:8082
RewriteRule ^/seafhttp - [QSA,L]
#
# seahub
#
SetEnvIf Request_URI . proxy-fcgi-pathinfo=unescape
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
ProxyPass "/.well-known/acme-challenge" "!"
ProxyPass / fcgi://127.0.0.1:8000/

Display More

**Nuxwin** · Mar 29th 2017

@Pimbo

First of all, I'll not talk about your custom changes from the /apache2/imscp/cloud.***.conf file. That is not i-MSCP related.

Now in the vhost that is generated by i-MSCP, you can see:

Code

...
RedirectMatch 301 ^/((?!(?:errors|\.well-known)/).*) https://cloud.***.d$
...

That statement should redirect from http to https for first client connect and once done, HSTS header which is set in SSL vhost should do it job on client browser side.

Could you also post us the content of your /etc/apache2/sites-available/<domain.tld>_ssl.conf vhost file?

Thanks.

**Pimbo** · Mar 29th 2017

Sure Already a thank you for helping me.

Code

<VirtualHost ***:443>
ServerAdmin webmaster@cloud.***.de
ServerName cloud.***.de
ServerAlias www.cloud.***.de vu2004.controlpanel.***.de
DocumentRoot /var/www/virtual/cloud.***.de/htdocs
DirectoryIndex index.html index.xhtml index.htm
LogLevel error
ErrorLog /var/log/apache2/cloud.***.de/error.log
Alias /errors/ /var/www/virtual/cloud.***.de/errors/
SSLEngine On
SSLCertificateFile /var/www/imscp/gui/data/certs/cloud.***.de.pem
SSLCertificateChainFile /var/www/imscp/gui/data/certs/cloud.***.de.pem
Header always set Strict-Transport-Security "max-age=31536000"
SuexecUserGroup vu2004 vu2004
DirectoryIndex index.php
<Proxy "unix:/run/php/php5.6-fpm-cloud.***.de.sock|fcgi://cloud.***.de" retry=0>
ProxySet connectiontimeout=5 timeout=7200
</Proxy>
<Directory /var/www/virtual/cloud.***.de>
Options +SymLinksIfOwnerMatch
Require all granted
</Directory>
<Directory /var/www/virtual/cloud.***.de/htdocs>
AllowOverride All
<If "%{REQUEST_FILENAME} =~ /\.ph(?:p[3457]?|t|tml)$/ && -f %{REQUEST_FILENAME}">
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
SetHandler proxy:fcgi://cloud.***.de
</If>
</Directory>
Alias /cgi-bin/ /var/www/virtual/cloud.***.de/cgi-bin/
<Directory /var/www/virtual/cloud.***.de/cgi-bin>
AllowOverride AuthConfig Indexes Limit Options=Indexes
DirectoryIndex index.cgi index.pl index.py index.rb
Options +ExecCGI -MultiViews
AddHandler cgi-script .cgi .pl .py .rb
</Directory>
<Location /stats>
ProxyPreserveHost Off
ProxyPass http://127.0.0.1:8889/stats/cloud.***.de retry=1 acquire=3000 timeout$
ProxyPassReverse http://127.0.0.1:8889/stats/cloud.***.de
</Location>
Include /etc/apache2/imscp/cloud.***.de.conf
</VirtualHost>

Display More

**Nuxwin** · Mar 29th 2017

Quote from Pimbo

Header always set Strict-Transport-Security "max-age=31536000"

The HSTS header is present as expected. So, from configuration point of view, there are no bugs. Please, could you give me the domain name privately? Then, I could test from my browser.

Thanks.

**Nuxwin** · Mar 29th 2017

@Pimbo

With your domain, the RedirectMatch directive don't do its job but once we have connected to https directly, the HSTS header do it job (on subsequent connect to http, we are automatically redirected to https version by the browser).

It seem that the ProxyPass directive takes precedence over the RedirectMatch directive. I'll perform some tests.

Seafile and LetsEncrypt 3.0.0

Share

Daily visitors