HTTPS Setup

[dancrowhurst]

Hi,

I'm running the latest release on a Raspberry Pi 4. I've got the standard HTTP site up and running, but need to look at enabling HTTPS. I've seen comments that imply running the enable_ssl.sh script will enable this, however when running the scrip it does nothing.

The script appears to be accessing running enable-ssl in the site.yml file located in /screenly/ansible, howerver the yml file does not do anything.

Has anyone been able to get https working recently and if so how did you accomplish this?

Many thanks,
Daniel

[dyseptical]

I ran into the same issue, but haven't found a real solution yet - i do have a workaround though.

• I installed Anthias with the supplied install script and rebooted the Pi.
• You now need to edit the File ~/screenly/docker-compose.yml.tmpl:

For the anthias-nginx container, replace the current port configuration:

    ports:
      - 80:80

With this:

    ports:
      - 127.0.0.1:8080:80

This procedure is also documented here: https://docs.docker.com/network/

If you include the localhost IP address (127.0.0.1) with the publish flag, only the Docker host can access the published container port.

$ docker run -p 127.0.0.1:8080:80 nginx

• You can execute the script under ~/screenly/bin/upgrade_containers.sh to apply this change.
• Install a web server of your choosing on the Pi directly, i chose nginx for this
• Configure a site that proxies the connection. For nginx, this can be done with
  proxy_pass http://127.0.0.1:8080/;
• On this site, you can now configure HTTPS with your own certificates and Security options.
• You can also configure a HTTP->HTTPS Redirect with this.

This configuration survives updating the containers with upgrade_containers.sh, but probably won't survive updating via the run_upgrade.sh script.

Maybe the supplied install script could ask if you want to use you own web server as a proxy?
Setting up the Proxy isn't hard and having full control over the nginx's Security configuration (and how often its updated) would be quite a plus for me.

[shaqaruden]

the nginx service is working as a reverse proxy to the anthias-server service so you would need to edit the nginx config file in the docker/nginx directory. I am have been working at this myself with only some luck.

I was not able to get the nginx config to work but switching to Caddy I was able to get https work just fine.I'm not sure if it is 100% functional yet but it's a good start. I'm using self-signed certs so I bind them into the container as well

Here is my anthias-caddy service defined in docker-compose.yml

services:
  ...
 anthias-caddy:
   image: caddy:latest
   ports:
     - 443:443
   environment:
     - HOME=/data
   depends_on:
     - anthias-server
     - anthias-websocket
   restart: always
   volumes:
     - resin-data:/data:ro
     - /home/pacerboard/.screenly:/data/.screenly:ro
     - /home/pacerboard/screenly_assets:/data/screenly_assets:ro
     - /home/pacerboard/screenly/staticfiles:/data/screenly/staticfiles:ro
     - /etc/timezone:/etc/timezone:ro
     - /etc/localtime:/etc/localtime:ro
     - ./docker/caddy:/etc/caddy
     - ./docker/caddy/Zima140.pem:/etc/caddy/Zima140.pem:ro # this is my certificate, marked with :ro to make it read only
     - ./docker/caddy/cert-key.pem:/etc/caddy/cert-key.pem:ro # this is my private key certificate marked with :ro

For the anthias-viewer service I needed to change

- LISTEN=anthias-nginx

to

- LISTEN=anthias-caddy

Then here is the Caddyfile I am using (Note that I am only handling https, so if you visit with http you are not redirected to https, I will be adding this to my Caddyfile at some point)

:443 {
       tls /etc/caddy/Zima140.pem /etc/caddy/cert-key.pem

       # Proxy requests to anthias-server
       @anthias {
               not path /static/* /ws /hotspot /screenly_assets /static_with_mime
       }
       reverse_proxy @anthias anthias-server:8080 {
               header_up Host anthias-server
               header_up X-Real-IP {remote}
               header_up X-Forwarded-For {remote}
       }

       # Handle API backup requests with extended timeouts
       @backup path_regexp /api/[0-9a-z]+/backup$
       reverse_proxy @backup anthias-server:8080 {
               transport http {
                       read_timeout 1800s
                       write_timeout 1800s
                       dial_timeout 1800s
               }
               header_up Host anthias-server
               header_up X-Real-IP {remote}
               header_up X-Forwarded-For {remote}
       }

       # Serve static files
       handle_path /static/* {
               root * /data/screenly/staticfiles
               file_server
       }

       # Handle WebSocket requests
       handle_path /ws {
               reverse_proxy anthias-websocket:9999 {
                       header_up Host {host}
                       header_up Upgrade {>Upgrade}
                       header_up Connection {>Connection}
               }
       }

       # Hotspot location
       @hotspot not file /data/.screenly/initialized
       handle_path /hotspot {
               root * /data
               rewrite * /hotspot/hotspot.html
               file_server
               @allowed_cidr {
                       remote_ip 172.16.0.0/12
               }
       }

       # Restrict /screenly_assets access
       handle_path /screenly_assets* {
               root * /data/screenly_assets
               file_server
               @allowed_cidr {
                       remote_ip 172.16.0.0/12
               }
       }

       # Static files with MIME type restrictions
       handle_path /static_with_mime* {
               root * /data/screenly/staticfiles
               file_server
               @allowed_cidr {
                       remote_ip 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
               }
       }
}

The websocket stuff is not working but it's also not working in the base installation so I'm not worrying about it

[vpetersson]

Just for clarity -- I'm not against using self-signed SSL certificates. It is just want to prioritize LE/Tailscale higher in the user workflow.

@nicomiguelino we could perhaps borrow a card out of the Proxmox playbook. That would cover both use cases.