Https ssl docker local home lab with external access

Help
1

1. The problem I’m having:

Setting up SSL. I am very confused as to how to set things up.

I am purely a coder/developer and front end UI (PHP, React, Python) so networking is absolutely not my strong suit.

My research seems to get conflicting results from previous versions of caddy and also “non” docker installations.

I just want to have SSL for local sites for example.

jellyfin.home.lab {
reverse_proxy jellyfin:8096
}

And then have that same dockerized container available externally from

jellyfin.lab.audasmedia.com.au{
reverse_proxy jellyfin:8096
}

And both of these use SSL in the most simple way.

I have my own website at audasmedia.com.au and set up a subdomain lab.audasmedia.com.au which forwarads everything to my public static IP for my local home network. This port forwards to pihole which distributes things via DNS server to caddy which reverse proxies.

The domain lab.audasmedia.com.au has its own lts encrypt certificate which happens automatically on inmotionhosting - I tried copying that and sticking it in the docker folder on Ubuntu- - please don’t laugh at me - and then bringing that in with having copied the certificate & key into cert.pem etc as shown.

lab.audasmedia.com.au {
       tls cert.pem key.pem
}

Just really not sure how to go about setting things up - I have spent the last few days going through documentation on this to no avail.

I guess its because so much magic is happening, I guess I can follow things better if htey are vastly more complex and stricter steps are required - but I’m also an Apache2 guy - so maybe thats why.

Have tried many different permutations, variations etc.

Please let me know if you need clarification on anything in my set up as this is a real rambling waflle.

Sorry.

Thanks.

2. Error messages and/or full log output:

I am not getting any responses at all - outside of an error message when trying to create a local tls (use internal ???)

jellyfin.home.lab{
tls internal
}

or I tried
*.home.lab {
tls internal
}

It tells me the domain suffix (top level) is not valid.

3. Caddy version:

Docker caddy:latest

4. How I installed and ran Caddy:

Docker

a. System environment:

Docker on virtual machine linux on proxmox

b. Command:

I have no idea - so I tried the following but it could not find these. I copied the key and cert from my domain and pasted them into a file next to the docker-compose.yml

As I said - SSL has never been my thing - so I am quite lost in the various versions of caddy and the types (Bash with SSL commands, Docker etc)

lab.audasmedia.com.au {
       tls cert.pem key.pem
}

c. Service/unit/compose file:

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

d. My complete Caddy config:

I have tried all these permutations without the host prefix (http / https)

http://ghost.home.lab {
    reverse_proxy freshrss:80
}


#REMOTE


http://homepage.lab.audasmedia.com.au {
import basic-auth
    reverse_proxy homepage:3000
}


http://freshrss.lab.audasmedia.com.au {
  import basic-auth
  reverse_proxy freshrss:80
}

5. Links to relevant resources:

1 Like
2

Howdy @audas - looks like you’ve tried a lot of stuff and you’ve got some goals that haven’t fully materialised yet.

If I may make a recommendation - ditch the config you’ve tried so far, redefine your starting goal as simply as possible, and get ONE thing working. Once you’ve got that, THEN start adding more complexity, bit by bit.

Lets start with this, just on its own:

Firstly, be very careful with jellyfin.lab.audasmedia.com.au{ - if you don’t have a space between the site label and the opening brace, Caddy will treat the brace as part of the label and you’ll have mismatched braces. Make sure its got room to breathe: jellyfin.lab.audasmedia.com.au {

Then, lets fix this…

Knowing that you’re unfamiliar with the networking side of things, there’s a bit of a trap here you’ve fallen into. The DNS server doesn’t forward packets. Think of it like a concierge with a yellow pages or a map for you to reference. You go there to check how to get somewhere else, before you then turn, leave, and go to that place. All it does is resolve domain names into IP addresses; it’s not involved in routing.

Traffic bound for Caddy has to reach Caddy itself directly. You need to fix your port forwards so that 80 and 443 don’t go to PiHole but instead go to your Caddy host. That way, HTTP(S) connections to your external IP address reach Caddy and Caddy can properly respond. Your DNS server itself should pretty much never ever be exposed to the public internet.

Once you’ve got port forwarding working, and Caddy can get ACME certificates for jellyfin.lab.audasmedia.com.au, then you can start expanding your configuration to add more sites and self-signed sites.

That said, given you have a PiHole, I’d recommend going with split horizon DNS rather than hosting internal sites separately on self-signed certs.

3

Everything is working perfectly.

Caddy is listening on 80 and 443

I just need to set up the SSL.

4

If you have Caddy listening on port 80 and 443, and external DNS pointed at Caddy, then Caddy will requisition SSL certificates via ACME (using HTTP or TLS-ALPN validation).

Is that not working?

5

If I try for example on local network with rss.home.lab - as I said it gives the error from the local network it delivers an error

Invalid identifiers requested :: Cannot issue for "rss.home.lab": Domain name does not end with a valid public suffix

If I use the external link it just gives me this site cant be reached.

So locally this fails
“https://rss.home.lab” and with the tls internal so does rss.home.lab

That said https://freshrss.lab.audasmedia.com.au fails - but freshrss.lab.audasmedia.com.au will work (with out the https)

Caddy is listening on port 80 and 443

What set up should I have for these in my Caddyfile?

6

This happens because .lab is not a real TLD and you can’t have publicly trusted HTTPS for this address.

You must specify tls internal for these domains. For this reason I generally recommend split horizon DNS, which would let you browse to freshrss.lab.audasmedia.com.au within the LAN and use the publicly trusted HTTPS locally, too.

Refer above re: split horizon DNS. Alternatively, your router may have a feature commonly referred to as hairpin or loopback NAT which can allow access to the external port forwards via the LAN.

You can generally omit the scheme. By omitting the scheme you leave it up to Caddy to serve a redirect on HTTP and the site itself on HTTPS, on default ports. You should only specify a scheme if you specifically want to serve ONLY that scheme.

But, I expect rss.home.lab to work just fine with tls internal and did just test it right now on Caddy v2.8.4 without issue.

If you’re running into an error with it, please post the exact Caddyfile you used and copy the exact log output when you ran it.

7

I have been using this command to restart from inside Caddy

docker exec -w /etc/caddy caddy-caddy-1 caddy reload

Jellyfin is able to connect. I have several other tests running none of which can connect via https.

homepage, freshrss, immich etc

Nothing works with local domains from pihole.

Any suggestions on what I could try in my tls config currently everything is commented out

#*.home.lab {
#   tls internal
#}


#lab.audasmedia.com.au {
#       tls cert.pem key.pem
#}

Also I have both http and without for domains to test.

For example

jellyfin.lab.audasmedia.com.au {
        import basic-auth
        reverse_proxy jellyfin:8096
}
http://shopping.lab.audasmedia.com.au {
        import basic-auth
        reverse_proxy shopping:8080
}

I know Caddy looks at the content of protocol - not sure if having mixed in there throws things off.

8

Can you elaborate?

There’s a million ways something could be not working. Without specifics we don’t really have a way to guess at what.

Curl attempts, specific errors, anything.

The *.home.lab site with tls internal should be a functional Caddy configuration. We need more information on how it’s failing.

I am not sure what you mean by content of protocol, here. Do you mean having one site HTTP and one site HTTPS? That should be perfectly fine.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.