_HTTPS required_ error attempting to connect to selkies ct in browser

[fiveangle]

After building and running openscad-selkies:trixie with compose, connecting in browser gives the error:

Error: This application requires a secure connection (HTTPS). Please check the URL.

Screenshot:

Re-establishing the connection via https results in a ERR_SSL_PROTOCOL_ERROR browser error. When I hit the "Back" button on the browser (to return to accessing via http) it showed an entire black frame with PLAY STREAM button centered, but clicking it returned to the first error screen above, except without the blue rectangle (but still had the https error text and blue vertically-centered "scroll widget" present (if that's what it is)).

Same result in these browsers (all macos Tahoe):
Brave 1.87.186
Chromium: 145.0.7632.45
Safari 26.2 (21623.1.14.11.9)

root@frigate:/var/lib/docker/volumes/openscad# uname -a; grep _FUL /etc/os-release;; docker --version; docker compose version
Linux frigate 6.14.11-5-pve #2 SMP PREEMPT_DYNAMIC PMX 6.14.11-5 (2025-12-15T08:44Z) x86_64 GNU/Linux
DEBIAN_VERSION_FULL=13.3
Docker version 29.2.1, build a5c7197
Docker Compose version v5.0.2
root@frigate:/var/lib/docker/volumes/openscad#

openscad-logs.txt

[t-paul]

You did neither share the URL used nor the docker command running the container, so there is no way of helping.

The documentation of the base image shows port 3000 for HTTP and 3001 for HTTPS (using a self-signed certificate).

Both connect fine on Linux, this error might be macOS specific, I can't help with that as Apple does not allow me to do that.

There also seems to be an issue with OpenSCAD not starting due to some library issue (double-conversion) but that's a separate issue.

[fiveangle]

"as Apple does not allow me to do that."

I don't follow.

launched via compose:

services:
    openscad-selkies:
        container_name: openscad
        ports:
            - 33333:3000
        volumes:
            - /var/lib/docker/volumes/openscad:/openscad
        image: openscad-selkies:trixie

url: http://localip:33333, then https://localip:33333, then back.

I can attempt to try connecting from a windows system, but the Brave and Chromium browsers codebases are pretty unified across platforms and this clearly isn't a certificate validation issue as it does attempt to connect. Will report further…

[t-paul]

As mentioned above, using 3000 would be plain http only, if your browser tries to enforce https, that won't work via the 3000 service.

If you set 33333:3001 you get a service that should work via https. This is still going to warn or maybe even block due to the self-signed certificate.

[fiveangle]

as I mentioned, it did not function using http. I don't know what you mean about the browser enforcing https. The screenshot I showed you was from the page at the docker container endpoint. nothing to do with the browser.

[t-paul]

Run: docker run -p 3000:3000 openscad-selkies - works fine, via http

Run: docker run -p 3001:3001 openscad-selkies - works fine, via https but gives a certificate warning

If you get this "https" error in the first case, that is something local prevent plain http request (e.g. firefox shows a big warning when filling out password fields on a http connection, something similar might be happening here where the browser decides some feature is not allowed via http).

You can switch to https but then you must use the 3001 port as shown above, you can't just change the URL to https.
(meaning the port on the container side, you can define 33333:3001 if you want to use https://localhost:33333 in the browser)

[t-paul]

Fixed the build issue, now OpenSCAD also works fine - needs a full rebuild of the image.

[fiveangle]

Thank you for your attempts to identify the issue, but I still believe there is something fundamentally missing here.

I've rebuilt with the latest from main and same identical result on http:

root@openscad:/var/lib/docker/volumes/openscad# cat docker-compose.yaml 
services:
    openscad-selkies:
        container_name: openscad
        ports:
            - 33333:3000
        volumes:
            - /var/lib/docker/volumes/openscad/data:/openscad
            - /var/lib/docker/volumes/openscad/config:/config
        image: openscad-selkies:trixie
root@openscad:/var/lib/docker/volumes/openscad#

Black viewport region momentarily flashes with a "Play Stream" button centered in the black viewport, which immediate disappears, then shows the error at the bottom of the viewport:

I changed port mapping in compose to:

ports:
  - 33333:3001

And it connects without issue:

I find it very difficult to believe that the error message presented in the black viewport within the browser window has anything to do with any https browser enforcement unless the enforcement is coming from within the contents of the container (e.g. setting strict https headers on some component). The behavior I detail here is identical on all default installed browsers on macos and windows 11 (edge, Brave, Chrome) and Windows 10 (Edge, Explorer, Chrome). By default none of the browsers enforce "https protocol upgrade" (although one could enable that, if desired, but alas, is not:

More interestingly, I'm very curious how you got it to work on http at all when it does not work for me with a vanilla macOS 26, macOS 10.8, Windows 10 H2, Windows 11, across every browser tested ? What unicorn OS/browser combination are you using?

Based on my observation, if I had changed my docker compose to expose the internal 3001 https port with my prior build, I am confident https would have worked prior to me opening this issue.

Can you provide a valid recipe where exposing a the internal 3000 to the docker host network will work, including the client-side configuration, because from what I'm seeing, it is either fundamentally broken from within, or requires very specific non-default settings for the client-side, which we could at least try and document somewhere within the project. Else, it would be best to simply abandon support for http if there's no way to communicate to users how to get it to work.

My goal is to place behind a reverse proxy running in same docker stack that will publish via OAuth/HTTPS with certs managed via letsencrypt cloudflare API dns challenge, so the extra https encode/decode is extraneous, but will move forward with that if http cannot be made to function (by configuring the reverse proxy to ignore invalid cert).

But something is missing here, it's just a mystery what it is : )

-=dave

[fiveangle]

Oh, poking around, I found that if I click the short vertical sky-blue bar on the left side of the viewport window, the selkies sidebar slides into view, but black viewport and error message remain:

I hope this proves to you that the browser is not specifically enforcing https on it's own (else none of the content would render).