What's showing in /var/log/caddy.log?
Code:
2020/03/22 07:36:34 [INFO] Caddy version: v1.0.4 2020/03/22 07:36:34 /usr/local/www/Caddyfile:12 - Error during parsing: Unknown directive '...'
What's showing in /var/log/caddy.log?
2020/03/22 07:36:34 [INFO] Caddy version: v1.0.4 2020/03/22 07:36:34 /usr/local/www/Caddyfile:12 - Error during parsing: Unknown directive '...'
Wonderful summery.Well after a couple of days of head-scratching and lots of trial and error, I've finally managed to get danb35's Nextcloud script and Reverse Proxy using Caddy resource to play nicely together. I may not be using the correct jargon below, but hopefully, you'll get my drift.
For the purpose of this explanation, Caddy will be installed in the jail at 192.168.1.10 and Nextcloud installed in the jail at 192.168.1.20.
A new Nextcloud installation is assumed. Caddy will be set up with DNS validation.
Note: If you have an existing Nexcloud installation installed via dan35b's script, Blueether's post above will give you a clue as to what may have to change on the Nextcloud Caddyfile. Adjust the steps below accordingly.
A broad outline of the steps:
If you haven't already done so, add a CNAME record for the subdomain cloud.mydomain.com. The record should point cloud to mydomain.com. This step is done using your DNS provider (I use Cloudflare).- Using dan35b's Nextcloud script, install Nextcloud at IP 192.168.1.20. Importantly, set HOST_NAME="cloud.mydomain.com" and NO_CERT=1 in the script configuration file nextcloud-config.
- After installation, check that you can access the Nextcloud login page at http://192.168.1.20.
Forward ports 80 and 443 to the Caddy jail that will be located at 192.168.1.10 (I did this on my Fritz!Box modem router).- Install Caddy at jail IP 192.168.1.10 following danb35's resource Reverse Proxy using Caddy with the aim of setting up TLS with DNS validation.
- Make sure you add mydomain.com to your DNS resolver (e.g. hosts file. I use DNSMasq) so that it resolves to 192.168.1.10 inside your network.
- See below for how I set up Caddyfile so that https://mydomain.com reaches the Caddy landing page and https://cloud.mydomain.com reaches the Nextcloud login page.
- Restart the Caddy jail and test that communication is encrypted for the domain names on the local network. If you need to debug your Caddyfile, var/log/caddy.log may provide some clues.
Code:www.mydomain.com mydomain.com { tls { dns cloudflare } gzip root /usr/local/www/html/ } cloud.mydomain.com { tls { dns cloudflare } gzip proxy / 192.168.1.20/ { transparent } }
www.mydomain.com mydomain.com { tls { dns cloudflare } gzip root /usr/local/www/html/ } cloud.mydomain.com { tls { dns cloudflare } gzip proxy / 192.168.111.200/ { transparent } }
cloud.mydomain.com:80 192.168.111.200:80 {
There's your issue I think.Code:cloud.mydomain.de:80 192.168.111.200:80 {
cloud.mydomain.de
.Hmm, that would be pretty counter-intuitive as I was under the impression, the nextcloud jail is only talking via unsecured http with the caddy jail.There's your issue I think.cloud.mydomain.de
.
2020/03/25 19:46:56 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3563039725 2020/03/25 19:46:56 [ERROR][cloud.mydomain.com] failed to obtain certificate: acme: Error -> One or more domains had a problem: [cloud.mydomain.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for cloud.mydomain.com - check that a DNS record exists for this domain, url: (attemp> 2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] acme: Obtaining bundled SAN certificate 2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3563040055 2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] acme: Could not find solver for: tls-alpn-01 2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] acme: use http-01 solver 2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] acme: Trying to solve HTTP-01 2020/03/25 19:46:59 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3563040055 2020/03/25 19:46:59 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3563040055 2020/03/25 19:46:59 [ERROR][cloud.mydomain.com] failed to obtain certificate: acme: Error -> One or more domains had a problem: [cloud.mydomain.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for cloud.mydomain.com - check that a DNS record exists for this domain, url: (attemp> 2020/03/25 19:47:00 [INFO] [cloud.mydomain.com] acme: Obtaining bundled SAN certificate 2020/03/25 19:47:00 [ERROR][cloud.mydomain.com] failed to obtain certificate: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLi> 2020/03/25 19:47:01 failed to obtain certificate: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLimited :: Error creating new>
I just set one. You've crossed that out in your guide on page 5. Didn't thought that it would be necessary.Do you have a CNAME record for cloud with your DNS hosting provider?
It will take some time to propagate (possibly an hour or so - I can't recall exactly). See post #91.I just set one. You've crossed that out in your guide on page 5. Didn't thought that it would be necessary.
So far no change when opening https://cloud.mydomain.com
Just spotted this.As a side note, my own domain is a .de TLD, whenever I post mydomain.com it's just for example purpose
It will take some time to propagate (possibly an hour or so - I can't recall exactly). See post #91.
/** * List of trusted proxy servers * * If you configure these also consider setting `forwarded_for_headers` which * otherwise defaults to `HTTP_X_FORWARDED_FOR` (the `X-Forwarded-For` header). */ 'trusted_proxies' => array('203.0.113.45', '198.51.100.128'), /** * Headers that should be trusted as client IP address in combination with * `trusted_proxies`. If the HTTP header looks like 'X-Forwarded-For', then use * 'HTTP_X_FORWARDED_FOR' here. * * If set incorrectly, a client can spoof their IP address as visible to * Nextcloud, bypassing access controls and making logs useless! * * Defaults to 'HTTP_X_FORWARED_FOR' if unset */ 'forwarded_for_headers' => array('HTTP_X_FORWARDED', 'HTTP_FORWARDED_FOR'),
I don't believe this is necessary. I've not had to include lines in DNSMasq for the subdomains. My current understanding of how the Caddy resource works:add your subdomains, one entry per line:
Apparently it is, though only with a semi-supported "net"-plugin. I maybe switch to nginx as a reverse proxy.I wouldn't expect so, but that's probably a question for the Caddy forums.
truecommand.mydomain.com { tls { dns cloudflare } gzip proxy / http://10.1.1.21:8080 { insecure_skip_verify transparent websocket } }