Seafile and LetsEncrypt 3.0.0

  • 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:

    1. 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***.deUsing the webroot path /var/www/virtual/LetsEncrypt for all unmatched domains.Waiting for verification...Cleaning up challengesFailed authorization procedure.***.de (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from***.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

    Edited once, last by Pimbo ().

  • My solution:

    1. ProxyPass "/.well-known/acme-challenge" "!"
    2. ProxyPass /seafhttp
    3. ProxyPassReverse /seafhttp
    4. RewriteRule ^/seafhttp - [QSA,L]

    is this a good solution?

  • @Pimbo

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

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

    This is almost the same thing.


  • 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

  • @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


  • 1. Yes


    1. <VirtualHost ***:80> ServerAdmin webmaster@cloud.***.de ServerName cloud.***.de ServerAlias***.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***.de retry=1 acquire=3$ ProxyPassReverse***.de </Location> Include /etc/apache2/imscp/cloud.***.de.conf</VirtualHost>

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

  • @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:

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

    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?



  • Sure :) Already a thank you for helping me.

  • 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.



  • @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.