Possibly some old configuration on your backend from the letsencrypt beforehand?

Are you referring to the original HTTPS configuration for Let’s Encrypt for domain.com? I haven’t disabled that yet. Should I entirely disable HTTPS for the Nextcloud server?

Have a look at your next cloud backend http logs to see what requests are arriving there and what HOST( http header ) it’s trying to connect to on that IP.

I’m not entriely sure where to find what you are referring to. I checked the Apache logs for Nextcloud, and I didn’t find anything.

Your first configuration results in the following when I access nextcluod.domain.com from both within and outside the LAN:

400 Bad Request
Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
 Instead use the HTTPS scheme to access this URL, please.

This is an interesting response, because it’s what I see when I try to access the server from 192.168.1.182:443 from within the LAN. Which, I assume, is to be expected when a port has TLS enabled – one should access it from 192.168.1.182:80 instead; however, when I modify your suggestion to be from port 80, rather than port 443, it results in the usual

301 Moved Permanently
Moved Permanently
The document has moved https://nextcloud.domain.com:443/

Your second configuration results in the following when I access nextcloud.domain.com from both within and outside the LAN:

Client sent an HTTP request to an HTTPS server.

Side note: I do still have the original HTTPS setup with Let’s Encrypt enabled on the Nextcloud server for domain.com. Is that causing the issue? I’d rather not disable that unless I need to, at the moment.

Here is the output of wget --spider https://nextcloud.domain.com:

Spider mode enabled. Check if remote file exists.
--2024-02-21 09:20:41--  https://nextcloud.domain.com/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving nextcloud.domain.com (nextcloud.domain.com)... public-ip
Connecting to nextcloud.domain.com (nextcloud.domain.com)|public-ip|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://nextcloud.domain.com:443/ [following]
Spider mode enabled. Check if remote file exists.
--2024-02-21 09:20:46--  https://nextcloud.domain.com/
Connecting to nextcloud.domain.com (nextcloud.domain.com)|public-ip|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://nextcloud.domain.com:443/ [following]
Spider mode enabled. Check if remote file exists.
--2024-02-21 09:20:46--  https://nextcloud.domain.com/
Connecting to nextcloud.domain.com (nextcloud.domain.com)|public-ip|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://nextcloud.domain.com:443/ [following]
Spider mode enabled. Check if remote file exists.
[...]
[I deleted a bunch of repetitions]
[...]
--2024-02-21 09:20:48--  https://nextcloud.domain.com/
Connecting to nextcloud.domain.com (nextcloud.domain.com)|public-ip|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://nextcloud.domain.com:443/ [following]
20 redirections exceeded.

And here is the contents of the cookie file (it is empty):

# Netscape HTTP Cookie File
# https://curl.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

Running curl --location https://nextcloud.domain.com results in

curl: (47) Maximum (50) redirects followed

I’m not exactly sure what the previous issue was, but it appears that, possibly, the previous bridge that was in use was broken in some way. I have since switched the primary router to one that supports WDS, and created a WDS bridge between the two, and now everything is working as expected.

Fair points! I hadn’t considered these nuances.

Did you forget to complete your reply, or did it perhaps glitch out?

Indeed it is not. Do you, by chance, have any suggestions – troubleshooting, alternatives, etc.?

[…] so there are other possibilities than a standard desktop computer.

Would you mind elaborating? I’m curious to know what you’re referring to.

The fact that it’s a “single board” computer, specifically, is mildly irrelevant, imo; just follow standard backup practices. The only way the type of computer really comes into question is whether or not it has adequate resources to run whatever backup solution that you choose. For my usecase, Borg works great, but choose whatever solution fits your requirements. The “simplest”, and lightest solution is probably rsync, but that may leave a lot to be desired.

What issues did you have with the AIO docker?

Well dang, I have Nextcloud installed as a snap (which has been perfectly stable for me when running on Ubuntu Server), but I was thinking of switching over to a docker installation; this thread doesn’t exactly fill me with enthusiasm for that idea…

I’m assuming it stays in the RAM till the time the computer shuts downs

Correct.

We know that one could, in theory, get a dump of the contents of the RAM in such a state, if done correctly.

An example of such an attack would a “cold boot attack”.

Is there some way to insert the USB, decrypt the drive, and then remove the USB and all traces of the key from the system?

It sort of depends on how the underlying hardware is designed. You can create a system in which the RAM’s contents are encrypted by the hardware, but at some point the data must be decrypted for use. For example, one could theoretically sniff the data-lines between the RAM, and the CPU. This is all of course ignoring the fact that the hardware, itself, could be compromised i.e. Intel M.E., backdoors/vulnerabilities in the BIOS, etc. There’s lots that can be done to try to mitigate security vulnerabilites, but there is always a tradeoff between security, and convenience.

Maybe the best form of security is memorizing a private key, then manually doing the math with a pen and paper to decrypt some text, and transmit it with a carrier pigeon.