"The page isn’t redirecting properly" when runn

Gonna tag @matt in on this one, should this be a breaking error? HTTP on port 443 is pretty stupid, yes, but still technically functional. In this case the only thing stopping this from working fine is the parsing error itself.

And the rest of my pages aren’t working

Yeah, that’s intentional. I believe it was the same way in Caddy 1 too.

Oh, so what do I do to fix it?

Simple: Change the port to anything else, or use https://.

So, as your Nextcloud instance appears to be listening for HTTP on port 443, and Caddy is opinionated against allowing HTTP upstreams on default HTTPS port, your Nextcloud installation is not supported by Caddy.

Best bet to get things running from here would be to go to Linuxserver, the maintainers of your Nextcloud image, and sort out how to fix your container so that it either accepts traffic on port 80 without issue, or listens to HTTPS instead of HTTP on port 443.

2 Likes

How was I able to get it to work outside Docker then? Can’t I try and replicate that?

It works because it hides the fact that Nextcloud is serving HTTP on port 443 from Caddy. Caddy doesn’t realise it because Docker is translating the port to 8443.

You can leave Caddy outside of Docker if you like and it’ll keep working fine.

That makes sense. I’ll create a post on the LinuxServer forums then.

@Whitestrake can you tell the LinuxServer people what you’re talking about in my thread? I’m not really sure how to explain it myself and they’re asking.

No worries. It can be a bit confusing.

Currently, your Nextcloud is listening to HTTP (i.e. no TLS) on port 443.

Ideally, it should listen to HTTPS (i.e. with TLS) on port 443. I am not sure why it isn’t.

They are telling you that, by default, the Nextcloud container does in fact listen on HTTPS. Yours for some reason is not exhibiting the default behaviour.

Feel free to link them to this post by way of explanation (click the timestamp up the top right of this post for a shareable link).

Thank you (:

@Whitestrake I don’t want to ask the Nextcloud people about this, but I’m getting the whole:

2020/06/05 21:24:42 http: TLS handshake error from 192.168.50.1:37575: no certificate available for 'cloud.haddock.cc'

and this after resetting /config/nginx/site-confs

@matt do you think maybe you could help me fix this one? (Sorry this is taking so long. Thanks for all your help).

Sorry, I don’t know or use NextCloud, so I won’t be of much help. If it’s uncharted territory you might have to figure it out on your own!

I’m not going to read all 100+ posts in this thread, but, the last log message you posted:

no certificate available for 'cloud.haddock.cc'

means that there isn’t any certificate loaded for that domain name, and/or Caddy isn’t configured to serve that domain.

You can read how automatic HTTPS works here: Automatic HTTPS — Caddy Documentation

Ok thank you. I’ll look into that.

Did you maybe revert your Caddyfile to some version without cloud.haddock.cc as a site label, when you were moving back to Caddy in Docker possibly? Definitely double check the site address is present so Caddy knows to fetch/load a cert for it.

Whoops. I’m dumb. I commented out the Nextcloud part of my Caddyfile. It now looks like this, but I’m back to getting the white screen. Ugh.

{
    #acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

cloud.{$DOMAIN} {
    reverse_proxy nextcloud:443
}

git.{$DOMAIN} {
    reverse_proxy gitea:3000
}
media.{$DOMAIN} {
    reverse_proxy jellyfin:8096
}

wiki.{$DOMAIN} {
    reverse_proxy bookstack:80
}

start.{$DOMAIN} {
    reverse_proxy dashmachine:5000
}

watch.{$DOMAIN} {
    reverse_proxy peertube:9000
}

admin.{$DOMAIN} {
    reverse_proxy keycloak:8080
}

Error message:

{"level":"error","ts":1591577516.0544076,"logger":"http.log.error","msg":"x509: certificate signed by unknown authority","request":{"method":"GET","uri":"/","proto":"HTTP/2.0","remote_addr":"192.168.50.1:41454","host":"cloud.haddock.cc","headers":{"Accept-Language":["en-US,en;q=0.5"],"Accept-Encoding":["gzip, deflate, br"],"Cookie":["__Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; oc_sessionPassphrase=jtGvwQ0k22QOmsGIjtQ9qY3MEURz04m8g90Jv29oH6qIV8Rqt6l2HcPf3tTHklOxFn0Iif3nw2YumdCRMskcwEFrMSZvobHzRxkYGR48gEfxC%2BU2fqtusxs5dko6k9ax; i18next=en-US; oc6mbe5vxaa7=hnb90f9hh1lktfn44p50i0h1cg; ocgiijrqfwz6=qkm9m4jmv2rkp9iadsg3lvnchr"],"Upgrade-Insecure-Requests":["1"],"Te":["trailers"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"]},"tls":{"resumed":false,"version":772,"ciphersuite":4865,"proto":"h2","proto_mutual":true,"server_name":"cloud.haddock.cc"}},"duration":0.065108629,"status":502,"err_id":"y8ywep0r9","err_trace":"reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:380)"}

Ahh, we’re getting somewhere! Previously it was an issue with sending HTTPS requests to a HTTP listener.

Now we see this: certificate signed by unknown authority. That means Nextcloud is now serving HTTPS on port 443, but it will be self-signed (untrusted).

You must configure Caddy to ignore the lack of trust. This is done with a transport subdirective block for your reverse_proxy.

Something like this:

    reverse_proxy nextcloud:443 {
        transport http {
                tls_insecure_skip_verify
        }
    }

reverse_proxy (Caddyfile directive) — Caddy Documentation

3 Likes