Setting up SSL for self-hosted instance

[nshki]

Hi all. I've been going through the process of setting up a self-hosted instance and wanted to enable SSL so that it won't ever be accessible without network encryption. The server is seemingly running fine, but I can't seem to actually hit the server via a URL. Here are the steps I've taken so far:

1. Issued new certificates from Let's Encrypt.
2. Symlinked the relevant certificate and private key in server/credentials/tls.cert and server/credentials/tls.key.
3. Added 443:443 as a list item in compose.yaml for services.museum.ports so that the SSL port defers to Docker.
4. Added the following to museum.yaml:

   http:
     use-tls: true

5. Created black-friday.json, in-testing.json, and us-testing.json under server/data/billing all with an empty JSON: {}. This was after I learned that these files are required when enabling TLS mode.
6. Changed the log.Fatal(server.RunTLS(":443", certPath, keyPath)) line to just server.RunTLS(":443", certPath, keyPath) so that the server won't error out each time it's started.
7. Added a GIN_MODE: release to the services.museum.environment env vars.

Now when I docker compose up, I get a "We have lift-off" success log message from the museum container, but when I run curl https://<mydomain>/ping, I get a Failed to connect to <mydomain> port 443 after <x> ms: Couldn't connect to server.

I've also double-checked that my port forwarding on my router is correct. WAN port 443 is forwarding to the relevant machine's port 443.

Perhaps my approach is not recommended and/or completely wrong? Would appreciate any pointers if anyone has any.

[mnvr]

Perhaps my approach is not recommended and/or completely wrong?

Nothing wrong in your approach, I think these are all just network configuration issues.

Steps 4, 6 and 7 shouldn't be required. Instead, all you need to do is set the ENVIRONMENT=production environment variable when starting museum. This variable decides which "configuration" is used. By default, the server runs in a "local" configuration (i.e. it uses configurations/local.yaml), but in production we want it to use configurations/production.yaml. Also, setting ENVIRONMENT to anything other than "local" or the empty string will turn off various if conditions.

But those steps are not related to your problem (that is, it should work even the way you're doing it). I think the issue is just that the port 443 is not getting mapped correctly. I can't tell you where exactly is the problem, but I can maybe rubber duck so that you could try things to debug where is the network issue:

• Since you're getting the "We have lift-off" message, then museum is actually running and listening somewhere.
• Since you're getting the Couldn't connect to server message, it is not a TLS issue, the error would be different in that case. Here the issue is that nothing is just listening on the 443 of the IP you're connecting to.

There are 3 connection points

1. The IP:443 you're connecting to (your router)
2. The 443 on the machine your docker cluster is running
3. The 443 inside the docker cluster (where museum is listening)

Since you've already added 443:443 to your docker compose mapping, 2<->3 should be fine (but I will still double check by trying to do a https://localhost/ping on your machine itself, even if the connection fails because of TLS errors it should still connect to something and not time out).

If 2<->3 seems fine, then the problem would be 1<->2. Perhaps Docker is not listening on the network interface where your router is connecting to (0.0.0.0 is different from localhost).

I hope some of this helps!

[nshki]

Thank you for the quick reply! I went ahead and switched over to the ENVIRONMENT=production config and was able to get some more helpful error messages. I went through some steps to make sure that the permissions on the Let's Encrypt certificate and key were correct (0644 and 0600, respectively) and then had to add a couple additional configs in museum.yaml:

webauthn:
  rporigins: ["<mydomain>"]

apps:
  public-albums: "https://<my-domain>"

However, now when I boot up the Compose services, I run into a slew of:

postgres-1         | 2024-04-19 07:59:59.265 UTC [1] LOG:  database system is ready to accept connections
minio-1            |
minio-1            |  You are running an older version of MinIO released 2 weeks before the latest release
minio-1            |  Update: Run `mc admin update ALIAS`
minio-1            |
minio-1            |
minio-1            | MinIO Object Storage Server
minio-1            | Copyright: 2015-2024 MinIO, Inc.
minio-1            | License: GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html>
minio-1            | Version: RELEASE.2024-03-30T09-41-56Z (go1.21.8 linux/arm64)
minio-1            |
minio-1            | API: http://172.24.0.2:3200  http://127.0.0.1:3200
minio-1            | WebUI: http://172.24.0.2:3201 http://127.0.0.1:3201
minio-1            |
minio-1            | Docs: https://min.io/docs/minio/linux/index.html
minio-1            | Status:         1 Online, 0 Offline.
minio-1            | STARTUP WARNINGS:
minio-1            | - The standard parity is set to 0. This can lead to data loss.
minio-provision-1  | Added `h0` successfully.
minio-provision-1  | Bucket created successfully `b2-eu-cen`.
minio-provision-1  | Bucket created successfully `wasabi-eu-central-2-v3`.
minio-provision-1  | Bucket created successfully `scw-eu-fr-v3`.
minio-provision-1 exited with code 0
postgres-1         | 2024-04-19 08:00:01.160 UTC [42] LOG:  could not receive data from client: Connection reset by peer
postgres-1         | 2024-04-19 08:00:01.162 UTC [41] LOG:  could not receive data from client: Connection reset by peer
museum-1 exited with code 0

Does this seem familiar at all? The Connection rest by peer is a bit harder to debug since it doesn't point to any lines of code in the repo.

[roughnecks]

Why don't you set up a reverse proxy and leave localhost:8080 alone?

[mnvr]

Does this seem familiar at all?

What's happening is that when you run with ENVIRONMENT=production, museum no longer logs to stdout, which is why you're no longer seeing the reason it stopped in the docker logs. Instead, now museum logs to /var/logs/museum.log (as configured here).

Note that this path is within the docker container, so you'll need to either map it to something on your local machine, or attach to the running container to see the contents of the log. In the default docker compose setup, this path points to a custom docker volume (see this line), so you can see the log by peeking into that volume, e.g. by creating a temporary container that mounts it and runs a shell command:

docker run -it --rm -v ente_custom-logs:/vol alpine ls -l /vol

If that is too confusing, you can also just temporarily replace the mount point in the compose file to point to somewhere in your local directory so that the log file gets generated directly on your filesystem, eg. by changing custom-logs:/var/logs to ./logs:/var/logs.

---

Once you can see the logs, you'll be able to find the reason why museum is failing to start.

[nshki]

Thank you both for the input. After digging some more, I ended up setting up a reverse proxy as @roughnecks suggested and that worked seamlessly. If I'm feeling extra spicy, I'll continue digging into enabling SSL via the repo, but for now I think I'll continue using a reverse proxy.

[toxl]

Hi @nshki

could you explain (or link to the solution) how you set it up?
THX!

[nshki]

Sure, I landed on Caddy as the solution. Their documentation is excellent so it's hopefully enough to get you going!

[wrobelda]

For the record, I found setting up TLS actually fairly straightforward. I created a PR that adds necessary info to the compose.yaml and museum.yaml when using quickstart.sh script: #5828