Pihole, caddy and internal websites with ".local"

1. Caddy version (caddy version):

v2.4.5 h1:P1mRs6V2cMcagSPn+NWpD+OEYUYLIf6ecOa48cFGeUg=

2. How I run Caddy:

RPi 3 // Linux pidrive 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux

a. System environment:

raspbian, systemctl caddy.service

b. Command:

Paste command here.

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

pi@pidrive:/etc/caddy $ caddy fmt
# The Caddyfile is an easy way to configure your Caddy web server.
# Unless the file starts with a global options block, the first
# uncommented line is always the address of your site.
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace ":80" below with your
# domain name.

tls {

http://homeassistant.local {

http://uptime.local {

http://heimdall.local {

http://senec.local {

http://tar1090.local {

http://smokeping.local {

3. The problem I’m having:

I am running th epihole as our local DNS server and this works like a charm. But now I want to achive, that I can reach my local websites/servers (some are running on the docker host and some not) just by typing the url e.g. http://senec.local or http://heimdall.local

The url http://tar1090.local I can reach after I skipped the advise that is not a trusted site, and than the url changes to https without an valid certificate…

4. Error messages and/or full log output:

pi@pidrive:/etc/caddy $ sudo systemctl status caddy.service
● caddy.service - Caddy
Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-11-23 12:55:00 CET; 2 days ago
Docs: Welcome — Caddy Documentation
Main PID: 24527 (caddy)
Tasks: 11 (limit: 2063)
CGroup: /system.slice/caddy.service
└─24527 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

Nov 25 11:55:00 pidrive caddy[24527]: {“level”:“info”,“ts”:1637837700.380797,“logger”:“tls”,“msg”:“reloading managed certificate”,“identifiers”:[“senec.local”]}
Nov 25 11:55:00 pidrive caddy[24527]: {“level”:“info”,“ts”:1637837700.3810217,“logger”:“tls.renew”,“msg”:“certificate renewed successfully”,“identifier”:“heimdall.local”}
Nov 25 11:55:00 pidrive caddy[24527]: {“level”:“info”,“ts”:1637837700.3811467,“logger”:“tls.renew”,“msg”:“releasing lock”,“identifier”:“heimdall.local”}
Nov 25 11:55:00 pidrive caddy[24527]: {“level”:“info”,“ts”:1637837700.3819904,“logger”:“tls”,“msg”:“reloading managed certificate”,“identifiers”:[“heimdall.local”]}
Nov 25 11:55:00 pidrive caddy[24527]: {“level”:“warn”,“ts”:1637837700.3895543,“logger”:“tls”,“msg”:“stapling OCSP”,“error”:“no OCSP stapling for [senec.local]: no OCSP server specified in certificate”}
Nov 25 11:55:00 pidrive caddy[24527]: {“level”:“info”,“ts”:1637837700.3897347,“logger”:“tls.cache”,“msg”:“replaced certificate in cache”,“subjects”:[“senec.local”],“new_expiration”:1637880900}
Nov 25 11:55:00 pidrive caddy[24527]: {“level”:“warn”,“ts”:1637837700.390031,“logger”:“tls”,“msg”:“stapling OCSP”,“error”:“no OCSP stapling for [heimdall.local]: no OCSP server specified in certificate”}
Nov 25 11:55:00 pidrive caddy[24527]: {“level”:“info”,“ts”:1637837700.3901327,“logger”:“tls.cache”,“msg”:“replaced certificate in cache”,“subjects”:[“heimdall.local”],“new_expiration”:1637880900}
Nov 25 12:55:00 pidrive caddy[24527]: {“level”:“info”,“ts”:1637841300.3068342,“logger”:“tls”,“msg”:“cleaning storage unit”,“description”:“FileStorage:/var/lib/caddy/.local/share/caddy”}
Nov 25 12:55:00 pidrive caddy[24527]: {“level”:“info”,“ts”:1637841300.4138114,“logger”:“tls”,“msg”:“finished cleaning storage units”}

5. What I already tried:

I registerd the local urls, that I have defined as a reverse proxy in the Caddyfile, with the ip which is the RPI on which Caddy is running.
I also tried it with a file on the pihole
with the content
to route every .local-domain to the Caddyserver, but this also did not work.

I have also several external domains defined in the Caddyfile and they work all perfectly, but just the internal webistes/service do not work as expected.

6. Links to relevant resources:

Thanks for all your help and assistance.

Please upgrade to v2.4.6!

tls is a directive, so it must go within site blocks, otherwise the Caddyfile parser will think it’s a site with the domain tls and a directive internal, which is invalid.

proxy doesn’t exist in Caddy v2. It’s reverse_proxy.

transparent and websocket also no longer exist in Caddy v2. They are the default behaviour of reverse_proxy.

This also doesn’t exist in Caddy v2. What are you trying to do with this?

FYI, the .local TLD is typically used for mDNS (multicast DNS), most often by Apple devices to find eachother on the network. Reusing .local for other purposes can cause bad things to happen. I recommend using a different TLD, like .home.arpa which is reserved for home networking:

It’s not clear to me what’s not working, because I don’t see any evidence of errors, and you didn’t describe the symptoms. Please elaborate.

Also, please use code formatting when posting your logs or config, by using ``` triple backticks on the lines immediately before and after the text. It’s difficult to read your logs because they lost their formatting.

As I run apt update on my RPI I get the message that all packages are uptodate. And as I installed as it is written in the official documentation I do not know how to do this. Please assist.

Thanks for your advice concerning the lines tls, transparent and websocket in my Caddyfile, I made these entrys as I found this in other threads and just copied them :innocent: as I hoped that it would lead to success.

Ok, as a first test I changed the DNS entry in pihole from
heimdall.local to heimdall.fritz.box and direct this to the ip of my caddy server.

The “only” thing I want to achieve with the caddy server, that I can use all my internal services/urls like heimdall.fritz.box without that I have to remember on which port this docker container is listening.

The error I get is that the url cannot be retrieved and is not accessable.
I hope I could make clear what the problem is and what I would like to achieve.

You definitely should be getting 2.4.6 from the APT repo. Cloudsmith - Repositories - Caddy (caddy) - stable (stable) - Packages

Did you only run apt update, or did you also run apt upgrade? apt update only updates the list of packages and their versions, it won’t actually upgrade the packages. You need to run apt upgrade afterwards to do that.

You should always refer to the docs to know what’s currently valid.

Please make the request with curl -v and show us what you see.

Also, enable the debug global option in your Caddyfile. Add this at the top of the Caddyfile:


Then and check Caddy’s logs. See this section in the docs for the right command to get your logs, without them being truncated:

Ok, I just set up a new server, because for my RPI3 was no new version 2.4.6 at this moment available at the link you shared with me.

I changed my local domain to fritz.box and now it is working for all my local services/domains, except my homeassistant.

The entry in my Caddyfile is

http://homeassistant.fritz.box {

and the output from the command curl -v http://homeassistant.fritz.box is

*   Trying
* Connected to homeassistant.fritz.box ( port 80 (#0)
> GET / HTTP/1.1
> Host: homeassistant.fritz.box
> User-Agent: curl/7.74.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Content-Length: 16
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 26 Nov 2021 18:59:33 GMT
< Server: Caddy
< Server: Python/3.9 aiohttp/3.7.4.post0
* Connection #0 to host homeassistant.fritz.box left intact
400: Bad Requestroot@caddy:/etc/caddy# 

When I directly use the ip adress and the port I can connect to the page.

Do you have any advise for me?

Thanks for your assistance. :wink:

Please see the docs for HA, make sure you configure it to trust requests coming from Caddy:

Thanks again for the advise that I have to define at the homeassistant the proxy ip :+1:

So the thread can be closed as “succesfully solved”. :wink:

1 Like