It’s not a checkbox you need to edit the config. I have disabled it unless I know there is an update to caddy and as you say I rarely restart the addon anyway. I would think it should check if the version is the latest though and if the flag is set update it.
If doing a or was within my capabilities for this addon I would just make my own!
So I updated the add on tonight and set it to true to trigger it to update my custom caddy and it worked fine. Then disabled the update again. Good job and I guess this time I waited a couple of days so caddyserver is serving latest version for the update build. 2,4.2 custom build running. Thanks.
Can this add-on be used in conjunction with Nabu Casa to allow viewing non-HTTPS websites as iframes? I’m happy using my Nabu Casa subscription for remote access etc but wanted a way to access internal config pages for devices on my network. Even the ones that are HTTPS don’t seem to load in iframes remotely. I think due to certificate warnings.
If you’re HA is HTTPS then anything you view in an iFrame must also be HTTPS. Caddy will get certificates and make a page https for you which is what I do for TasmoAdmin and Portainer - they are each on their own subdomain and viewed via an iFrame in HA.
I use Nabu Casa so HA is HTTPS. I realise the iframe limitation hence looking into Caddy.
It’s a shame there is no setup info in the GitHub repo, looks like I have some reading / learning to do. I just want to use iframes from non-secure internal network device pages. ie: 192.168.0.100 for my NVR which is supposed to be HTTPS HA won’t display it in a normal iframe.
Look up in this thread. Search my posts as I have my full Caddy config here. It is pretty simple to set up and even makes sense to me which NGINX for instance doesn’t. I assume you are using a self signed cert for that local IP address? Caddy will get a LetsEncrypt cert.
I seem to have problems with external connections since I upgraded from 2021.6.5 to 2021.7.1. Internally, everything works fine. When I connect externally, I get redirected to https://extermal/lovelace and the browser shows the HA logo with the text ‘Unable to connect to Home Assistant’ and retry. When I try again, I get a ‘400: Bad Request’.
My setup: HA on a RPi4, Caddy 2 installed as an add on. HA IP address 192.168.2.25. Internal modem IP is 192.168.2.254.
My Caddy 2 config (in the web interface) is:
non_caddyfile_config:
email: xxx
domain: xxx
destination: localhost
port: 8123
args: []
env_vars: []
log_level: info
Today, I added the following to my configuration.yaml file to try to solve this, but so far it didn’t help:
http:
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1
- 192.168.2.25
I’d certainly appreciate any tips on how to solve this!
You might need to use a caddyfile and add x_forwarded_for to the header… I am using this with no reverse proxy warnings or issues. What does the HA log report?
I get this in the core log (nothing related in the supervisor or host log):
2021-07-09 11:58:35 ERROR (MainThread) [homeassistant.components.http.forwarded] Received X-Forwarded-For header from an untrusted proxy ::1
So I added ‘::1’ to the trusted_proxies, removed the line with 192.168.2.25 and everything works as expected. I wouldn’t have known how/where to add x_forward_for to the header, so I’m happy that this change is sufficient. Thanks for the pointer!
Interesting. Looks like caddy has that header by default. You might also add 127.0.0.1 to trusted proxies as that is the IPv4 localhost and ::1 is the IPv6 localhost. I use those as trusted proxies. I do suggest you scroll up in this thread and see my caddyfile example as if you run your HA instance through a header security you will likely find it deficient… Extensive discussion of that in this thread…
Thanks! 127.0.0.1 was already in the list, so it now includes both IPv4 and IPv6 localhosts.
I’m still getting to know HA so I’m trying not to overcomplicate things, but I’ll definitely get back to the examples in this thread later!
Hi David,
I saw that one of my reverse proxies was getting locked and not working with reverse_proxy /* which I believe was a breaking change recently - went to change it to a similar address to the later ones and all h*ll broke loose.
Now I'm getting this message: {"level":"info","ts":1627082913.4539983,"msg":"using provided configuration","config_file":"/share/caddy/Caddyfile","config_adapter":""}
run: adapting config using caddyfile: subject does not qualify for certificate: '}'
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
Without posting all of my scripts, what might a change be or should I post them all again?
Thank you, Daniel
Trying my caddyfile with this script:
{
email [email protected]
}
(common) {
tls {
dns dns {env.DNS_TOKEN}
on_demand
}
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 *.domain.dns.com:port"
Permissions-Policy "geolocation=(self), microphone=()"
}
}
sub.domain.dns.com:port {
import common
reverse_proxy localhost:port {
}
}
sub.domain.dns.com:port {
import common
reverse_proxy localhost:port {
}
}
sub.domain.dns.com:port {
import common
reverse_proxy localhost:port {
}
}
sub.domain.dns.com:port {
import common
reverse_proxy localhost:port {
}
}
sub.domain.dns.com:port {
reverse_proxy ip_address:port {
}
}
}
Last entry I think is main issue - can you decipher what’s needing to be added to avoid 1st post error of subject does not qualify for certificate?
I had originally had it like this and it was in the lock folder and this was the only address on a second computer if that is allowed (not localhost), but the other addresses worked at that time:
sub.domain.dns.com:port {
reverse_proxy /* {
to ip_address:port
transport http {
tls
tls_insecure_skip_verify
}
}
The very last line of your caddyfile } shouldn’t be there.
Have you tried adding the caddyfmt option as the formatting seems to be all over the place (although it could be the forum mangling it here.)
My Caddy yesterday renewed a certificate but I could not access the domain and the cert integration said unavailable or unknown or something. I am using DNS validation with lego-deprecated and namecheap. Turns out caddy hadn’t cleared the .txt file it created to validate the domain. Once I manually deleted that it roared to life. BUT your issue will be you need to delete the last line of the Caddyfile. If you use notepad++ or something like that you will see that’s not closing anything and is hanging in space by itself…
Also I removed the on_demand completely as I was always getting log messages about that and now with the latest caddy seems to be working properly without it. I originally added it on advice from @berichta but it seems to not be needed now and my cert renewals etc all are fine.
Hi David,
I removed on demand and hanging }, then cleared the txt at my dns provider and had to update the ip_address as an added bonus, and for a dose of “be sure” I removed my previous certs folder to ensure clean start. Took about 20 minutes for my sites to fully issue all certs, but I’m back in business.
Really appreciate the advice. Thanks,
Daniel
Yeah!!! The txt file has caught me a few times. Caddy should be cleaning up after itself!
Hi David,
So I can get the certs issued, but the actual connection says that it is not secure and if I use https it comes up with “an ssl error has occurred and you’re not connected to the server.”
Please note the difference in the change between 1st subdomain and 2nd port, don’t know if this should trip it up or not?
Caddyfile is as follows:
{
email [email protected]
}
(common) {
tls {
dns dns {env.DNS_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 1st_subdomain.dns.com:1st_port *.1st_subdomain.dns.com:1st_port"
Permissions-Policy "geolocation=(self), microphone=()"
}
}
(common2) {
tls {
dns dns {env.DNS_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 1st_subdomain.dns.com:2nd_port *.1st_subdomain.dns.com:2nd_port"
Permissions-Policy "geolocation=(self), microphone=()"
}
}
(common3) {
tls {
dns dns {env.DNS_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 2nd_subdomain.dns.com:3rd_port *.2nd_subdomain.dns.com:3rd_port"
Permissions-Policy "geolocation=(self), microphone=()"
}
}
1st_sub.1st_subdomain.dns.com:1st_port {
import common
reverse_proxy localhost:port1 {
}
}
2nd_sub.1st_subdomain.dns.com:1st_port {
import common
reverse_proxy localhost:port2 {
}
}
3rd_sub.1st_subdomain.dns.com:1st_port {
import common
reverse_proxy localhost:port3 {
}
}
4th_sub.1st_subdomain.dns.com:1st_port {
import common
reverse_proxy localhost:port4 {
}
}
5th_sub.1st_subdomain.dns.com:2nd_port {
import common2
reverse_proxy IP_Address:port5 {
}
}
6th_sub.2nd_subdomain.dns.com:3rd_port {
import common3
reverse_proxy IP_Address2:port6 {
}
}
Thank you for your help,
Daniel
It shouldn’t matter. I assume you have 2nd_port etc open/forwarded in your router?
Correct, open and forwarded and all the certificates say that they completed successful validation and released their locks.
Is there something else that I’m missing? A reboot of the computer/VM for HA? A reboot of the router? Anything to check on my DNS provider side?
If I use the http instead of the ssl format I can get to the port on a browser and of course it says not secure. HA iPhone app gives error 1200 NSURL and won’t connect.
No clue… I’d suggest posting caddyfile on the caddy forum… they are really helpful over there.
Also… is there anything in the caddy addon log?