# Letsencrypt certificate renewal fails with well hardend Nextcloud 15.04 server **URL:** \ **Category:** ℹ️ Support\ **Tags:** nc15, letsencrypt\ **Created:** [February 9, 2019, 10:37pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268 "2019-02-09T22:37:22Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 9, 2019, 10:37pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/1 "2019-02-09T22:37:22Z")
Hi there, I would appreciate your assistance in getting certbot renew my Letsencrypt certificate again. I have the impression that hardening my Nextcloud server went a bit too far or I went in the wrong direction for the new requirements Let’s Encrypt imposes. > **[How to stop using TLS-SNI-01 with Certbot](https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210)** > > Let's Encrypt is removing support for domain validation with TLS-SNI-01. If you're using Certbot and received an email titled "Action required: Let’s Encrypt certificate renewals" or are getting the error message: Client with the currently... > If you get a connection refused or connection timeout, you may have a firewall blocking port 80. tls-sni-01 used port 443, but http-01 uses port 80. Ideally your web server should allow both ports. They removed the default validation method (TLS-SNI-01) I seem to have been using, and now I am lost. Nextcloud 15.04 Fedora 29 Apache 2.4.38 PHP 7.2.14 certbot 0.30.2 ``` # apachectl status Feb 09 22:14:06 wind httpd[32464]: Server configured, listening on: port 443, port 80 certbot renew --dry-run Saving debug log to /var/log/letsencrypt/letsencrypt.log Processing /etc/letsencrypt/renewal/my.domain.tld.conf Cert is due for renewal, auto-renewing... Plugins selected: Authenticator apache, Installer apache Renewing an existing certificate Performing the following challenges: http-01 challenge for my.domain.tld Waiting for verification... Cleaning up challenges 'Attempting to renew cert (my.domain.tld) from /etc/letsencrypt/renewal/my.domain.tld.conf produced an unexpected error: Failed authorization procedure. my.domain.tld (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://my.domain.tld/.well-known/acme-challenge/ PfmI5ZQxPjdVdL1EvRGyp9tnpsXhgeQe-2fyRBy8P4g: Error getting validation data. Skipping.' All renewal attempts failed. [...] ``` **I would like to stay with certbot and simply adapt my server settings.** The server is at home behind a FritzBox router with a dynds my.domain.tld pointing to it, and I have root access to it, so all freedom to improve. But WHAT? Any help is appreciated. ---
**Author:** ![rakekniven](https://help.nextcloud.com/user_avatar/help.nextcloud.com/rakekniven/32/67096_2.png) [@rakekniven](https://help.nextcloud.com/u/rakekniven)\ **Post date:** [February 9, 2019, 10:43pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/2 "2019-02-09T22:43:04Z")
Do you have port 80 forwarded as well? ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 9:45am UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/3 "2019-02-10T09:45:56Z")
In the area of webservers I am really a beginner, sorry. Let me try to answer anyhow: If your suggestion targets to the ports in the router: My Fritzbox now is 1:1 mapping 22 to 22, 80 to 80 and 443 to 443, all to the local IP of my server, see here: ![2019_02_10_Fritzbox_Portfreigaben](https://help.nextcloud.com/uploads/default/original/2X/8/8433cca6da9898c7a1f631f0ebfbf87e367454e8.png) In terms of VirtualHost I tried 2 Alternatives without success, both (one only active at a time) placed in ``` /etc/httpd/conf.d/http_my.conf ``` # Alternative 1 (direct) \< currently active ``` ServerAdmin webmaster@my.domain.tld DocumentRoot "/var/www/nextcloud" ServerName my.domain.tld ErrorLog logs/http_error_log CustomLog logs/http_access_log common ``` # Alternative 2 (redirect) \< currently commented with # ``` ServerAdmin webmaster@localhost Redirect permanent / https://my.domain.tld/ ErrorLog logs/http_error_log CustomLog logs/http_access_log combined ``` Alternative 2 was recommended to me here: > [@What is the target NC12 configuration for strict https only?](https://help.nextcloud.com/t/what-is-the-target-nc12-configuration-for-strict-https-only/18463): > > Hi, I am trying to set up the correct Apache2 config for strict https access only and strict http transport security only as recommended here: [https://docs.nextcloud.com/server/12/admin\_manual/configuration\_server/harden\_server.html#enable-http-strict-transport-security](https://docs.nextcloud.com/server/12/admin_manual/configuration_server/harden_server.html#enable-http-strict-transport-security) Where I am stuck is: Which of the files 000-default.conf, default-ssl.conf and nextcloud.conf do I need to keep enabled? What should be their content? The server is up and running in my home network and I made it temporaril… I would prefer Alternative 2, but I fear that Letsencrypt might have problems with ending up with a http **s** , that’s why I tried with Alternative 1. Even without http\_my.conf [http://my.domain.tld](http://my.domain.tld) ends up in http **s** ://my.domain.tld in the browser. This is perfectly fine for Nextcloud - but for Letsencrypt / certbot ??? I’m confused … ---
**Author:** ![rakekniven](https://help.nextcloud.com/user_avatar/help.nextcloud.com/rakekniven/32/67096_2.png) [@rakekniven](https://help.nextcloud.com/u/rakekniven)\ **Post date:** [February 10, 2019, 11:06am UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/4 "2019-02-10T11:06:09Z")
Ok, you forwarded http (port 80) as well. Sounds good for me. Have no idea why it fails right now. ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 11:25am UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/5 "2019-02-10T11:25:26Z")
I just checked with [https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/) and I get an A+ 🙂 All https tests worked fine. However in the summary section it says: HTTP request to this server failed, see below for details. And below in the Miscellaneous section it says: Test date: Sun, 10 Feb 2019 11:09:57 UTC, Test duration: 147.941 seconds HTTP status code: Request failed **(Too many Redirection)** Maybe this is an entry point? ---
**Author:** ![MichaIng](https://help.nextcloud.com/user_avatar/help.nextcloud.com/michaing/32/2125_2.png) [@MichaIng](https://help.nextcloud.com/u/MichaIng)\ **Post date:** [February 10, 2019, 11:34am UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/6 "2019-02-10T11:34:28Z")
Generally the HTTPS redirection (alternative 2) should work well work certbot, it does in my case. Of course this means that in browser you will always end up with a HTTPS connection, which is the intention. > [@ubuntiger](#): > > Even without http\_my.conf [http://my.domain.tld](http://my.domain.tld) ends up in http **s** ://my.domain.tld in the browser. Do your have HSTS enabled in your \*443 vhost (config)? In this case browsers remember that they should always connect via HTTPS to your domain. Is your Nextcloud located in your webservers webroot, so accessible via the domain directly instead your.domain.tld/nextcloud and is the use of .htaccess files (AllowOverride All) enabled in your \*443 or Nextcloud specific vhost? AFAIK in case of Nextcloud being webroot you need a specific rewrite rule to directly forward the acme challenge certbot attempts. ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 12:20pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/7 "2019-02-10T12:20:29Z")
> [@MichaIng](#): > > Generally the HTTPS redirection (alternative 2) should work well work certbot, it does in my case. Of course this means that in browser you will always end up with a HTTPS connection, which is the intention. Exactly, to always end up in an HTTPS connection is my intention. I just switched to Alternative 2 due to your suggestion. > [@MichaIng](#): > > Do your have HSTS enabled in your \*443 vhost (config)? In this case browsers remember that they should always connect via HTTPS to your domain. I do not think so. At least I did not find the string “HSTS” in any of my files in /etc/httpd/conf.d/ > [@MichaIng](#): > > Is your Nextcloud located in your webservers webroot, so accessible via the domain directly instead your.domain.tld/nextcloud Yes. It is /var/www/nextcloud/, see also ssl.conf below. The directory of the initial setup of apache on Fedora was /var/www/html, but this is empty now. > [@MichaIng](#): > > and is the use of .htaccess files (AllowOverride All) enabled in your \*443 or Nextcloud specific vhost? I could not find any AllowOverride in my ssl.conf: > **ssl.conf** > > ``` > Listen 443 https > SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog > SSLSessionCache shmcb:/run/httpd/sslcache(512000) > SSLSessionCacheTimeout 300 > SSLRandomSeed startup file:/dev/urandom 256 > SSLRandomSeed connect builtin > SSLCryptoDevice builtin > > DocumentRoot "/var/www/nextcloud" > ServerName my.domain.tld:443 > ServerAlias 192.168.67.xx wind wind.fritz.box > ErrorLog logs/ssl_error_log > TransferLog logs/ssl_access_log > LogLevel warn > SSLEngine on > SSLProtocol all -SSLv3 > SSLProxyProtocol all -SSLv3 > SSLHonorCipherOrder on > SSLCipherSuite PROFILE=SYSTEM > SSLProxyCipherSuite PROFILE=SYSTEM > > SSLOptions +StdEnvVars > > > SSLOptions +StdEnvVars > > BrowserMatch "MSIE [2-5]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 > CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" > > ServerAlias my.domain.tld > Include /etc/letsencrypt/options-ssl-apache.conf > SSLCertificateFile /etc/letsencrypt/live/my.domain.tld/fullchain.pem > SSLCertificateKeyFile /etc/letsencrypt/live/my.domain.tld/privkey.pem > > > ``` but there is one in my nextcloud.conf: > **nextcloud.conf** > > ``` > Alias /nextcloud "/var/www/nextcloud/" > > Options +FollowSymlinks > AllowOverride All > > Dav off > > SetEnv HOME /var/www/nextcloud > SetEnv HTTP_HOME /var/www/nextcloud > > > ``` > [@MichaIng](#): > > AFAIK in case of Nextcloud being webroot you need a specific rewrite rule to directly forward the acme challenge certbot attempts. Sounds like a good idea to continue with. How would I do that? ---
**Author:** ![MichaIng](https://help.nextcloud.com/user_avatar/help.nextcloud.com/michaing/32/2125_2.png) [@MichaIng](https://help.nextcloud.com/u/MichaIng)\ **Post date:** [February 10, 2019, 1:33pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/8 "2019-02-10T13:33:41Z")
> [@ubuntiger](#): > > I do not think so. At least I did not find the string “HSTS” in any of my files in /etc/httpd/conf.d/ The directive should look something like this: `Header always set Strict-Transport-Security “max-age=31536000; includeSubDomains”` HSTS is the abbreviation for HTTP Strict Transport Security 😉. Above I see you set `DocumentRoot "/var/www/nextcloud"`, so Nextcloud is indeed in your webroot. Actually then `Alias /nextcloud "/var/www/nextcloud/"` in your `nextcloud.conf` does not make much sense. Your method web UI should then be available on `you.domain.tld` as well as on `you.domain.tld/nextcloud` which is most properly not desired? Okay let me check for possibly required acme rewrite rules then. Will check the next hour when I am home. ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 2:16pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/9 "2019-02-10T14:16:32Z")
> [@MichaIng](#): > > The directive should look something like this: > `Header always set Strict-Transport-Security “max-age=31536000; includeSubDomains”` > HSTS is the abbreviation for HTTP Strict Transport Security 😉. I guess that thanks to your help I am about to understand now what I did years ago when I was simply following the Nextcloud cookbook 😉. Indeed I placed a HSTS line into my httpd.conf manually, see here for details: > **/etc/httpd/conf/httpd.conf** > > ``` > ServerRoot "/etc/httpd" > Listen 80 > Include conf.modules.d/*.conf > User apache > Group apache > ServerAdmin my@email.address.de > > ServerName my.domain.tld:80 > > > AllowOverride none > Require all denied > > > DocumentRoot "/var/www/html" > > > AllowOverride None > Require all granted > > > > Options Indexes FollowSymLinks > AllowOverride None > Require all granted > > > > DirectoryIndex index.html > > > > Require all denied > > > ErrorLog "logs/error_log" > > LogLevel warn > > > LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined > LogFormat "%h %l %u %t \"%r\" %>s %b" common > > LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio > > CustomLog "logs/access_log" combined > > > > ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" > > > > AllowOverride None > Options None > Require all granted > > > > TypesConfig /etc/mime.types > AddType application/x-compress .Z > AddType application/x-gzip .gz .tgz > AddType text/html .shtml > AddOutputFilter INCLUDES .shtml > > AddDefaultCharset UTF-8 > > > MIMEMagicFile conf/magic > > > EnableSendfile on > > IncludeOptional conf.d/*.conf > # Extension by me according to Nextcloud Admin Manual > > Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" > > > ``` With my better feeling (to not use understanding…) I guess the following content of httpd.conf does not make sense any more either!? What do you suggest? Replace ``` DocumentRoot "/var/www/html" ``` by ``` DocumentRoot "/var/www/nextcloud" ``` ? Remove the following completely? Or just modify - to what? ``` AllowOverride None Require all granted Options Indexes FollowSymLinks AllowOverride None Require all granted ``` Could this be an obstacle for Letsencrypt / certbot? > [@MichaIng](#): > > Actually then `Alias /nextcloud "/var/www/nextcloud/"` in your `nextcloud.conf` does not make much sense. Your method web UI should then be available on `you.domain.tld` as well as on `you.domain.tld/nextcloud` which is most properly not desired? Now that you point it out, I simply removed the entire line with the Alias. Understanding things a little bit better, it really does not make sense. I will be back in about an hour or two, need some fresh air with the family now. ---
**Author:** ![MichaIng](https://help.nextcloud.com/user_avatar/help.nextcloud.com/michaing/32/2125_2.png) [@MichaIng](https://help.nextcloud.com/u/MichaIng)\ **Post date:** [February 10, 2019, 3:11pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/10 "2019-02-10T15:11:17Z")
Hehe posting/editing in parallel. Okay I have to understand the Apache folder/config structure on Fedora, I think I got it mostly 😉. So `/etc/httpd/conf/httpd.conf` is the main config, including all the other vhosts and configs from `/etc/httpd/conf.d/`. Please verify: - `/etc/httpd/conf.d/` contains - `http_my.conf` the default vhost answering port 80 (default HTTP) requests - `ssl.conf` the vhost answering port 443 (default HTTPS) requests - `nextcloud.conf` the Nextcloud specific config file. - and nothing else? - To be failsafe assure as well the required Apache module is enabled: - `a2enmod rewrite` (Debian-specific) Some of the directives are indeed inconsistent/doubled and possibly conflicting, although the vhost settings are applied last so override the ones from `/etc/httpd/conf/httpd.conf`. But just to clean it up a bid you could do: _ **NB: I assume now you really only need Nextcloud access on this webserver and no other website possibly located on another directory and/or accessible via another port, which would be generally possible.** _ - Set `DocumentRoot "/var/www/nextcloud"` or remove it. It has no effect, as long as the final `ssl.conf` (everything should be redirected to) contains this correctly. - Set `ServerName my.domain.tld` (without port) once here and remove those from `http_my.conf` and `ssl.conf`. So there is an identical webserver wide server name, matching the external domain name. - Also all the `ServerAlias` directives should be not required (in all configuration files). Not sure about the use of them actually, possibly they can be used as hostnames then locally, but as long as you always connect to the webserver via `my.domain.tld`, it’s local network IP or hostname (given by the NAT/router), everything will work without Aliases. - Although this should be default, to be failsafe add `AccessFileName .htaccess` before the line ``. - The other `` directives are fine, in cases obsolete but apply reasonable default rules. Just leave them as they are. - Move - To apply all changes do: `service httpd restart` Now according to the Nextcloud internal config, assure: - Your `/var/www/nextcloud/config/config.php` contains: `'htaccess.RewriteBase' => '/',` - To apply this to `/var/www/nextcloud/.htaccess` , do: `sudo -u apache php /var/www/nextcloud/occ maintenance:update:htaccess` - `/var/www/nextcloud/.htaccess` should now contain the required rule, respectively the exclusion for rewriting other requests requests, to handle cerbot challenges correctly: `RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*` > [@ubuntiger](#): > > HTTP status code: Request failed **(Too many Redirection)** That must be the issue (didn’t see this post when I answered first 😉) , although currently not sure about the whole redirection path. Lets see if with `httpd.conf` and `ServerName`/`ServerAlias` cleanup this is resolved. * * * One last question: - You use `mod_php`, right? So there is no `php-fpm` process that Apache uses to handle PHP scripts? ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 5:21pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/11 "2019-02-10T17:21:21Z")
Thanks for all your support, MichaIng! Let me answer in parts. This is “Part 1” > [@MichaIng](#): > > `/etc/httpd/conf.d/` contains the files you mentioned, all correct, plus some more. Here is the total: > **Recursive listing of /etc/httpd** > > ``` > [root@wind /etc/httpd]# ls -laFR > .: > insgesamt 28 > drwxr-xr-x. 5 root root 4096 10. Feb 10:56 ./ > drwxr-xr-x. 167 root root 12288 10. Feb 10:54 ../ > drwxr-xr-x. 2 root root 4096 10. Feb 17:53 conf/ > drwxr-xr-x. 2 root root 4096 10. Feb 17:52 conf.d/ > drwxr-xr-x. 2 root root 4096 26. Jan 10:50 conf.modules.d/ > lrwxrwxrwx. 1 root root 19 23. Jan 13:40 logs -> ../../var/log/httpd/ > lrwxrwxrwx. 1 root root 29 23. Jan 13:40 modules -> ../../usr/lib64/httpd/modules/ > lrwxrwxrwx. 1 root root 10 23. Jan 13:40 run -> /run/httpd/ > lrwxrwxrwx. 1 root root 19 23. Jan 13:40 state -> ../../var/lib/httpd/ > > ./conf: > insgesamt 36 > drwxr-xr-x. 2 root root 4096 10. Feb 17:53 ./ > drwxr-xr-x. 5 root root 4096 10. Feb 10:56 ../ > -rw-r--r--. 1 root root 11983 9. Feb 18:30 httpd.conf > -rw-r--r--. 1 root root 13077 23. Jan 13:40 magic > > ./conf.d: > insgesamt 64 > drwxr-xr-x. 2 root root 4096 10. Feb 17:52 ./ > drwxr-xr-x. 5 root root 4096 10. Feb 10:56 ../ > -rw-r--r--. 1 root root 2893 23. Jan 13:40 autoindex.conf > -rw-r--r--. 1 root root 1537 10. Feb 10:51 http_my.conf > -rw-r--r--. 1 root root 344 23. Jan 13:37 manual.conf > -rw-r--r--. 1 root root 211 10. Feb 15:04 nextcloud.conf > -rw-r--r--. 1 root root 1752 29. Aug 13:36 perl.conf > -rw-r--r--. 1 root root 1618 8. Jan 15:24 php.conf > -rw-r--r--. 1 root root 400 23. Jan 13:40 README > -rw-r--r--. 1 root root 298 11. Dez 11:35 squid.conf > -rw-r--r--. 1 root root 9807 21. Mär 2018 ssl.conf > -rw-r--r--. 1 root root 1252 23. Jan 13:37 userdir.conf > -rw-r--r--. 1 root root 302 15. Jul 2018 webalizer.conf > -rw-r--r--. 1 root root 516 23. Jan 13:37 welcome.conf > > ./conf.modules.d: > insgesamt 64 > drwxr-xr-x. 2 root root 4096 26. Jan 10:50 ./ > drwxr-xr-x. 5 root root 4096 10. Feb 10:56 ../ > -rw-r--r--. 1 root root 3311 23. Jan 13:37 00-base.conf > -rw-r--r--. 1 root root 139 23. Jan 13:37 00-dav.conf > -rw-r--r--. 1 root root 41 23. Jan 13:37 00-lua.conf > -rw-r--r--. 1 root root 951 23. Jan 13:37 00-mpm.conf > -rw-r--r--. 1 root root 787 23. Jan 13:37 00-optional.conf > -rw-r--r--. 1 root root 1073 23. Jan 13:37 00-proxy.conf > -rw-r--r--. 1 root root 41 23. Jan 13:37 00-ssl.conf > -rw-r--r--. 1 root root 88 23. Jan 13:37 00-systemd.conf > -rw-r--r--. 1 root root 451 23. Jan 13:37 01-cgi.conf > -rw-r--r--. 1 root root 448 29. Aug 13:36 02-perl.conf > -rw-r--r--. 1 root root 45 9. Okt 14:31 10-h2.conf > -rw-r--r--. 1 root root 57 9. Okt 14:31 10-proxy_h2.conf > -rw-r--r--. 1 root root 480 8. Jan 15:24 15-php.conf > -rw-r--r--. 1 root root 496 23. Jan 13:40 README > > ``` > [@MichaIng](#): > > To be failsafe assure as well the required PHP module is enabled: > > - `phpenmod rewrite` No, as it seems. I cannot find phpenmod in Fedora, but ``` php -m | grep -i rewrite ``` gives zero results. The other modules are: > **php-Modules** > > # php -m > [PHP Modules] > apcu > bz2 > calendar > Core > ctype > curl > date > dom > exif > fileinfo > filter > ftp > gd > gettext > gmp > hash > iconv > igbinary > imagick > imap > intl > json > ldap > libsmbclient > libxml > mbstring > mcrypt > memcached > msgpack > mysqli > mysqlnd > openssl > pcntl > pcre > PDO > pdo\_mysql > pdo\_sqlite > Phar > posix > readline > redis > Reflection > session > shmop > SimpleXML > smbclient > sockets > SPL > sqlite3 > standard > sysvmsg > sysvsem > sysvshm > tokenizer > wddx > xml > xmlreader > xmlwriter > xsl > Zend OPcache > zip > zlib > > [Zend Modules] > Zend OPcache Trying the method used to install a couple of other php modules fails here. I just guessed the package name, but obviously it is wrong: ``` dnf install php-rewrite Kein Treffer für Argument: php-rewrite ``` Maybe it is part of another package? But it seems to be loaded anyhow according to ``` httpd -M | grep rewrite rewrite_module (shared) ``` So the rewrite Module should be fine. > [@MichaIng](#): > > NB: I assume now you really only need Nextcloud access Yes, the server is for **Nextcloud only**. (In the future I plan to run Collabora online server on this machine as well, but for now just forget it.) So, now I am going to continue with your cleanup suggestions. I will be back. ---
**Author:** ![MichaIng](https://help.nextcloud.com/user_avatar/help.nextcloud.com/michaing/32/2125_2.png) [@MichaIng](https://help.nextcloud.com/u/MichaIng)\ **Post date:** [February 10, 2019, 6:00pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/12 "2019-02-10T18:00:19Z")
Whoopsie, `rewrite` is no PHP module, but an Apache module of course. Mixed that up. So it should be: `a2enmod rewrite` (Debian-specific) I will fix that above as well… If the command above does not work, check the README in how to enable/disable modules. Since `./conf.modules.d` does not contain any `XX-rewrite.conf` that could be indeed missing, on the other hand Nextcloud should face major errors then and other obviously active modules also lack an explizite entry. Perhaps those are contained in `00-base.conf` or `00-optional.conf` Definitely different then on Debian that I am used to 😉. I see the `dav` module seems active. The `nextcloud.conf` disables it anyway, but you can disable it server wide: `a2dismod dav` (Debian-specific) Okay so on Fedora vhosts, config snippets and even module specific configs are merged into `./conf.d`. Makes it harder to get an overview but matches the way how Apache includes those settings: All exactly the same way via `Include` directive. However these seem to be default snippets that should not interfere any Nextcloud setup or CertBot challenge. `15-php.conf` indicates that PHP is implemented as Apache module, as expected. * * * Generally for understanding: - I am pretty sure that `./conf.modules.d` contains files with only the `LoadModule` directive, loading the modules with their set of features and additional directives. - `./conf.d` has as well module specific configs, but those apply special settings to them, e.g. `ssl.conf` containing special SSL/HTTPS settings and `perl.conf` doing the same for the perl module etc. * * * Ah jep a2en/dismod, a2en/dissite, a2en/disconf + phpen/dismod are Debian specific. Good to know: [https://serverfault.com/questions/251475/how-to-check-enable-mod-rewrite-on-apache-linux](https://serverfault.com/questions/251475/how-to-check-enable-mod-rewrite-on-apache-linux) ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 6:05pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/13 "2019-02-10T18:05:02Z")
I just found that the rewrite\_module is loaded and updated my post above. So this should be fine. ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 6:10pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/14 "2019-02-10T18:10:49Z")
As far as I recall a2enmod and a2dismod are also commands of the Debian / Ubuntu world. Some years ago I was using that, but I’m still confusing them once in a while as well. ``` a2dismod dav bash: a2dismod: Kommando nicht gefunden. / Command not found. a2enmod rewrite bash: a2enmod: Kommando nicht gefunden. / Command not found. ``` ---
**Author:** ![MichaIng](https://help.nextcloud.com/user_avatar/help.nextcloud.com/michaing/32/2125_2.png) [@MichaIng](https://help.nextcloud.com/u/MichaIng)\ **Post date:** [February 10, 2019, 6:16pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/15 "2019-02-10T18:16:57Z")
Okay so either `/etc/httpd//conf.modules.d/README` gives a hint or you manually remove `/etc/httpd//conf.modules.d/00-dav.conf`, which should be a symlink to `/etc/httpd/modules/*`: `ls -l /etc/httpd/conf.modules.d/00-dav.conf` Or simply leave it as is, since `nextcloud.conf` anyway disables it 😉. ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 6:32pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/16 "2019-02-10T18:32:42Z")
``` cat /etc/httpd/conf.modules.d/00-dav.conf ``` > **00-dav.conf** > > ``` > LoadModule dav_module modules/mod_dav.so > LoadModule dav_fs_module modules/mod_dav_fs.so > LoadModule dav_lock_module modules/mod_dav_lock.so > > ``` ``` cat /etc/httpd/conf.modules.d/README ``` > **README** > > ``` > This directory holds configuration files for the Apache HTTP Server; > any files in this directory which have the ".conf" extension will be > processed as httpd configuration files. This directory contains > configuration fragments necessary only to load modules. > Administrators should use the directory "/etc/httpd/conf.d" to modify > the configuration of httpd, or any modules. > > Files are processed in sorted order and should have a two digit > numeric prefix. See httpd.conf(5) for more information. > > ``` I suggest to leave this unchanged, as it follows the Nextcloud instructions and the README. Obviously completely removing would be the most robust solution. ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 6:33pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/17 "2019-02-10T18:33:57Z")
You were perfectly right, the rewrite module is loaded with 00-base.conf: ``` grep rewrite *.conf 00-base.conf:LoadModule rewrite_module modules/mod_rewrite.so ``` ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 10, 2019, 7:02pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/18 "2019-02-10T19:02:45Z")
Cool now, the server settings seem to be cleaned up! I rebooted the server and now it is up and running again. Do you need the updated files (\*.conf, …)? Thanks a lot for guiding me through. Now getting back to the original problem(s): a) The certbot error still occurs b) A new ssllabs test unfortunately also still states: Too many Redirection Could you please advice what to proceed next? ---
**Author:** ![MichaIng](https://help.nextcloud.com/user_avatar/help.nextcloud.com/michaing/32/2125_2.png) [@MichaIng](https://help.nextcloud.com/u/MichaIng)\ **Post date:** [February 11, 2019, 12:24am UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/19 "2019-02-11T00:24:08Z")
Okay there seem to be a redirect loop or something, that I can’t find yet. Although not really a loop since accessing via HTTPS (Nextcloud) works well right? * * * Lets check if with HTTPS, access to the ACME challenge dir works: ```auto mkdir -p /var/www/nextcloud/.well-known/acme-challenge echo 'No redirection/rewrite is done, great!' > /var/www/nextcloud/.well-known/acme-challenge/test ``` Then try to access via browser: `https://my.domain.tld/.well-known/acme-challenge/test` If you can see the file content, everything is fine so far, otherwise some rewrite/blocking/redirection is done that should not be done. Please paste any error message or URL you land on. * * * To identify the HTTP redirects: - You have no CloudFlare or some redirects active from your dynamic DNS/domain provider, have you? I found one case where provider side 443 is redirected to 80 and on local server 80 back to 443, causing a loop. Of course this is not in your case, but at least a hint where additional redirects could come from. - Lets check the remaining config file contents: `cat /etc/httpd/conf.d/*.conf` * * * I just see the logs directory now. Perhaps `/etc/httpd/logs/http_error_log` or `/etc/httpd/logs/http_access_log` show something interesting? * * * Instead of doing `Redirect permanent / https://my.domain.tld/` you could try do this with a rewrite rule as well: ```auto RewriteEngine On RewriteRule ^/?(.*)$ https://%{SERVER_NAME}/$1 [R,L] ``` - No more content required in `http_my.conf` when redirecting everything anyway. - The **R** still does a redirect (forces browser to send a new request) instead of a “silent” rewrite only (which is not reflected in browser URL). So the error might be still the same. - For debugging at least you could try to remove the **R** , so having only **[L]** at the end of the line. - The **L** btw. means that no further rewrite should be done in this context. - If interested, read for further details about `mod_rewrite`: [https://httpd.apache.org/docs/current/mod/mod\_rewrite.html](https://httpd.apache.org/docs/current/mod/mod_rewrite.html) But for simple HTTP =\> HTTPS redirection this is actually not the recommended way. So at best, even if somehow the above works, we find the reason why it doesn’t with `Redirect permanent` … ---
**Author:** ![ubuntiger](https://help.nextcloud.com/letter_avatar/ubuntiger/32/6_22734026db12803ebb3e059622ac3534.png) [@ubuntiger](https://help.nextcloud.com/u/ubuntiger)\ **Post date:** [February 11, 2019, 10:33pm UTC](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268/20 "2019-02-11T22:33:38Z")
> [@MichaIng](#): > > If you can see the file content, everything is fine so far, otherwise some rewrite/blocking/redirection is done that should not be done. Please paste any error message or URL you land on. This works with [http://my.domain.tld/.well-known/acme-challenge/test](http://my.domain.tld/.well-known/acme-challenge/test), which immediately changes to [https://my.domain.tld/.well-known/acme-challenge/test](https://my.domain.tld/.well-known/acme-challenge/test) and it shows what is intended: ![2019_02_10_acme_challenge_test](https://help.nextcloud.com/uploads/default/original/2X/3/37aa5cbfc4b81ce274f891461d28eb6fdb356eae.png) It also works with my current public IP adress with https [https://87.181.xx.xx/.well-known/acme-challenge/test](https://87.181.xx.xx/.well-known/acme-challenge/test) after accepting the certificate. But it fails for http with IP: [http://87.181.xx.xx/.well-known/acme-challenge/test](http://87.181.xx.xx/.well-known/acme-challenge/test) which automatically changes to (I guess just another type of displaying it by Firefox): 87.181.xx.xx/.well-known/acme-challenge/test ![2019_02_10_acme_challenge_test_http_IP](https://help.nextcloud.com/uploads/default/original/2X/0/083c06b0d66be1795712e32dc87d0ef16daea2c6.png) As it is quite late now, I will check your proposal “rewrite rule” tomorrow evening, if it still should be a path you suggest to follow. I just had a look into /etc/letsencrypt/ There is that ``` SSLOptions +StrictRequire ``` Now letsencrypt state that they need port 80 open, see link on very top of this thread. Might this be a problem? As far as I recall I opted to have strict SSL only when setting up letsencrypt. The complete file is here: > **/etc/letsencrypt/options-ssl-apache.conf** > > ``` > # This file contains important security parameters. If you modify this file > # manually, Certbot will be unable to automatically provide future security > # updates. Instead, Certbot will print and log an error message with a path to > # the up-to-date file that you will need to refer to when manually updating > # this file. > > SSLEngine on > > # Intermediate configuration, tweak to your needs > SSLProtocol all -SSLv2 -SSLv3 > SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS > SSLHonorCipherOrder on > > SSLOptions +StrictRequire > > # Add vhost name to log entries: > LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined > LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common > > #CustomLog /var/log/apache2/access.log vhost_combined > #LogLevel warn > #ErrorLog /var/log/apache2/error.log > > # Always ensure Cookies have "Secure" set (JAH 2012/1) > #Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4" > > ``` Here is the listing of all \*.conf, unfortunately without the name of the conf, then stripped by comment lines because it kills length of allowed post. This is some manual work for me for tomorrow, unless you have a nice bash command… > **cat /etc/httpd/\*/\*.conf \> ./cat\_of\_all\_dot\_conf.txt** > > IndexOptions FancyIndexing HTMLTable VersionSort > > Alias /icons/ “/usr/share/httpd/icons/” > > \ > Options Indexes MultiViews FollowSymlinks > AllowOverride None > Require all granted > > AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip > > AddIconByType (TXT,/icons/text.gif) text/\* > AddIconByType (IMG,/icons/image2.gif) image/\* > AddIconByType (SND,/icons/sound2.gif) audio/\* > AddIconByType (VID,/icons/movie.gif) video/\* > > AddIcon /icons/binary.gif .bin .exe > AddIcon /icons/binhex.gif .hqx > AddIcon /icons/tar.gif .tar > AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv > AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip > AddIcon /icons/a.gif .ps .ai .eps > AddIcon /icons/layout.gif .html .shtml .htm .pdf > AddIcon /icons/text.gif .txt > AddIcon /icons/c.gif .c > AddIcon /icons/p.gif .pl .py > AddIcon /icons/f.gif .for > AddIcon /icons/dvi.gif .dvi > AddIcon /icons/uuencoded.gif .uu > AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl > AddIcon /icons/tex.gif .tex > AddIcon /icons/bomb.gif core. > > AddIcon /icons/back.gif … > AddIcon /icons/hand.right.gif README > AddIcon /icons/folder.gif ^^DIRECTORY^^ > AddIcon /icons/blank.gif ^^BLANKICON^^ > > DefaultIcon /icons/unknown.gif > > ReadmeName README.html > HeaderName HEADER.html > > \ > ServerAdmin [email@address.de](mailto:email@address.de) > Redirect permanent / [https://my.domain.tld/](https://my.domain.tld/) > ErrorLog logs/http\_error\_log > CustomLog logs/http\_access\_log combined > > Alias /manual /usr/share/httpd/manual > > \ > Options Indexes > AllowOverride None > Require all granted > > ``` > RedirectMatch 301 ^/manual/(?:da|de|en|es|fr|ja|ko|pt-br|ru|tr|zh-cn)(/.*)$ "/manual$1" > > ``` > > Options +FollowSymlinks AllowOverride All Dav off SetEnv HOME /var/www/nextcloud SetEnv HTTP\_HOME /var/www/nextcloud > > \ > Require all denied > > AddType text/html .php > > DirectoryIndex index.php > > \ > \ > SetEnvIfNoCase ^Authorization$ “(.+)” HTTP\_AUTHORIZATION=$1 > > ``` > > SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost" > > > ``` > > SetHandler application/x-httpd-php > > ``` > php_value session.save_handler "files" > php_value session.save_path "/var/lib/php/session" > php_value soap.wsdl_cache_dir "/var/lib/php/wsdlcache" > > ``` > > ScriptAlias /Squid/cgi-bin/cachemgr.cgi /usr/lib64/squid/cachemgr.cgi > > \ > Require local > > Listen 443 https > > SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog > > SSLSessionCache shmcb:/run/httpd/sslcache(512000) > SSLSessionCacheTimeout 300 > > SSLRandomSeed startup file:/dev/urandom 256 > SSLRandomSeed connect builtin > > SSLCryptoDevice builtin > > DocumentRoot “/var/www/nextcloud” > > ErrorLog logs/ssl\_error\_log > TransferLog logs/ssl\_access\_log > LogLevel warn > > SSLEngine on > > SSLProtocol all -SSLv3 > SSLProxyProtocol all -SSLv3 > > SSLHonorCipherOrder on > > SSLCipherSuite PROFILE=SYSTEM > SSLProxyCipherSuite PROFILE=SYSTEM > > \ > SSLOptions +StdEnvVars > > \ > SSLOptions +StdEnvVars > > BrowserMatch “MSIE [2-5]” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 > > CustomLog logs/ssl\_request\_log “%t %h %{SSL\_PROTOCOL}x %{SSL\_CIPHER}x "%r" %b” > > Include /etc/letsencrypt/options-ssl-apache.conf > SSLCertificateFile /etc/letsencrypt/live/my.domain.tld/fullchain.pem > SSLCertificateKeyFile /etc/letsencrypt/live/my.domain.tld/privkey.pem > > Header always set Strict-Transport-Security “max-age=15552000; includeSubDomains” > > UserDir disabled > > \ > AllowOverride FileInfo AuthConfig Limit Indexes > Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec > Require method GET POST OPTIONS > > Alias /usage /var/www/usage > > \ > Require local > > \ > Options -Indexes > ErrorDocument 403 /.noindex.html > > \ > AllowOverride None > Require all granted > > Alias /.noindex.html /usr/share/httpd/noindex/index.html > > ServerRoot “/etc/httpd” > > Listen 80 > > Include conf.modules.d/\*.conf > > User apache > Group apache > > ServerAdmin [email@address.de](mailto:email@address.de) > > ServerName my.domain.tld > > AllowOverride none Require all denied > > \ > AllowOverride None > Require all granted > > \ > Options Indexes FollowSymLinks > > ``` > AllowOverride None > > Require all granted > > ``` > > DirectoryIndex index.html > > AccessFileName .htaccess > \ > Require all denied > > ErrorLog “logs/error\_log” > > LogLevel warn > > LogFormat "%h %l %u %t \"%r\" %\>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %\>s %b" common > > ``` > > LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio > > > CustomLog "logs/access_log" combined > > ``` > > ``` > ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" > > ``` > > \ > AllowOverride None > Options None > Require all granted > > TypesConfig /etc/mime.types > > ``` > AddType application/x-compress .Z > AddType application/x-gzip .gz .tgz > > AddType text/html .shtml > AddOutputFilter INCLUDES .shtml > > ``` > > AddDefaultCharset UTF-8 > > MIMEMagicFile conf/magic > > EnableSendfile on > > IncludeOptional conf.d/\*.conf > > LoadModule access\_compat\_module modules/mod\_access\_compat.so > LoadModule actions\_module modules/mod\_actions.so > LoadModule alias\_module modules/mod\_alias.so > LoadModule allowmethods\_module modules/mod\_allowmethods.so > LoadModule auth\_basic\_module modules/mod\_auth\_basic.so > LoadModule auth\_digest\_module modules/mod\_auth\_digest.so > LoadModule authn\_anon\_module modules/mod\_authn\_anon.so > LoadModule authn\_core\_module modules/mod\_authn\_core.so > LoadModule authn\_dbd\_module modules/mod\_authn\_dbd.so > LoadModule authn\_dbm\_module modules/mod\_authn\_dbm.so > LoadModule authn\_file\_module modules/mod\_authn\_file.so > LoadModule authn\_socache\_module modules/mod\_authn\_socache.so > LoadModule authz\_core\_module modules/mod\_authz\_core.so > LoadModule authz\_dbd\_module modules/mod\_authz\_dbd.so > LoadModule authz\_dbm\_module modules/mod\_authz\_dbm.so > LoadModule authz\_groupfile\_module modules/mod\_authz\_groupfile.so > LoadModule authz\_host\_module modules/mod\_authz\_host.so > LoadModule authz\_owner\_module modules/mod\_authz\_owner.so > LoadModule authz\_user\_module modules/mod\_authz\_user.so > LoadModule autoindex\_module modules/mod\_autoindex.so > LoadModule brotli\_module modules/mod\_brotli.so > LoadModule cache\_module modules/mod\_cache.so > LoadModule cache\_disk\_module modules/mod\_cache\_disk.so > LoadModule cache\_socache\_module modules/mod\_cache\_socache.so > LoadModule data\_module modules/mod\_data.so > LoadModule dbd\_module modules/mod\_dbd.so > LoadModule deflate\_module modules/mod\_deflate.so > LoadModule dir\_module modules/mod\_dir.so > LoadModule dumpio\_module modules/mod\_dumpio.so > LoadModule echo\_module modules/mod\_echo.so > LoadModule env\_module modules/mod\_env.so > LoadModule expires\_module modules/mod\_expires.so > LoadModule ext\_filter\_module modules/mod\_ext\_filter.so > LoadModule filter\_module modules/mod\_filter.so > LoadModule headers\_module modules/mod\_headers.so > LoadModule include\_module modules/mod\_include.so > LoadModule info\_module modules/mod\_info.so > LoadModule log\_config\_module modules/mod\_log\_config.so > LoadModule logio\_module modules/mod\_logio.so > LoadModule macro\_module modules/mod\_macro.so > LoadModule mime\_magic\_module modules/mod\_mime\_magic.so > LoadModule mime\_module modules/mod\_mime.so > LoadModule negotiation\_module modules/mod\_negotiation.so > LoadModule remoteip\_module modules/mod\_remoteip.so > LoadModule reqtimeout\_module modules/mod\_reqtimeout.so > LoadModule request\_module modules/mod\_request.so > LoadModule rewrite\_module modules/mod\_rewrite.so > LoadModule setenvif\_module modules/mod\_setenvif.so > LoadModule slotmem\_plain\_module modules/mod\_slotmem\_plain.so > LoadModule slotmem\_shm\_module modules/mod\_slotmem\_shm.so > LoadModule socache\_dbm\_module modules/mod\_socache\_dbm.so > LoadModule socache\_memcache\_module modules/mod\_socache\_memcache.so > LoadModule socache\_shmcb\_module modules/mod\_socache\_shmcb.so > LoadModule status\_module modules/mod\_status.so > LoadModule substitute\_module modules/mod\_substitute.so > LoadModule suexec\_module modules/mod\_suexec.so > LoadModule unique\_id\_module modules/mod\_unique\_id.so > LoadModule unixd\_module modules/mod\_unixd.so > LoadModule userdir\_module modules/mod\_userdir.so > LoadModule version\_module modules/mod\_version.so > LoadModule vhost\_alias\_module modules/mod\_vhost\_alias.so > LoadModule watchdog\_module modules/mod\_watchdog.so > > LoadModule dav\_module modules/mod\_dav.so > LoadModule dav\_fs\_module modules/mod\_dav\_fs.so > LoadModule dav\_lock\_module modules/mod\_dav\_lock.so > LoadModule lua\_module modules/mod\_lua.so > > LoadModule mpm\_event\_module modules/mod\_mpm\_event.so > > LoadModule proxy\_module modules/mod\_proxy.so > LoadModule lbmethod\_bybusyness\_module modules/mod\_lbmethod\_bybusyness.so > LoadModule lbmethod\_byrequests\_module modules/mod\_lbmethod\_byrequests.so > LoadModule lbmethod\_bytraffic\_module modules/mod\_lbmethod\_bytraffic.so > LoadModule lbmethod\_heartbeat\_module modules/mod\_lbmethod\_heartbeat.so > LoadModule proxy\_ajp\_module modules/mod\_proxy\_ajp.so > LoadModule proxy\_balancer\_module modules/mod\_proxy\_balancer.so > LoadModule proxy\_connect\_module modules/mod\_proxy\_connect.so > LoadModule proxy\_express\_module modules/mod\_proxy\_express.so > LoadModule proxy\_fcgi\_module modules/mod\_proxy\_fcgi.so > LoadModule proxy\_fdpass\_module modules/mod\_proxy\_fdpass.so > LoadModule proxy\_ftp\_module modules/mod\_proxy\_ftp.so > LoadModule proxy\_http\_module modules/mod\_proxy\_http.so > LoadModule proxy\_hcheck\_module modules/mod\_proxy\_hcheck.so > LoadModule proxy\_scgi\_module modules/mod\_proxy\_scgi.so > LoadModule proxy\_uwsgi\_module modules/mod\_proxy\_uwsgi.so > LoadModule proxy\_wstunnel\_module modules/mod\_proxy\_wstunnel.so > LoadModule ssl\_module modules/mod\_ssl.so > LoadModule systemd\_module modules/mod\_systemd.so > > LoadModule cgid\_module modules/mod\_cgid.so LoadModule cgid\_module modules/mod\_cgid.so LoadModule cgi\_module modules/mod\_cgi.so > > LoadModule perl\_module modules/mod\_perl.so > LoadModule http2\_module modules/mod\_http2.so > LoadModule proxy\_http2\_module modules/mod\_proxy\_http2.so > > \ > > LoadModule php7\_module modules/libphp7.so > > \ > \ So now. late enough. More tomorrow. As Cert expiration dates is on Wednesday, maybe we switch to open a simple \*80 port temporarily, make sure I keep a valid certificate with that and then try to close again… Thanks again for great support! [Next page](https://help.nextcloud.com/t/letsencrypt-certificate-renewal-fails-with-well-hardend-nextcloud-15-04-server/47268.md?page=2)