New Caddy add-on

I do it with sub domains in Caddy…

you can also use 127.0.0.1 instead of localhost. this should save you a lot of headache if you -for whatever reason- have to change your rpi’s ip address in the future and forgot you used it in your caddy config :slight_smile:

btw: caddy version 1.0.3 was released some days ago and it’s working flawlessly for me. since caddy version 1.0.2 fixed a security vulnerability you should consider using it with this add-on.

How?

Good idea about using 127.0.0.1 - I’ll try that tomorrow…

download your customized binary from caddy’s website. the latest version of a pi 3 b+ compatible binary without any plugins and disabled telemetry can be downloaded by using this link: https://caddyserver.com/download/linux/arm7?license=personal&telemetry=off

open the downloaded file, find the file caddy in the root of the archive, extract it, rename it to caddy.bin and place it next to your Caddyfile in the share folder. restart the caddy add-on and have a look at the log. it should start with “Found custom Caddy” and the version of the custom binary.

2 Likes

Good point. I’ll do that.

Holy crap!!! I never even realised it was so easy to ‘build your own’ Woot!!!

Now I just need to work out how to configure the caddyfile for duckdns dns challenge and I can close port 80.

This is awesome.

Well that was disappointing…

/run.sh: line 14: /share/caddy/caddy.bin: cannot execute binary file: Exec format error
Found custom Caddy: 
Running Caddy:  /share/caddy/caddy.bin -conf /share/caddy/Caddyfile -agree -email [email protected]
env: ‘/share/caddy/caddy.bin’: Exec format error

I built for linux arm64 (Using a NUC and Debian Buster), added the duckdns plugin and turned off telemetry and copied/renamed the caddy to caddy.bin (and made it executable)

Edit: Ugh… maybe it should be Linux 64-bit and not arm…

It’s in the README :wink:

Also, I would think NUC would be amd64.

Thanks yeah… I’m building that now. Just trying to work out what I need in the caddyfile to use it…

The docs here https://caddyserver.com/docs/automatic-https#dns-challenge don’t tell you what environment vars to set for duckdns either.

@DavidFW1960 Caddy uses the lego library. Looking at the source, you’ll want to set DUCKDNS_TOKEN, presumably to your DuckDNS token.

and that’s in the addon as an environment variable?

So in the caddyfile I would add:

tls {
    dns duckdns
}

and then add the “env_vars”: [] with the token. Trying that now…
Hmm

Found custom Caddy: Caddy v1.0.3 (h1:i9gRhBgvc5ifchwWtSe7pDpsdS9+Q0Rw9oYQmYUTw1w=)
Running Caddy: DUCKDNS_TOKEN=xxxxxx
/share/caddy/caddy.bin -conf /share/caddy/Caddyfile -agree -email [email protected]
2019/08/19 10:44:56 /share/caddy/Caddyfile:96 - Error during parsing: Unknown directive 'dns'

That is possible, though not necessarily plug and play. You just need to get Caddy to put the .caddy folder in the /ssl folder so other add-ons can get to the files.

I haven’t done a ton of testing on this but it may be as simple as putting "HOME=/ssl" in the env_vars configuration.

It looks like you either didn’t include tls.dns.duckdns when you built Caddy, or you tried doing the tls config at the top level instead of underneath a site block. Can you show your full config?

domain.duckdns.org {
    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
}
    proxy / localhost:8123 {
        websocket
        transparent
        header_upstream Authorization {>Authorization}
    }
}

tls {
    dns duckdns
}

So instead, I think it should be:

domain.duckdns.org {
    tls {
        dns duckdns
    }

    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
    }

    proxy / localhost:8123 {
        websocket
        transparent
        header_upstream Authorization {>Authorization}
    }
}

Ok. So that worked. I added it to all the sub domains as well.

The log is normal… includes this:

Found custom Caddy: Caddy v1.0.3 (h1:i9gRhBgvc5ifchwWtSe7pDpsdS9+Q0Rw9oYQmYUTw1w=)
Running Caddy: DUCKDNS_TOKEN=entered token here
/share/caddy/caddy.bin -conf /share/caddy/Caddyfile -agree -email [email protected]
Activating privacy features... done.

Serving HTTPS on port 443 
https://domain.duckdns.org
https://sub.domain.duckdns.org


Serving HTTP on port 80 
http://domain.duckdns.org
http://sub.domain.duckdns.org

But of course until certs expire I guess I won’t know if it’s working but I’m going to block port 80 now anyway.

Scratch that… added a new domain (port 80 closed on router) Restarted Caddy and I get a certificate now! This will give folk who can’t forward port 80 (or indeed any other port probably) a way to get ssl working in addition to the core duckdns addon.

Thanks a lot for your help. This is great.

You’re 100% right it is. We even discussed it earlier in the thread but I didn’t realise compiling my own was as simple as a few mouse clicks on the Caddy site - until @Florian mentioned that today and now of course once you know it’s all 100% clear. (well after you helped me sort out the syntax in the Caddyfile).

Given a lot of people use duckdns+letsencrypt, it might be worth including that on the instructions in your repo or in the ‘help’ when you install the hassio addon?

Thanks for the answer, I tried your suggestion but nothing was created in the SSL folder

Using built-in Caddy: Caddy 0.11.1 (unofficial)
Running Caddy: home=/ssl /usr/sbin/caddy -conf /share/caddy/Caddyfile -agree -email [email protected]
Activating privacy features... done.

And to reply to David, I dont want to expose the addon outside my LAN, I just want to get rid of the annoying SSL warning when browsing my UniFi controller for example (“NET::ERR_CERT_AUTHORITY_INVALID” Back to safety blaha blaha)

@martikainen

According to the logs you used “home=/ssl” instead of “HOME=/ssl” in your configuration. That makes a difference here. Please make sure you use “HOME=/ssl”.

@DavidFW1960

What instructions would you like to see added to the README, exactly?

ooh… thats what I get when rushing things :wink:
Updated to HOME=/ssl

The current structure of my folder looks like this

ssl\acme\acme-v02.api.letsencrypt.org\sites/ here are folders for the sites specified in the caddy file
and in each folder there is 3 files,
my domainname.se.crt
my domainname.se.json
my domainname.se.key

Theese folders were not changed when updating the caddy addon with your suggestion

ssl\acme\acme-v02.api.letsencrypt.org\users/[email protected]/ dnsname.json
ssl\acme\acme-v02.api.letsencrypt.org\users/[email protected]/ dnsname.key
ssl\acme\challenge_tokens

Theese folders were not changed when updating the caddy addon

ssl\ocsp 6 files, 2 per site in the caddy file

This folder was updated with 1 new file for my domainname domain.se-68ba3508

Then in each addon you normally have these options.

{
  "ssl": true,
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem",
  "log_level": "info"
}

I’m not sure exactly what to change these too, i tried with a path to the .crt and .key files but


{
  "ssl": true,
  "certfile": "ssl/acme/acme-v02.api.letsencrypt.org/sites/domain.se/sites/domain.se.crt",
  "keyfile": "ssl/acme/acme-v02.api.letsencrypt.org/sites/domain.se/sites/domain.se.key",
  "log_level": "info"
}