I get this error with that header:
Hey all, was looking for some advice on Caddy 2. It looks pretty powerful and although thereâs a bit of a learning curve with the Caddyfiles it doesnât seem too bad and I like how it gives me complete control over things.
Iâm currently using Nginx Proxy Manager for all my reverse proxy needs so Iâm trying to see what it would take to migrate my config there to Caddy 2. I figured out a lot of the key stuff I needed already (basic reverse proxy setup with multiple subdomains, using a custom origin certificate instead of Letâs Encrypt, and setting up authenticated origin pulls with my Cloudflare setup).
But now Iâm reviewing the more basic options in NPM and not sure how or if I have to do anything to enable them. The basic options I can toggle on for every proxy host in NPM that I use are:
- Block common exploits (which includes this block-exploits.conf when enabled)
- Websockets support
- HTTP/2 support
- Enable HSTS
I know Caddy 2 does a lot of things automatically so I wasnât sure which of these just work already, which I have to do things for and which (if any) arenât supported. Was hoping someone could help.
Also I have quite a few subdomains and all of them use the same basic setup, same certificate (since it has a wildcard origin) and same authenticated origin pull setup. Is there a way to reuse the same config repeatedly in a caddyfile? Or do I have to copy and paste all that a few times?
See my example caddyfile above (in all the noise) but yes you can certainly define blocks you can reuse.
I think your basic options are covered by defauly.
I use a seperate certificate for every sub domain - no wildcards all with Lets Encrypt but I know you can define wildcards if you want. Theres also examples on the caddyserver.com forum as well as extensive docs - particularly there are threads about using cloudflare.
Iâd recommend checking the caddy forum and asking questions there as well as the caddyfile docs. @berichta would probably advise doing the same as he and I have very similar installations and what you are wanting is possible with caddy but outside my experience.
2 Likes
Ah I see now, thatâs what the import <defined block> stuff does, duh.
Iâm good on the wildcard part, sorry if that wasnât clear. Cloudflare provides users with a certificate with a wildcard domain to just import and use. I believe I figured out how to do that already from the caddy docs and some guides around cloudflare.
Good to know on the other options. I thought they might be covered just wanted to check. And yea, have been browsing around their forum, looks like a good community.
I just like caddy as it actually makes much more sense than a lot of the NGINX stuff and so far as I can see itâs equally powerful. You can run a security check as well once you sort out the headers etc and make sure you get a good A+ score. Links above as well.
1 Like
Oh nice, I like that. I also liked the built-in health check stuff, was planning to check that out as well.
1 Like
Hi David,
In terms of ssl certificates, where does caddy store these to in the system?
Thank you,
Daniel
And how would you reference them for other addons that say:
Certfile:
Keyfile:
Got it covered on HassOS it is:
/root/ssl/caddy/certificates/acme-v02.api.letsencrypt.org-directory/<my-domain>.duckdns.org/<my-domain>.duckdns.org.crt
And ââââ.key
1 Like
Remove /root from the beginning, thatâs incorrect.
When you use the SSH & Web Terminal addon it adds links to /ssl, /share, /config and the other top-level folders to the home directory (/root) for easy access. But it only does that in that addon, in every other container /root is basically just empty.
The certs and keyfiles actually live in /ssl so just strip /root off the beginning and youâre good.
EDIT: Also any addon which has certfile and keyfile options in the config doesnât actually want an absolute reference anyway, it wants a relative reference from /ssl. So for those strip off /ssl/ too and just start from caddy.
2 Likes
FYI for those using the Visual Studio Code addon (or those that just have VS code set-up on their own) thereâs a Caddyfile syntax extension here: https://marketplace.visualstudio.com/items?itemName=zamerick.vscode-caddyfile-syntax .
For some reason I wasnât able to get it to appear in the list of extensions in the marketplace of the add-on, not really sure why. But I was able to install it manually by execâing into the docker container and doing a git clone on the repository into /data/vscode/extensions. And now Iâve got syntax highlighting and autocompleting for directives!
1 Like
Hi Mike, I appreciate the clarification on those paths, I started to get the nuances - but this helps solidify their structure. Thank you so much!
-Daniel
1 Like
Build version 2.4.0 just now with lego-deprecated and it is working properly with this addon.
1 Like
Updated to latest addon with the upgrade caddy set but I donât think itâs building caddy with the plugins (lego-deprecated) same as when I tried to d/l 2.4.1 todayâŚ
So fun fact⌠I ran a console in Portainer in the card container and caddy version says 2.4.1 but restarting the addon (with the upgrade flag false) still says 2.4.0âŚ
I think it must be mixing your built caddy with the custom one in portainer as the checksum of the caddy built by the addon and downloaded are the same. So I built a custom one with xcaddy and it now shows 2.4.1 as the version for custom caddy in the addonâŚ
Hi @DavidFW1960 ,
I donât fully get your intention. Please can you provide a clear overview of:
- A description of your current setup
- Your Addon-settings
- Your expected result
- The actual result
That way I would be able to review the issue.
Thanks
Well my use case and setup are pretty well documented in this thread I thought.
I used the option to upgrade caddy - I run a custom caddy with a DNS challenge (lego-deprecated). My 2.4.0 caddy was a custom build with that module so using the caddy_upgrade option it should have built a custom 2.4.1 with the same plugins but it didnât.
I also tried in a console in the caddy container running the caddy version command but that was obviously using the caddy from your addon even though I changed directory to the share/caddy directory.
The caddy server site download is still creating caddy 2.4.0 rather than 2.4.1 builds.
So the only way to get a custom caddy 2.4.1 with the lego deprecated plugin was via xcaddy.
Hi @DavidFW1960 ,
The caddy upgrade function works as specified here:
Replaces the current Caddy binary with the latest version from our download page with the same modules installed, including all third-party plugins that are registered on the Caddy website.
Meaning, if the download from the webpage provides a 2.4.0 version, the result will be the same within the add-on.
Possibly you will have to wait until the web page download is updated. At that moment you will also receive the latest version with help of the add-on.
1 Like
Yeah I get that - hence I used xcaddy Does the addon check if the version is the latest one or does the upgrade function in the addon just build a new one every time the addon starts?
At the moment the add-on builds a new one every time the add-on starts.
Simply because it was convenient and, well, simple to implement.
One could always just enable or disable the checkbox when needed. And I would also question that many people restart the add-on multiple times a day.
If there are more requests, letâs review again. Pull requests are also welcome on GitHub in case anyone wants to help on that topic. 