Allow to use it with local domains

[Emanuel-Bjurhager]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

1. Follow the install guide at https://github.com/nextcloud/all-in-one or https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
2. Go to Nextcloud AIO config at port 8080
3. Type the (local) domain name that will be used into "Please type in the domain that will be used for Nextcloud if you want to create a new instance:" field.
4. Wait for error "The server is not reachable on Port 443. You can verify this e.g. with 'https://portchecker.co/' by entering your domain there as ip-address and port 443 as port."

Expected behavior

It should be possible to use Nextcloud AIO local only without having it open from the outside.

Actual behavior

Because server is not public, it is not possible to continue setup

Host OS

Ubuntu Server 20.04.4 LTS

Nextcloud AIO version

Nextcloud AIO v1.4.1

Current channel

latest

Other valuable info

[phatpaul]

Is there just a way to bypass the domain setup part? I like the idea of this, but I already have the reverse proxy and SSL certs handled. I also just want to play with it locally before exposing it to the outside.

[gclawes]

If the all-in-one container needs to trust a custom CA, I could see 3 options:

1. Mount system root trust into the AIO container (assuming the system is debian-based, or system root trust is compatible with the one on the container)
2. Add the ability in AIO to disable TLS validation.
3. Add the ability to upload a custom CA cert to AIO.

[szaimen]

Seems like someone managed to deploy it locally already before the private ip-address check was introduced. See #745 (comment)

The private ip-address check will be removed again when running behind reverse proxies with #859

[dantefromhell]

Caddy supports auto-generation of TLS for "local domains" (would not cover the internal corporate network scenario). See chapter "Local HTTPS" https://caddyserver.com/docs/automatic-https
That could/ should help w/ the OPs scenario.

Self-signed certs can create problems w/ verification though, depending on where the client is located. If all TLS clients are in Browsers one can override the TLS errors manually. In case any of the containers initiates TLS requests to any other container things get complicated, as you either need to

1. include the custom root CA in every container that initiates TLS requests
2. Disable TLS verification (bad idea)

@szaimen
I am not sure I understand all bit & pieces of nextcloud-aio correctly, but there are situations in which one container attempts to use TLS to connect to another container, correct?

[szaimen]

I would prefer a solution like this: #745 (comment)
(it only needs to be documented correctly)

[dantefromhell]

I dont understand how does my question about TLS in between containers (and local domains) relates to internal IP addresses. Can you please elaborate?

[szaimen]

I am adding an option to disable the domain validation with #873. Not saying that it will automatically work afterwards with local domains but you may be a step closer figuring out what needs to be done. PRs are welcome!

[szaimen]

I will document how to get it running locally: #878