Nextcloud/Apache2 External access issue

Having issues with your DietPi installation, or, found a bug? Post it here.
Post Reply
Skirge01
Posts: 10
Joined: Wed Jan 08, 2020 6:45 pm

Nextcloud/Apache2 External access issue

Post by Skirge01 »

I installed Nextcloud, Let's Encrypt, and Certbot in a virtual machine running diet-pi. Trusted domains are entered correctly. HTTP works fine via LAN, but HTTPS does not:

http://192.168.1.175/nextcloud (WORKS)
https://192.168.1.175/nextcloud (BROKEN w/"SSL_ERROR_RX_RECORD_TOO_LONG" message)
http://[domain].allowed.org/nextcloud/login (WORKS)
https://[domain].allowed.org/nextcloud/login (BROKEN w/"SSL_ERROR_RX_RECORD_TOO_LONG" message)

Both HTTP and HTTPS fail via WAN. HTTP times out while HTTPS gives the same "SSL_ERROR_RX_RECORD_TOO_LONG" error message.

I'm using FreeDNS for multiple sites I host and the others work fine. I have forwarded both ports 80 and 443 to 192.168.1.175 on my firewall. Port 80 shows up as stealth on ShieldsUp, while 443 shows up as open.

When running Let's Encrypt, I received a message of:

Code: Select all

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for [domain].allowed.org
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. [domain].allowed.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://[domain].allowed.org/.well-known/acme-challenge/[challenge code]: Timeout during connect (likely firewall problem)
I believe that's expected when using services like FreeDNS.

I assume I have something messed up in one or more (apache2?) conf files, but I don't know enough to figure it out on my own.

I think this is the only one I tried modifying:

Code: Select all

[email protected]:/etc/apache2/sites-available# more 000-default.conf
<VirtualHost *:80>
        ServerName [domain].allowed.org
        ServerAdmin [email protected]
        DocumentRoot /var/www

        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

        ErrorLog ${APACHE_LOG_DIR}/error.log
        #CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Ultimately, I don't want/need HTTP working for Nextcloud. Any help pointing me in the right direction to get HTTPS working would be greatly appreciated. Thanks!

User avatar
Joulinar
Posts: 752
Joined: Fri Nov 15, 2019 11:49 pm

Re: Nextcloud/Apache2 External access issue

Post by Joulinar »

Hi,
the problem you are facing has nothing to do with your DDNS provider. It's more coming from the fact that your Apache Webserver is not reachable on port 80 from the internet. But this needs to be ensured otherwise Let'sEncrypt is not able to create your SSL certificate. Next to that, there is no need to perform manuel configurations. Everything will be done by dietpi-config and dietpi-letsencrypt

Therefore I would recommend the following (as this a VM) ;)
  1. reset your VM and create a clean DietPi installation
  2. ensure Port 80 and 443 are forwarded (from your internet router) correctly to your VM
  3. once ready with the initial setup, goto dietpi-software and change to Webserver Preference : [Apache2]
  4. search and install NextCloud
  5. once installation completed and your system was rebooted, try to connect to your Apache Webserver on http (port 80)
  6. pls try to connect from your LAN as well as from Internet, you should receive the Apache2 Debian Default Page
    • once your are able to connect to your Webserver from Internet on http (80), got to point 7. (https - port 443 will not work at this stage)
    • if you are not able to connect on http (80) from internet, you would need to check why and whats wrong with your port forwarding
  7. lets do the SSL certificate now, goto dietpi-letsencrypt
  8. install CertBot
  9. once done you will be ask for your Let'sEncrypt information
    • fill in your domain name
    • fill in your email address
    • set Redirect to ON
    • Apply the setting
  10. once finished (and all services started) you should be able to reach your website on http (80) as well as https (443)
  11. if you are opening the website on http (80) you should be automatically redirected to https (443)
hope it will fix your issue

Skirge01
Posts: 10
Joined: Wed Jan 08, 2020 6:45 pm

Re: Nextcloud/Apache2 External access issue

Post by Skirge01 »

Fair enough. I'll just shut down the existing VM and create a new one. When we get this one working, I can delete the old one. This also allows me to reference things, if necessary.

Skirge01
Posts: 10
Joined: Wed Jan 08, 2020 6:45 pm

Re: Nextcloud/Apache2 External access issue

Post by Skirge01 »

With the new VM, I was having the same issue. Knowing my ports were properly forwarded on the firewall, it hit me that my ISP may have started doing some port blocking. Turns out they have started blocking port 80. I figured out how to change the http port in apache2 and now can access it externally via a different port.

I ran dietpi-letsencrypt/certbot, but it's complaining about no virtual host on port 80:
Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.
Is there a way around this?

User avatar
Joulinar
Posts: 752
Joined: Fri Nov 15, 2019 11:49 pm

Re: Nextcloud/Apache2 External access issue

Post by Joulinar »

Beste to my knowledge Let'sEncrypt is expecting port 80 and 443. Not sure if this can be changed. Probably something you would need to check with Let'sEncrypt directly.

Skirge01
Posts: 10
Joined: Wed Jan 08, 2020 6:45 pm

Re: Nextcloud/Apache2 External access issue

Post by Skirge01 »

After doing some reading, I don't think it's worth the effort for the certificate. Maybe I can figure out how to redirect apache from http to https without the cert.

User avatar
Joulinar
Posts: 752
Joined: Fri Nov 15, 2019 11:49 pm

Re: Nextcloud/Apache2 External access issue

Post by Joulinar »

If you want https, you need a certificate. But you might solve the problem by using a self-signed certificates.

Post Reply