Home Assistant Add-on: Caddy 2

Hi David,

Got rate limited a couple of times - I have a Caddy of version 1 downloaded[LinuxAMD64 on HassOS VM (should this be v2?)], I have ports 80 and 443 opened to the server (plus all other ports for external access to the internal forwarded ports), I have my caddyfile with https added to the front of the external site and separated out each common section to a separate reference for each port (so not really common anymore, lol).

I’m getting the sites passing validation in the Caddy add-on log, but it is only working for HTTP and not setting up HTTPS sites, do you know what may be causing this?

Can’t throw this up at the Caddy server site, as they require the full domain name and nothing redacted and I’m not prepared for that.

The add-on log says:

{"level":"info","ts":1629306286.4848493,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"sub.sub.domain.com","challenge_type":"dns-01","ca":"https://acme.zerossl.com/v2/DV90"}
{"level":"info","ts":1629306290.9622422,"logger":"tls.issuance.acme.acme_client","msg":"validations succeeded; finalizing order","order":"https://acme.zerossl.com/v2/DV90/order/SyeibHNn6qerU8PAH3ETNw"}
{"level":"info","ts":1629306307.1248104,"logger":"tls.issuance.acme.acme_client","msg":"successfully downloaded available certificate chains","count":1,"first_url":"https://acme.zerossl.com/v2/DV90/cert/MWbHp4seMiWUG1nve5fDoA"}
{"level":"info","ts":1629306307.1260618,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"sub.sub.domain.com"}
{"level":"info","ts":1629306307.12614,"logger":"tls.obtain","msg":"releasing lock","identifier":"sub.sub.domain.com"}

The Caddyfile is as follows for one example:

{   
	email [email protected]
}
(common) {
        tls {
                dns ddns {env.DDNS_TOKEN}
        }
        header {
                Strict-Transport-Security "max-age=31536000; includeSubdomains"
                X-XSS-Protection "1; mode=block"
                X-Content-Type-Options "nosniff"
                Referrer-Policy "same-origin"
                -Server
                Content-Security-Policy "frame-ancestors *.subdomain.domain.com:port"
		Permissions-Policy "geolocation=(self), microphone=()"
        }
}
sub.subdomain.domain.com:port {
    import common
    reverse_proxy localhost:ha_port {
    }
}

Thank you,
Daniel

I just use a dummy domain name when I post on the caddy site.
Are you saying you are using caddy v1? And you downloaded a custom caddy? Why not use caddy 2?

Not sure what you mean by that.

Also you shouldn’t need 443 and 80 open - unless you use 443 externally to come in. You appear to be using the dns challenge so no 80.
If you get rate limited at LetsEncrypt it will automatically switch to zerossl which has no limits.
Maybe @berichta has some ideas?

Hi David,

When I go to caddy server site, instead of hitting on new v2 and adding the addons I go to just the download button and put on my addons - should I be using from that site the v2 version? The addon for HA of course I’m using Caddy2.

That’s good to know about zerossl taking over, I usually just stop when it says rate limited 167 hours - good to know. I will have a look at closing port 80, do you not need 443 open for certs though - interesting if not?

I’ll look to throw this up on Caddy site then, if I can use dummy domain - their warning was ominous.

Thank you,
Daniel

That will download v2. And then you copy the binary to the Caddy folder right?
image
I am using /share/caddy2 not caddy because I was playing with caddy v1 as well and never bothered changing it. When you startup the addon it should say you are running a custom caddy and give the version.

If you are using DNS validation, you don’t need ANY ports open for certificates… that’s the whole point of using it. But yu need to build caddy with the plugin for the DNS provider. I’m using lego-deprecated because noone has made a namecheap plugin yet.

Caddy site won’t care if you use a fake domain for help.

Hi David,

I’m getting a lot of these OCSP stapling errors, any clue?

{“level”:“warn”,“ts”:1629430610.3012443,“logger”:“tls”,“msg”:“stapling OCSP”,“error”:“no OCSP stapling for [sub.subdomain.domain.com]: parsing OCSP response: ocsp: error from server: unauthorized”}

Thank you,
Daniel

Looks like it’s a certificate error

Hi David,

I’m having a heck of a time trying to get tls certs again. Can you please post an example of your redacted working Caddyfile. The error I had above was from the cert processing in caddy 2 startup, I’m just not getting things to align again and I’ve been reviewing all the documentation from our post here, there’s been at least 2 version changes of Caddy 2 since last time I had it working and the port config is gone on my install - so it picks up ports from other programs and cert process says port in use, so I have to stop several add-ons.

I put in the address and it just sits there and doesn’t error out or anything. I noticed that on another thread you asked if someone had a pihole which I have and I’ve turned it off. I have the external port (XXXXX) forwarded to the internal port for each item (ie 8123 for HA). I’ve added https:// to the start of the external addresses to ensure that it knows to select TLS for the reverse proxy.

I feel like once again I’m really close, but enough variables have changed that there must be something that is throwing the monkey wrench.

Thank you for the assistance,
Daniel

See here

I don’t think anything material has changed with caddy in the 2 minor updates.

I don’t understand your setup or why you are making this so hard!!! If you use the DNS challenge you don’t need any ports open at all for certificates. I only have the one port opened which is what all my sub domains come in on and then get proxied to the correct places.

Apparently it’s my pi-hole tripping me up, any clue how to avoid it?

Can you disable Pihole temporarily? (Or even permanently lol)

Apparently my certs are implementing older TLS handshake protocols. Caddy only supports TLS 1.2 and 1.3, older versions are deprecated and potentially insecure.

What the error is telling the caddy folks is that I’m probably not hitting Caddy with my request, but instead some other server which is intercepting the request. Can you think of how to solve that?

as per my previous post, disable Pihole.

Port config issue!! Fixed it! External port XXXX to Internal port XXXX, I had internal port of YYYY instead. My bad, it had been awhile since I had the port forwarding all entered and configured from the past setup I had done. Thank you, David.

1 Like

I can now pull up the login screen fine, but HA says Login attempt or request with invalid authentication and goes to unable to connect to HA (retry) - any clues?

  • reset router
  • reset phone
  • reset HA, VM, and MAC
  • commented back in base url and have https://sub.subdomain.domain.com
  • have use_x_forwarded_for
  • have 127.0.0.1
  • have ::1, although I’m not using ip6

So you setup trusted proxies in configuration.yaml? I use trusted networks with trusted user. With the base_url if you don’t connect with port 443 you need to specify that as well. Does the error give the ip_address for invalid auth?

Setup trusted networks and users, but same message “unable to connect” when either selecting network and user or just entering credentials. Changed base_url to add port. It now allows me to choose my network and user then just goes straight to unable screen.

Is there different credentials that I should be using - this looks to be a bug in the on boarding script, but I can’t figure out how to get around it. It looks like the credentials are valid or else it would have an error on the login page - this has an error in the logs stating that it will ban it before I put in the trusted networks language.

I’m also using the same address as a couple of weeks ago and cleared the refresh tokens, but wonder if there’s an older token (not api) that I need to address?

homeassistant:
  customize: !include customize.yaml
  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 127.0.0.1
        - ::1
        - 192.168.1.0/24
        - 172.17.0.0
        - 2700:1010:b053:309a:28d2:be32:f7e2:2456
        - 174.194.12.245
      trusted_users:
        192.168.1.0/24: !secret user_id
        127.0.0.1: !secret user_id
        "::1": !secret user_id
        2700:1010:b053:309a:28d2:be32:f7e2:2456: !secret user_id
        174.194.12.245: !secret user_id
      allow_bypass_login: true
    - type: homeassistant
http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.2.0/24
    - 192.168.1.0/24
    - 172.17.0.0
    - 172.30.32.0
    - ::1
    - 127.0.0.1
  ip_ban_enabled: True
  login_attempts_threshold: 5
  base_url: https://sub.subdomain.domain.com:port

Hi David,

I feel like I have the trusted networks and proxies confused, would you be able to inform me of the correct way of thinking of both:
Is trusted networks the IP address that you’re connecting from and trusted proxies is the IP address that the internal docker image is connecting from? Should there be any that are overlapping?

Thank you,
Daniel

trusted_networks with a trusted user and bypass login will enable you to bypass entering any logon details at all when you login/connect from that network. The login screen will just flash by and you are logged in without lifting a finger.
Trusted proxy… well when you use a reverse proxy (caddy) HA will always see the IP address you are connecting from as the proxy and not the true IP address… even someone connecting externally will be seen as connecting from the proxy and not their true IP address. So recently HA forced you to use a trusted proxt so that is configured under http: section. You can also configure a lockout etc. This is mine:

http:
  # ssl_certificate: /ssl/fullchain.pem
  # ssl_key: /ssl/privkey.pem
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - ::1
  ip_ban_enabled: true
  login_attempts_threshold: 5

That is essentially localhost on IPv4 and IPv6 and 5 logon failures and you’re banned.
In the caddy config you can configure it to pass through the real ip address using the x_forwarded_for header as I have in all my examples.
I also use Ludeeus’ custom Authenticated so I can see the ipaddresses connecting on my lovelace dashboard.

So my trusted proxy and trusted network are the same IP address localhost but some proxies like NGINX need the 172.x network (the docker network) as the trusted proxy to work.

Hope that helps

Finally got it working enough, I took out trusted networks and auto logon. The thing that was killing it was the zerossl was erroring out and not OCSP stapling at the end so not valid authentication.

Thank you David for all the help!!

1 Like

Unless fixed, this is a reason not to use it for now for me as I’m using DNS challenge.

I like the look of this especially as I have some HTTP iframe issues internally which I think it might solve.

Load more reading to do before I take the plunge :slight_smile: