ok, i deactivated the option âDo not trust system certificatesâ in DAVx5, i guess now the confirmation requests for certificate in the calendar wonât come any more
Itâs not about security. Itâs about ressources. The difference is 1000 or more log entries per hour without filter vs zero to 10 a day with filter. Without filter, we have to add CPU and RAM to the VM to keep it working.
We use the Nextcloud AIO without additional reverse proxy. We assumed this is the âAIOâ idea.
What reverese proxy whould you recommend for small footprint?
all-in-one/reverse-proxy.md at main · nextcloud/all-in-one · GitHub mentions âCaddy, Nginx, Apache, Traefik, HAProxy, etc.â
Iâm a fan of Caddy, but if youâre already familiar with one of the other reverse proxies, thatâs fine too. A reverse proxy generally doesnât consume many resources on its own, although it obviously depends on how much traffic youâre handling and just how resource-constrained your system actually is.
In your case, if port 443 is GeoBlocked and therefore canât be used for automatic certificate renewal via TLS-ALPN, you could try something like this:
- Forward both ports 80 and 443 to your server.
- Install Caddy and Certbot (standalone mode) on the server.
- Start AIO with:
--env APACHE_PORT=11000 \
--env APACHE_IP_BINDING=127.0.0.1
Then obtain the certificate using Certbot and the HTTP challenge:
certbot certonly --standalone --preferred-challenges http -d aio.yourdomain.tld
And use a Caddyfile similar to this:
{
# General Options
auto_https disable_certs
}
aio.yourdomain.tld:443 {
reverse_proxy 127.0.0.1:11000
tls /path/to/certs/aio.yourdomain.tld.crt /path/to/certs/aio.yourdomain.tld.key
}
You may need to adjust file permissions, configure ACLs, or use a deploy hook in Certbot to copy the certificates to a location where Caddy can read them, as well as reload or restart Caddy after the certificates are renewed. But that should be manageable.
With this setup, nothing is permanently listening on port 80. Caddy only listens on port 443 and proxies requests to the AIO instance running on port 11000. Certbot only starts a temporary web server on port 80 when obtaining or renewing certificates.
So you can leave port 80 open permanently, and outside of certificate issuance or renewal, requests to it will simply time out because nothing is listening there.
Personally, I still think using AIOâs built-in ACME supportâor, in this case, Caddyâs built-in ACME supportâis the cleaner solution. But if GeoBlocking on port 443 is a concern and you donât want Caddy to listen permanently on port 80, this approach should work as well.
Alternatively, you could also use a DNS challenge if your DNS provider supports it, either with Certbot, another ACME client, or by building Caddy with the appropriate DNS challenge plugin. In that case, you wouldnât need to open any ports at all.
Maybe this community container is an option too: all-in-one/community-containers/caddy at main · nextcloud/all-in-one · GitHub
Or, of course, âââ this âââ 
And maybe itâs even possible to use the HTTP challenge directly with Caddy as well, without having it listen permanently on port 80. Iâve never tried that myself, though, because as I mentioned in my reply to @egc, I donât really see port 80 as a security concern when all traffic is properly redirected to HTTPS, which Caddy does by default.
However,in your case, it might be worth testing what happens if you simply use something like this in your Caddy configuration:
aio.yourdomain.tld:443 {
reverse_proxy 127.0.0.1:11000
}
Or, if youâre using the community container in the same Docker stack, you could probably use something like:
reverse_proxy container_name
Ideally, Caddy would then behave similarly to Certbot: use port 80 only when performing the HTTP challenge, but otherwise not listen on port 80 at all. That would make things extremely simple, since you wouldnât need a separate ACME client, and port 80 would effectively be unused except during certificate renewals.
However, I havenât tested this myself, so I canât say for sure whether it works that way.
âŠand If permanently serving port 80 with a redirect to HTTPS isnât a concern for you, itâs even simpler, as the following is really all you need:
aio.yourdomain.tld {
reverse_proxy 127.0.0.1:11000
}
Caddy will automatically obtain and renew the certificates vai HTTP challenge (port 80), redirect HTTP requests to HTTPS, and proxy the requests to your AIO instance.
EDIT: Ah dang, that obviously isnât an option for your case, because with that you would also have to GeoBlock port 80, which in turn could cause the HTTP challenge to fail, which is exactly your problem in the first place. 
So just ignore this post and refer back to the previous ones.
AIO update to v13.2.1 has reverted the acme profile from shortlived to tlsserver.
That should silence the cert warning from âstandalone-signalingâ too.
I configured a own caddy reverse proxy for testing and found out that the tls option accepts a crt and key. So we can use the cheap wildcard cert that we have anyway.
I have installed caddy on the same machine where the docker containers are running. Not in a container, just âapt install caddyâ. Is this a security problem? We use a separate debian vm for each Nextcloud AIO instance, running the docker containers.