Right. Of course it’s just the regular way you set environment variables. So I guess I’ll set up a bash script that sets the variables and then launches caddy. Does Caddy look for CLOUDFLARE_EMAIL and
CLOUDFLARE_API_KEY?
I may be blind, but I’m not seeing exactly where you set which DNS challenge provider you’re using.
If you’re using the shim (the module that supports ~75 DNS providers from acme-go/lego), their documentation on which env vars they look for is here: DNS Providers :: Let’s Encrypt client and ACME library written in Go.
If you’re using the upgraded modules, it takes its data from the Caddyfile, which can take it from any env var you like, although CLOUDFLARE_API_TOKEN is given by way of example: GitHub - caddy-dns/cloudflare: Caddy module: dns.providers.cloudflare
Wait, so do I just copy this to the top of my Caddyfile?
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
I’m a little confused, because I’m just trying to get this undockerized version of caddy to work like my dockerized version was working.
What was your full, Dockerized Caddyfile? However you configured DNS validation previously, that’s how you should keep doing it now.
Actually, wait. You’re just using stock Caddy v2. It doesn’t come with DNS provider modules by default.
None of your Caddyfiles from near the start of this thread had DNS validation configured, either. Why do you need Cloudflare credentials? Caddy isn’t using them (or shouldn’t be, based on what you’ve posted).
1 Like
{
#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:6875
}
start.{$DOMAIN} {
reverse_proxy dashmachine:5000
}
watch.{$DOMAIN} {
reverse_proxy peertube:9000
}
I thought it was because Cloudflare is my cert provider. My Docker caddy config is working, but my non-Docker config isn’t, so I figured it was because it needed Cloudflare credentials.
This is whole thing is just to get the master version of Caddy so I can get better debug output, like @matt was telling me to do.
Nope.
You’ve been giving your Docker container your Cloudflare credentials, but doing nothing with them. To enable the DNS challenge, you need to use the tls directive / dns subdirective:
- dns enables the DNS challenge using the specified provider plugin, which must be plugged in from one of the caddy-dns repositories. Each provider plugin may have their own syntax following their name; refer to their docs for details. Maintaining support for each DNS provider is a community effort. Learn how to enable the DNS challenge for your provider at our wiki.
That means the Docker container has been maintaining certs using HTTP or TLS-ALPN challenges.
Which, in turn, means that you’ve got some other issue going on when you run it manually. Lets walk back to here:
What, specifically, is telling you that Caddy failed to get certs because of a lack of Cloudflare credentials? Was it some output from the Caddy command that indicated this?
I suspect a closer look at the output might give a better idea of what actually failed.
2 Likes
Ok. It keeps giving me variations of 2020/05/21 19:19:37 http: TLS handshake error from 91.121.101.53:54026: no certificate available for host.domain.tld for every one of my domains, like this:
2020/05/21 19:19:34 http: TLS handshake error from 91.121.101.53:53798: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:37 http: TLS handshake error from 91.121.101.53:54026: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:45 http: TLS handshake error from 91.121.101.53:54626: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:49 http: TLS handshake error from 91.121.101.53:54850: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:52 http: TLS handshake error from 91.121.101.53:55074: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:55 http: TLS handshake error from 91.121.101.53:55306: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:59 http: TLS handshake error from 194.182.166.141:44394: no certificate available for 'watch.haddock.cc'
2020/05/21 19:20:03 http: TLS handshake error from 91.121.101.53:55834: no certificate available for 'watch.haddock.cc'
2020/05/21 19:20:06 http: TLS handshake error from 91.121.101.53:56050: no certificate available for 'watch.haddock.cc'
2020/05/21 19:20:09 http: TLS handshake error from 91.121.101.53:56296: no certificate available for 'watch.haddock.cc'
2020/05/21 19:20:27 http: TLS handshake error from 192.168.50.1:41361: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:32 http: TLS handshake error from 172.58.45.202:62051: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:33 http: TLS handshake error from 172.58.45.202:19586: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:33 http: TLS handshake error from 172.58.45.202:54462: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:33 http: TLS handshake error from 172.58.45.202:21718: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:35 http: TLS handshake error from 192.168.50.1:42929: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:35 http: TLS handshake error from 192.168.50.1:44181: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:37 http: TLS handshake error from 192.168.50.1:40291: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:37 http: TLS handshake error from 192.168.50.1:39641: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:37 http: TLS handshake error from 192.168.50.1:43677: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:38 http: TLS handshake error from 192.168.50.1:43412: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:38 http: TLS handshake error from 192.168.50.1:43414: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:42 http: TLS handshake error from 192.168.50.1:39643: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:54 http: TLS handshake error from 116.202.14.219:50736: no certificate available for 'watch.haddock.cc'
2020/05/21 19:21:10 http: TLS handshake error from 192.168.50.1:39646: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:21:51 http: TLS handshake error from 99.149.215.66:37226: no certificate available for 'watch.haddock.cc'
2020/05/21 19:21:58 http: TLS handshake error from 91.121.101.53:56882: no certificate available for 'watch.haddock.cc'
2020/05/21 19:22:07 http: TLS handshake error from 69.30.230.122:38286: no certificate available for 'watch.haddock.cc'
2020/05/21 19:22:13 http: TLS handshake error from 192.168.50.1:39647: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:22:30 http: TLS handshake error from 51.91.68.227:50036: no certificate available for 'watch.haddock.cc'
You need to go back to the very start of those logs. Or even post the entire log.
There will be output from when Caddy first starts up where it attempts to retrieve those certificates. When it does that, the output will tell you what is happening, and often exactly why.
Ok. Here’s everything up until now:
2020/05/22 02:19:31.127 INFO using provided configuration {"config_file": "/home/cassidy/docker/shared/Caddyfile", "config_adapter": ""}
2020/05/22 02:19:31.128 INFO admin admin endpoint started {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", "127.0.0.1:2019"]}
2020/05/22 02:19:31.129 INFO http server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2020/05/22 02:19:31.129 INFO http enabling automatic HTTP->HTTPS redirects {"server_name": "srv0"}
2020/05/21 19:19:31 [INFO][cache:0xc00064b8b0] Started certificate maintenance routine
2020/05/22 02:19:31.129 INFO tls cleaned up storage units
2020/05/22 02:19:31.129 INFO autosaved config {"file": "/root/.config/caddy/autosave.json"}
2020/05/22 02:19:31.129 INFO serving initial configuration
Successfully started Caddy (pid=8596) - Caddy is running in the background
2020/05/21 19:19:34 http: TLS handshake error from 91.121.101.53:53798: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:37 http: TLS handshake error from 91.121.101.53:54026: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:45 http: TLS handshake error from 91.121.101.53:54626: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:49 http: TLS handshake error from 91.121.101.53:54850: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:52 http: TLS handshake error from 91.121.101.53:55074: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:55 http: TLS handshake error from 91.121.101.53:55306: no certificate available for 'watch.haddock.cc'
2020/05/21 19:19:59 http: TLS handshake error from 194.182.166.141:44394: no certificate available for 'watch.haddock.cc'
2020/05/21 19:20:03 http: TLS handshake error from 91.121.101.53:55834: no certificate available for 'watch.haddock.cc'
2020/05/21 19:20:06 http: TLS handshake error from 91.121.101.53:56050: no certificate available for 'watch.haddock.cc'
2020/05/21 19:20:09 http: TLS handshake error from 91.121.101.53:56296: no certificate available for 'watch.haddock.cc'
2020/05/21 19:20:27 http: TLS handshake error from 192.168.50.1:41361: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:32 http: TLS handshake error from 172.58.45.202:62051: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:33 http: TLS handshake error from 172.58.45.202:19586: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:33 http: TLS handshake error from 172.58.45.202:54462: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:33 http: TLS handshake error from 172.58.45.202:21718: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:35 http: TLS handshake error from 192.168.50.1:42929: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:35 http: TLS handshake error from 192.168.50.1:44181: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:37 http: TLS handshake error from 192.168.50.1:40291: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:37 http: TLS handshake error from 192.168.50.1:39641: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:37 http: TLS handshake error from 192.168.50.1:43677: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:38 http: TLS handshake error from 192.168.50.1:43412: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:38 http: TLS handshake error from 192.168.50.1:43414: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:42 http: TLS handshake error from 192.168.50.1:39643: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:20:54 http: TLS handshake error from 116.202.14.219:50736: no certificate available for 'watch.haddock.cc'
2020/05/21 19:21:10 http: TLS handshake error from 192.168.50.1:39646: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:21:51 http: TLS handshake error from 99.149.215.66:37226: no certificate available for 'watch.haddock.cc'
2020/05/21 19:21:58 http: TLS handshake error from 91.121.101.53:56882: no certificate available for 'watch.haddock.cc'
2020/05/21 19:22:07 http: TLS handshake error from 69.30.230.122:38286: no certificate available for 'watch.haddock.cc'
2020/05/21 19:22:13 http: TLS handshake error from 192.168.50.1:39647: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:22:30 http: TLS handshake error from 51.91.68.227:50036: no certificate available for 'watch.haddock.cc'
2020/05/21 19:23:22 http: TLS handshake error from 148.251.134.157:48684: no certificate available for 'watch.haddock.cc'
2020/05/21 19:23:24 http: TLS handshake error from 66.249.64.113:56624: no certificate available for 'git.haddock.cc'
2020/05/21 19:24:08 http: TLS handshake error from 116.203.17.124:59378: no certificate available for 'watch.haddock.cc'
2020/05/21 19:25:38 http: TLS handshake error from 192.168.50.1:43448: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:25:38 http: TLS handshake error from 192.168.50.1:43450: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:25:43 http: TLS handshake error from 192.168.50.1:39649: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:25:43 http: TLS handshake error from 192.168.50.1:39648: no certificate available for 'cloud.haddock.cc'
2020/05/21 19:26:53 http: TLS handshake error from 194.182.165.8:38534: no certificate available for 'watch.haddock.cc'
Hmm. It just didn’t do anything. At all.
Was that the log from the very first time you ran it outside of Docker?
I’m curious, if you take it down, replace instances of {$DOMAIN} with your actual domain name in the Caddyfile, and start it up again, does that change anything at all?
It’s possible that it’s not able to find my docker containers. All of the hostnames in my Caddyfile are the name’s of their respective container. Would Caddy running on bare metal be able to find those containers on the network?
That’s orthogonal to our issue here, which is that Caddy doesn’t seem to be fetching HTTPS certificates.
You could replace all the reverse proxies with respond 403 "F#@$ OFF!" and it wouldn’t matter; we’re not even getting to that stage. The (lack of) certificates need to be troubleshooted before Caddy will even serve the site properly.
Ok it seems I was right about that. It’s saying No such host
2020/05/21 19:40:00 [INFO][git.haddock.cc] Obtain: Releasing lock
2020/05/22 02:40:06.771 ERROR http.log.error dial tcp: lookup dashmachine on 192.168.50.1:53: no such host {"request": {"method": "GET", "uri": "/", "proto": "HTTP/2.0", "remote_addr": "192.168.50.1:43500", "host": "start.haddock.cc", "headers": {"Dnt": ["1"], "Te": ["trailers"], "User-Agent": ["Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0"], "Accept": ["text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"], "Accept-Language": ["en-US,en;q=0.5"], "Accept-Encoding": ["gzip, deflate, br"], "Cookie": ["remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6IkpKUHFqUW1GTEZQbVRrTnpVQ29kUUE9PSIsInZhbHVlIjoicThwRHk5Z1o0UDBpOURqQnBqZTJvaVwvY2F6cElTbXJBVERta2poaWZ6QjdsVzFPMUc1NGFaZENEb3E2QUk1Q3Y3ME1UZ1BaRDVGM3owZHQ2bENWS2xBUFNmeDVXY1VIUXEyTjJaTEJ0YUJsREErZlJRR0JaY25vbzdYWkVIMklFV0ZPMElGSVlKZzNkYnh0Zk9TM1Q0ZlNDM29wWTFLb3lxeVNIanFWYUVUUT0iLCJtYWMiOiI5ODM1Y2Q5Njk0ZmE4YjQwNjc2MjA2YzBlZDIzODYyYTU4NjA1MTJlMGNkMmUyYjMzMWYwMTllYzc1NTZlZjk1In0%3D; remember_token=1|520634d2722f87583ac30ad7eb56234974a36cb2e6bbd1b4b388ae9b5481324aeeef4c14e29f7b162faf6acad50f6cdfddb6ed7246afd29b809155023553cd54; session=.eJwlzkFuAzEIheG7eJ0FtjGYXGYEBtQqVSvNtKsqd4-lLN-_ePr-y5FnXB_lnvp1xa0cn17uZTRb6YnWEhy8zrFQajRdHWZLbC6hNHaePGbXbJ6rKzEKqw9etQ43h6CZJGLQASeZEUpzG0oyRUcaOXOEARuCz-DFCVCblA35u-J8a-qe6zrz-P15xPcOlFVBlyFjt2DoW7nvW6cZS9hVUMzYyvMFiXhAbg.Xsca3w.c_0g3WepoVo37YpqDntdb6mtI1w"], "Upgrade-Insecure-Requests": ["1"]}, "tls": {"resumed": false, "version": 772, "ciphersuite": 4865, "proto": "h2", "proto_mutual": true, "server_name": "start.haddock.cc"}}, "duration": 0.088063739, "status": 502, "err_id": "dupkbnsnd", "err_trace": "reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:380)"}
2020/05/22 02:40:06.860 ERROR http.log.error dial tcp: lookup dashmachine on 192.168.50.1:53: no such host {"request": {"method": "GET", "uri": "/favicon.ico", "proto": "HTTP/2.0", "remote_addr": "192.168.50.1:43500", "host": "start.haddock.cc", "headers": {"User-Agent": ["Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0"], "Accept": ["image/webp,*/*"], "Accept-Language": ["en-US,en;q=0.5"], "Accept-Encoding": ["gzip, deflate, br"], "Cookie": ["remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6IkpKUHFqUW1GTEZQbVRrTnpVQ29kUUE9PSIsInZhbHVlIjoicThwRHk5Z1o0UDBpOURqQnBqZTJvaVwvY2F6cElTbXJBVERta2poaWZ6QjdsVzFPMUc1NGFaZENEb3E2QUk1Q3Y3ME1UZ1BaRDVGM3owZHQ2bENWS2xBUFNmeDVXY1VIUXEyTjJaTEJ0YUJsREErZlJRR0JaY25vbzdYWkVIMklFV0ZPMElGSVlKZzNkYnh0Zk9TM1Q0ZlNDM29wWTFLb3lxeVNIanFWYUVUUT0iLCJtYWMiOiI5ODM1Y2Q5Njk0ZmE4YjQwNjc2MjA2YzBlZDIzODYyYTU4NjA1MTJlMGNkMmUyYjMzMWYwMTllYzc1NTZlZjk1In0%3D; remember_token=1|520634d2722f87583ac30ad7eb56234974a36cb2e6bbd1b4b388ae9b5481324aeeef4c14e29f7b162faf6acad50f6cdfddb6ed7246afd29b809155023553cd54; session=.eJwlzkFuAzEIheG7eJ0FtjGYXGYEBtQqVSvNtKsqd4-lLN-_ePr-y5FnXB_lnvp1xa0cn17uZTRb6YnWEhy8zrFQajRdHWZLbC6hNHaePGbXbJ6rKzEKqw9etQ43h6CZJGLQASeZEUpzG0oyRUcaOXOEARuCz-DFCVCblA35u-J8a-qe6zrz-P15xPcOlFVBlyFjt2DoW7nvW6cZS9hVUMzYyvMFiXhAbg.Xsca3w.c_0g3WepoVo37YpqDntdb6mtI1w"], "Dnt": ["1"], "Te": ["trailers"]}, "tls": {"resumed": false, "version": 772, "ciphersuite": 4865, "proto": "h2", "proto_mutual": true, "server_name": "start.haddock.cc"}}, "duration": 0.002542183, "status": 502, "err_id": "zy11wdism", "err_trace": "reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:380)"}
2020/05/22 02:40:19.705 ERROR http.log.error dial tcp: lookup gitea on 192.168.50.1:53: no such host {"request": {"method": "GET", "uri": "/", "proto": "HTTP/2.0", "remote_addr": "192.168.50.1:43502", "host": "git.haddock.cc", "headers": {"Accept": ["text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"], "Accept-Language": ["en-US,en;q=0.5"], "Accept-Encoding": ["gzip, deflate, br"], "Upgrade-Insecure-Requests": ["1"], "Cookie": ["i_like_gitea=b5284520ae7c1382; lang=en-US"], "Te": ["trailers"], "User-Agent": ["Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0"]}, "tls": {"resumed": false, "version": 772, "ciphersuite": 4865, "proto": "h2", "proto_mutual": true, "server_name": "git.haddock.cc"}}, "duration": 4.150446666, "status": 502, "err_id": "6n6dpqspf", "err_trace": "reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:380)"}
2020/05/22 02:40:19.809 ERROR http.log.error dial tcp: lookup gitea on 192.168.50.1:53: no such host {"request": {"method": "GET", "uri": "/favicon.ico", "proto": "HTTP/2.0", "remote_addr": "192.168.50.1:43502", "host": "git.haddock.cc", "headers": {"User-Agent": ["Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0"], "Accept": ["image/webp,*/*"], "Accept-Language": ["en-US,en;q=0.5"], "Accept-Encoding": ["gzip, deflate, br"], "Cookie": ["i_like_gitea=b5284520ae7c1382; lang=en-US"], "Te": ["trailers"]}, "tls": {"resumed": false, "version": 772, "ciphersuite": 4865, "proto": "h2", "proto_mutual": true, "server_name": "git.haddock.cc"}}, "duration": 0.003469364, "status": 502, "err_id": "sq8h5tqnv", "err_trace": "reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:380)"}
2020/05/22 02:40:20.733 ERROR http.log.error dial tcp: lookup gitea on 192.168.50.1:53: no such host {"request": {"method": "GET", "uri": "/serviceworker.js", "proto": "HTTP/2.0", "remote_addr": "192.168.50.1:43502", "host": "git.haddock.cc", "headers": {"Accept": ["*/*"], "Service-Worker": ["script"], "Pragma": ["no-cache"], "Cache-Control": ["no-cache"], "User-Agent": ["Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0"], "Accept-Language": ["en-US,en;q=0.5"], "Accept-Encoding": ["gzip, deflate, br"], "Cookie": ["i_like_gitea=b5284520ae7c1382; lang=en-US"], "Te": ["trailers"]}, "tls": {"resumed": false, "version": 772, "ciphersuite": 4865, "proto": "h2", "proto_mutual": true, "server_name": "git.haddock.cc"}}, "duration": 0.003534664, "status": 502, "err_id": "a9wfzuxj8", "err_trace": "reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:380)"}
It seems replacing $DOMAIN with my actual domain worked liked you said as well. So that’s progress.
Alright, so now we have certs. And the only change you implemented was to use labels directly in the Caddyfile instead of the DOMAIN env var.
I’m reluctant to pin that issue on some problem with Caddyfile parsing and variable replacement.
Instead, can you check - did you set your DOMAIN var outside of Docker before running Caddy? The lack of variable there could have been causing a lack of certificate fetching and then TLS handshake errors, since Caddy would’ve been “reading” site labels like just wiki. and media. etc (just single words, no registered domain) if the variable was empty.
Yeah I never set environment variables outside Docker and for some reason assumed it would just work. That’s on me for forgetting that part.
Alright. So we’re out of Docker, we have certs, and we’re live.
Next step: exposing Nextcloud so Caddy can proxy to it. As you noted, outside of Docker, there’s no routable address nextcloud:443, which your current Caddyfile points to.
However, I note in your first docker-compose.yml in this thread you already have Nextcloud’s port 80 exposed as port 8080 on the host.
That means you should be able to change that from nextcloud:443 to localhost:8080 to talk to Nextcloud’s HTTP endpoint.
While I’m at it all remove all the other services from my Caddyfile to make things easier to troubleshoot.
That would make things very simple indeed!
When reproducing issues, the minimum amount of configuration required to recreate that issue is always helpful. It reduces noise from other configuration and makes it easy to narrow down the actual cause.
It seems to be slowly moving through my domains:
2020/05/21 19:55:32 http: TLS handshake error from 116.203.17.124:55644: no certificate available for 'watch.haddock.cc'
I’ll wait to see if it ever gets to Nextcloud.