Hi @bouwew,
Thanks for mentioning the issues. Yes, changed my GitHub name a while ago. So far I didn’t experience any issues, because GitHub forwarded everything accordingly. But will change things right now.
One note, the image information in the config.json is correct, as it refers to docker hub.
Let me check the builds on docker hub. Possible that something failed during the build.
Great, thanks!
Please note: Caddy 2 Edge from hassio-addons-dev installs without error.
I was able to identify an issue with the docker image tag, which only happens on installation.
A new version is building right now. When all works as expected, an update should be available soon, which is installable.
Will update here once it works as expected.
Again, thanks for making aware of this issue!
Update
Installation just worked fine in my installation. Please can you test and confirm as well?
In order to do so:
Update 2
As it turned out, the installation error was caused by a supervisor bug. This was reported and fixed.
For further information, in case anyone is interested, here are the links:
Yes, confirmed. V0.1.1 installs fine and works OK.
Thanks for fixing!
Throughout the last weeks the Caddy 2 add-on and also the repository received multiple “under the hood” updates in order to streamline future updates and releases.
Unfortunately, this change and update will require some actions on your side.
https://github.com/einschmidt/hassio-addons
The new addon should be able to pick up everything from where it was stored before.
When everything worked as expected, you should run version v0.2.0 from there on.
In case of any error or issue, please let me know. Either here or via GitHub.
Sorry for any inconvenience.
All good… installed
I just tried to get my network up and running in a new place as I have been down for quite awhile. I’m completely behind and trying to get up to speed. Am I looking at moving on to Caddy 2? is Caddy 1 deprecated? I’m not looking for help with Caddy 1 just trying to figure out whats the currents state of affairs with reverse proxies.
I’m using duckdns, and the caddy addon from korylprince and Im seeing this error.
Using built-in Caddy: Caddy 0.11.1 (unofficial)
Running Caddy: /usr/sbin/caddy -conf /share/caddy/Caddyfile -agree -email [email protected]
2021/02/07 14:46:04 too many renewal attempts; last error: acme: Error -> One or more domains had a problem:
[ombi.ivymike.duckdns.org] acme: Error 400 - urn:ietf:params:acme:error:connection - Fetching http://redacted.duckdns.org/.well-known/acme-challenge/redactedjtg: Connection refused
Activating privacy features...
am I just looking at moving on to Caddy 2 here?
It looks like it can’t get a cert? What kind of validation are you doing? Do you have port 80:forwarded? Why don’t you switch to caddy2?
Hi @dasbooter,
Caddy 2 comes with plenty of improvements, but also subtle changes. I could say keep your existing add-on (as long as it works), but I think it would be general and good practice to update internet facing services to the latest version.
Having that said, looking at your error, it seems you started your caddy add-on a few times too often, hitting the request level at the configured acme server (most likely Letsencrypt). Caddy 2 shouldn’t run into such errors as there are now even fallback acme servers. 
So my recommendation would be to give Caddy 2 a try. The add-on comes with a non-caddyfile-config, so you don’t have to take care of the new Caddyfile structure for the beginning. Just enter your data and run the add-on. (Don’t forget to rename your existing Caddyfile first 
)
In case you need further tips, advices or help, just let us know.
Unfortunately I don’t have complete control over the network where I’m at. I’ve asked for port 80 to be forwarded to 443 on the machine running caddy 1. I’m just confirming with them they have done that.
Caddy one should work using korylprinces add on still but It sounds like I should move on to Caddy 2 anyways. Its always been a bit of trial and error with me anyways and I can’t really do that without access to the network hardware.
Thanks all for the feedback. Covid 19 has made my living circumstances unusual so I may have to give up on things for a bit I fear
You need to forward port 80 to port 80 with http validation. 80 to 443 won’t work. I would strongly recommend using DNS validation and not http validation - then you won’t require any port forwards. I don’t know if it is still possible to build v1 caddy with the correct addons anymore automatically. Caddy 2 you can build easily with the dns addons. Let me know if you need any help as I recently went through the conversion.
Ugh I will have to reteach myself the whole networking situation here. I thought that forward 80 to 443 was to redirect requests made on http to https, so for instance people requesting http://ombi.redacted.duckdns.org would be redirected to https://ombi.redacted.duckdns.org
I’m trying to remember exactly how I set up my router here and passing along requests to somebody who doesn’t necessarily get back to me all the time to implement things on their fancy ubiquiti router. I dont want to waste anybody’s time here so I’ll see if I can find another tutorial that includes setting this up in terms of this and also google assistant I had running with HA. It looks like the caddy one addon by Koryl might not work anymore so when I do get started Ill move to caddy 2. Incidentally I think I got the too many requests immediately after I started the old addon but not sure what that could mean. Any ways thanks for pointing me in the right direction
Google Assistant works fine with Caddy1 but it requires you to use a https URL. Caddy will convert to https by default BTW. There is no reason for caddy1 not to be working. I only converted to Caddy2 myself a few weeks ago.
But letsencrypt for either addon will require port 80-80 forwarded if you use http validation (the default) so in your situation I would use dns validation instead (actually I’d use that anyway) it’s really quite easy to setup and use.
I just need to revisit my Caddyfile.
I am having a few issues with the conversion from caddy1 to caddy2
First, in Caddy1 I did this:
proxy / localhost:8123 {
websocket
transparent
header_upstream Authorization {>Authorization}
}
I know websocket and transparent are not needed but if I enable
header_up Authorization {>Authorization}
in Caddy2 then I can not access any ingress panel (like supervisor etc)
Secondly, NONE of my iFrames work and I get a console error like : Refused to display ‘https://subdomain.domain/login’ in a frame because it set ‘X-Frame-Options’ to ‘sameorigin’.
My header is like this:
header {
Strict-Transport-Security "max-age=31536000; includeSubdomains"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "same-origin"
-Server
}
Worked perfectly in Caddy1 but error above for any iFrame with Caddy2
Any ideas?
I also posted on the Caddy2 forum but they are not necessarily too helpful
Hi @dasbooter,
Although outdated, don’t hesitate to refesh your memory on the general instructions for a Caddy (1) usage here:
Note to myself: Update that page…
Important for you, in case you want to go with the default SSL method:
Forward both ports (80 and 443) from your router to your Hass.io server. Can’t help you with that part, as it is highly dependent on the manufacturer etc. Just ensure that the ports are mapped 80:80 and 443:443 as from:to
Once the ports arrive at home assistant, the most dificult part is done. Run the add-on with the non-config settings and you should be able to access HA via https.
As to your question, Caddy will take care of the routing from 80 to 443 automatically.
As mentioned by @DavidFW1960, there is another method for the Cert verification, which may require only one port. However, I am not used to that method but I am certain David will be able to help if wanted.
Hi @DavidFW1960,
as to your issue, a few questions:
As I said I think I changed it because when I did a security check on my HA from a third party site it recommended that option.
Yes I have x-forwarded-for set. Setting x-frame-options to same origin should ALLOW iFrame connections not deny them.
Caddy1 had no issues with those options and worked correctly.
So as a follow-up. I was recommended to try a content-security-policy like this:
Content-Security-Policy "frame-ancestors domain:xxxxx *.domain:xxxxx"
In the header instead and that works with my iframes.
When using the X-Frame-Options with “same-origin”, it failed on my end.
But changing the X-Frame-Options to the following enabled my iFrame instantly:
X-Frame-Options "ALLOW-FROM https://my.domain.com"
The above allows your webpage to be inserted into iFrames, but only on that particular page.
See also: here
The content-security policy supersedes the x-frame-options. A poster on the Caddy forum linked me to a doc about it. When I do a security check on my HA even though I slated the x-frame-options it shows that requirement as satisfied now. I can give you some links tomorrow when on my PC if you are interested.
I still don’t know it is only caddy2 that didn’t like the sameorigin… caddy1 was fine with that…
From your link
SAMEORIGIN which allows you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify sites that are permitted to frame your own site.
I don’t understand unless sameorigin doesn’t see a sub domain as same origin in Caddy2?