Https saying not secure when using plex, cockpit, and filebrowser

My domain is: shinytreecko.com

I ran this command: n/a

It produced this output: n/a

My web server is (include version): Apache 2.4.25

The operating system my web server runs on is (include version): Debian 8

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.40.1

When accessing my file browsing service at shinytreecko.com:8080 it says not secure. When going to https://shinytreecko.com:8080 it says that the site cannot provide a secure connection. I get the same types of errors when using cockpit and plex on different ports. Would it be possible for me to extend use of SSL to these services and would anyone also have advice on how to help me make shinytreecko.com:8080 redirect to files.shinytreecko.com or just having files.shinytreecko.com access the filebrowser service while keeping “:8080” out of the address bar as well as having everything secured with SSL?

1 Like

If you look at the FileBrowser docs - they recommend using Caddy, which will automatically proxy FileBrowser and handle SSL for you: https://filebrowser.xyz/installation/caddy .

Only problem is … you are using Apache already, which is a choice that conflicts with the use of Caddy, since they cannot both use the same ports (80/443).

You can do approximately the same thing with Apache, it’s just a bit more complicated to setup.

For example, what you can do is setup an Apache virtual host as follows:

<VirtualHost *:80>
  ServerName files.shinytreecko.com
  ProxyPass http://localhost:8080/
  ProxyPassReverse http://localhost:8080/
</VirtualHost>

Setup an appropriate DNS record for files.shinytreecko.com (probably a CNAME record pointing to shinytreecko.com), then reload Apache, and confirm that you can access FileBrowser insecurely at http://files.shinytreecko.com .

Once you’ve done that, you can then setup SSL:

certbot --apache -d files.shinytreecko.com

That should succeed, and you should then be able to access https://files.shinytreecko.com securely, and stop using the :8080 endpoint.

I hope that sort of makes sense.

2 Likes

I know you said that caddy conflicts with apache because they use the same ports, but I’ve changed the SSH listening port on my server to a different one. Would it be possible to do the same thing with caddy and change the ports to something besides 80/443? Also thank you so much for your advice, and if it’s not possible to change caddy’s ports I’ll use virtual hosts like you suggested because that sounds like it would work perfectly.

I’m not sure if I did this right. This is what I have in my configuration file.


This is the result of me doing “sudo systemctl restart apache2.service”

This is the result of me running “sudo systemctl status apache2.service”

Any advice on what I should do with these issues? My site works fine without the changes to 000-default.conf which I made a backup of before changing anything.

1 Like

The problem with that would be that your existing website on https://shinytreecko.com would disappear, unless you also moved it to use Caddy instead of Apache.

That’s my bad. Change the two ProxyPass lines to these:

  ProxyPass / http://localhost:8080/
  ProxyPassReverse / http://localhost:8080/

You might also need to run:

a2enmod proxy_http
1 Like

Ok that worked and it’s all making more sense. I use Google Domains for hosting so I made a CNAME record for the files subdomain that points to shinytreecko.com and now I actually have a page that sends data. http://files.shinytreecko.com/ looks different now and even has the filebrowser logo at the top of my chrome tab. It says the service is unavailable though. I made a service to make filebrowser start at login and keep running, so I stopped this service and started it and refreshed the page and it still has the same message. Reloaded apache with the same result. Could this be because I still have my website hosted on shinytreecko.com? If at all possible I would rather keep hosting on apache but if it’s not I’d be happy to switch to caddy. Don’t know what all that entails though and I apologize for not being as tech savvy as you because your help has been extremely thorough.

1 Like

Can you verify that FileBrowser is indeed running on the same server as your Apache webserver?

Any chance that it’s port forwarded to a different server? e.g. port 80 goes to one server, 8080 goes to another?

ss -tlnp | grep ":8080"
curl -X GET -I localhost:8080
tail -n 20 /var/log/apache2/error_log

The result of those commands is this


Everything is running on one server whose internal IP is 192.168.1.90. I'm not sure why I cannot connect with localhost.

The result of this one is in the screenshot below.


I should probably be blurring out all these external IP addresses but I'm not sure lol.

Port 80 and port 8080 are both forwarded on my router to go to this specific server and I don't have any other devices hosting anything on my network. I do have UFW configured on my server though and I believe I've let everything through the firewall that needs to come through with both IPv6 and IPv4.

1 Like

Okay. I think it’s a fairly simple issue. FileBrowser is listening on a specific address (as opposed to all addresses), so we just need to tell Apache to connect on that address.

Changing the proxy lines to this should do the trick:

  ProxyPass / http://192.168.1.90:8080/
  ProxyPassReverse / http://192.168.1.90:8080/
1 Like

I noticed you got the proxy working, but you seem to have created an SSL certificate that replaced your original one, and it doesn’t point to the right website.

What you ideally want to do in this case is to have two certificates - one for your main domain, and one for the FileBrowser domain.

I would have expected my original advice would have achieved this. One certiicate per vhost:

certbot --apache -d shinytreecko.com -d www.shinytreecko.com
certbot --apache -d files.shinytreecko.com

But if that hasn’t worked as expected, posting the output of this might help:

apachectl -t -D DUMP_VHOSTS
1 Like

WOW changing those lines worked and allowed me to access files.shinytreecko.com with the service running. Thank you so much!

I used this to get SSL working on that subdomain but it said that the command could not be found so I instead did certbot-auto --apache -d files.shinytreecko.com and that command worked.
https://shinytreecko.com/screenshots/Screenshot%20(51).png
This is what happened when I did that, but as you mentioned in your last reply it seems to have overwritten my original certificate. I also went to https://files.shinytreecko.com and it goes to my website without filebrowser HOWEVER the connection is still secure so something's working.

This is the result of

https://shinytreecko.com/screenshots/Screenshot%20(52).png

1 Like

Also I feel like I should mention that when I added the VirtualHost lines in /etc/apache2/sites-available/000-default.conf. I have not edited 000-default-le-ssl.conf, default-ssl.conf, or anything else.

OK. I tried copying what you’ve done, and it seems like Certbot made a bit of a mess because it does the wrong thing when you have multiple virtual hosts combined in a single file. Sorry. :cry: (Edit: I’ve filed https://github.com/certbot/certbot/issues/7572 to represent this issue)

From a high level, getting this to work will need you to separate the shinytreecko.com/www.shinytreecko.com virtual host and the files.shinytreecko.com virtual host into separate files.

Right now they’re located in the same file in /etc/apache2/sites-enabled/000-default.conf. I propose that you separate the files.shinytreecko.com virtualhost into a new file, such as /etc/apache2/sites-enabled/files.conf.

Second, we want to undo a little bit of what Certbot did.

Open up /etc/apache2/sites-enabled/000-default-le-ssl.conf, and remove the line that says ServerAlias files.shinytreecko.com.

Third, we want to disable default-ssl.conf, since it’s not helpful at all:

a2dissite default-ssl

At this point, try reload Apache. It’s not the full solution, but I want to confirm that we can get to this staging before finally applying the certificates to the two separate virtual hosts.

For the next step, having the output of this command will help too:

sudo certbot-auto certificates
1 Like

I just got back to try your suggestions and It's completely okay that certbot didn't work as intended. That's the fun of finding things out because sometime it sucks when the computer does exactly what you tell it to do instead of exactly what you want it to do. Ok so I separated the files and removed the line that you told me to delete in /etc/apache2/sites-enabled/files.conf (finally getting a hold of how we're supposed to format text here lol). I called the new virtual host file files.conf and disabled default-ssl.conf with the command. I believe that's everything covered to move onto the next steps. Here is the output of

I’m a little afraid that things will go wrong again because I can’t check your configuration for myself, so it might help to be more explicit this time:

/etc/apache2/sites-enabled/000-default.conf should look like:

<VirtualHost *:80>
  ServerName shinytreecko.com
  ServerAlias www.shinytreecko.com
  ServerAdmin wes@shinytreecko.com
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/error.log combined
</VirtualHost>

# and the remainder of the file
# <Directory /var/www/html> etc ...

/etc/apache2/sites-enabled/files.conf should look like:

<VirtualHost *:80>
  ServerName files.shinytreecko.com
  ProxyPass / http://192.168.1.90:8080/
  ProxyPassReverse / http://192.168.1.90:8080/
</VirtualHost>

We’re going to temporarily disable your existing SSL because it’s not doing what we want:

a2dissite 000-default-le-ssl
mv /etc/apache2/sites-available/000-default-le-ssl.conf /etc/apache2/sites-available/000-default-le-ssl.conf.old

and then we try install your existing certificates to your split up virtualhosts:

sudo certbot-auto install --cert-name shinytreecko.com -i apache --no-redirect

and

sudo certbot-auto install --cert-name files.shinytreecko.com -i apache --no-redirect

Fingers crossed. I’ve tested this all out locally based on what you have done so far, so it should work.

1 Like

That all works perfectly I can't thank you enough for all of your help and commitment to getting this problem solved! This all works perfectly and it accomplishes everything I need in terms of filebrowser. I'm not sure if you have the time and if not that is completely okay, but do you know if the steps would be the same for using Plex on port 32400? Plex looks a bit more complicated to set up with SSL and a subdomain, but I think Cockpit on port 9090 should have the same steps as filebrowser. The other thing I wanted to ask is that when I go to shinytreecko.com:8080, it doesn't automatically redirect with https. If it's simpler, I would prefer to disable accessing my site through a specific port (besides 80 and 443 of course) and restrict access to subdomains using https only. If it's not possible that is completely okay you have helped me so much with this and I honestly don't think I would've had the patience to solve all this on my own :slight_smile:. I also used these lines

but then used them again without --no-redirect to see if that would force redirects site-wide, but it did not.

1 Like

I would just block port 8080 on your firewall. This reflects a best practice of only allowing traffic via your Apache proxy, and not allowing direct access to the application (FileBrowser).

Any sufficiently simple and well-written software should be proxy-able in the exact same way we’ve done here.

I’m not sure about Plex. I haven’t run it in quite a few years but if I recall, it’s a complex beast with multiple ports involved. e.g. when I search for “plex apache reverse proxy”, it comes up with this link, which suggests that you not only need to secure the HTTP part, but also the websocket part. Certbot’s --apache plugin can’t deal with that, it’s too exotic. So you might need to use certbot-auto certonly (issue the certificate but don’t install it), and then manually configure Apache to use the certificate for the Plex domain. Good luck.

1 Like

Blocking port 8080 on UFW worked perfectly and now I can only use files.shinytreecko.com which uses SSL by default. Thank you so much for your help on all of this! After reading your suggestion for Plex I decided to put it off for another day because it’s 3:22 AM where I am and I had a burst of energy and wanted to get this done. However, I tried to repeat your steps to get cockpit to work and just replaced a couple things. The steps I did were

  1. Create a file called cockpit.conf with the contents
    <VirtualHost *:80>
    ServerName files.shinytreecko.com
    ProxyPass / http://192.168.1.90:9090/
    ProxyPassReverse / http://192.168.1.90:9090/
  2. run sudo certbot-auto install --cert-name cockpit.shinytreecko.com -i apache
  3. sudo certbot-auto --apache -d cockpit.shinytreecko.com
  4. Got an error saying it could not find a virtual host called cockpit.shinytreecko.com
  5. Realize I accidentally typed files.shinytreecko.com instead of cockpit.shinytreecko.com in cockpit.conf
  6. Fix issue and steps 2 and 3 again with forced https redirects
  7. Do sudo systemctl restart apache2
  8. Go to cockpit.shinytreecko.com and it redirects to https://192.168.1.90:9090. The connection is secure though so I guess that’s progress

This is definitely my mistake and it’s probably even a tiny one but I can’t seem to figure out what it is. Any advice you might have?

1 Like

You setup the certificate correctly. It seems that Cockpit requires some little extra configuration to work under reverse proxying, or else it sends a pointless redirect (https://github.com/cockpit-project/cockpit/wiki/Proxying-Cockpit-over-Apache-with-LetsEncrypt).

From what I can tell, you need to add this to your Apache virtualhost for Cockpit:

  ProxyPreserveHost On

  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /(.*)           ws://192.168.1.90:9090/$1 [P,L]
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule /(.*)           http://192.168.1.90:9090/$1 [P,L]

and this to your Cockpit config:

[WebService]
Origins = https://cockpit.shinytreecko.com http://127.0.0.1:9090 http://192.168.1.90:9090
ProtocolHeader = X-Forwarded-Proto
AllowUnencrypted = true

after you restart both, Cockpit shouldn’t send the redirect anymore (but you might need to flush browser cache, because a 301 redirect is going to get cached unfortunately).

1 Like

Ok so after falling asleep I checked the files in my /etc/apache2/sites-available and found that cockpit.conf was missing. Not sure what happened to it but when I restarted apache2 and tried to go to cockpit.shinytreecko.com it still redirected to my server's local IP with :9090 so that's strange. Anyways I did sudo vim /etc/apache2/sites-available/cockpit.conf and added
<VirtualHost *:80> ServerName cockpit.shinytreecko.com ProxyPass / http://192.168.1.90:9090/ ProxyPassReverse / http://192.168.1.90:9090/ </VirtualHost>

Do I put this in that same file? If so, do I put it inside of the VirtualHost tag (I'm 99% sure it does) or does it go below?

I also don't know where my cockpit config is unless that's /etc/apache2/sites-available/cockpit.conf. And when you say flush browser cache you mean on the client-side?

1 Like