Hey all!

I have a bunch of services running on my home server and was looking to expose some of them publicly via Cloudflare tunnel. This is done and working great using the origin server certificate and strict TLS.

Up until now, I’ve been using self-signed certs internally but now I don’t want to deal with the “proceed anyway” crap on browsers. I have Traefik set up to get certs from Cloudflare using DNS challenge and that seems to be working.

So, now my problem is: how do I switch between these certificates for the same URL when I’m internal vs public? I’d rather keep that traffic local if I’m at home, which is also working, I just can’t figure out how to get Traefik to use the appropriate certificate depending on if the request is coming from my LAN or Cloudflare.

Any suggestions? Is there a better way to accomplish what I want to do?

EDIT: Looks like I’m just going full Cloudflare on this one, thanks for your help everyone!

@shiftymccool@programming.dev
creator
link
fedilink
English
14M

If I use the Cloudflare origin server certs, the browser shows insecure and the message is “certificate not trusted” which is the same message as self-signed, if I’m not mistaken. I’m not sure what other details are relevant as I’m still new-ish to the networking portion of this home server thing. I’m happy to answer any questions if you suspect something.

@IHawkMike@lemmy.world
link
fedilink
English
44M

You said Traefik is getting certs from Cloudflare, but do you mean it’s getting Let’s Encrypt certs using a CF DNS challenge? And if that is the case, then your browser should trust the Traefik endpoint since LE certs are publicly trusted.

Are you sure you’re hitting Traefik when you get a cert warning? You need to update your internal DNS if not.

@shiftymccool@programming.dev
creator
link
fedilink
English
14M

You’re right, I’m using the cloudflare DNS challenge to get let’s encrypt certs. I’m definitely hitting traefik. I’m testing by turning the Wi-Fi on my phone off/on and opening the page after. I get the same cert every time but it’s not trusted when on Wi-Fi. This makes sense since it’s the origin server cert which is meant to encrypt traffic between my server and cloudflare. To add more certainty, when Wi-Fi is on, a traceroute shows only one hop to my server and shows a bunch of hops when it’s off.

@IHawkMike@lemmy.world
link
fedilink
English
14M

If you, Traefik, and your origin server are on the same network, then it’s going to be one hop regardless of whether you’re hitting the Traefik proxy or the origin server. If Traefik is serving up the origin server’s cert and not the LE cert, then Traefik is misconfigured to pass through instead of proxy, but I’m still not sure that’s the case as it’s almost harder to configure it that way than the correct way as a proxy.

What IP:port is your origin server listening on, what IP:port is Traefik listening on, and how is Traefik configured to reach the origin server?

@shiftymccool@programming.dev
creator
link
fedilink
English
14M

When I turn off Wi-Fi, I’m not on the same network as my server, it’s my carrier network so all the internet hops are expected.

The way it’s working now is I have a domain (example.com) that is set up on cloudflare DNS. I added a tunnel in cloudflare zero trust, which generates certificates you add to your server to encrypt traffic from your server to cloudflare. I have added these to traefik to be served with my service url (service.example.com). Then, I added a route in cloudflare for service.example.com.

This works fine. But, what I’ve also done is add a local DNS entry for service.example.com so when I’m on my LAN, I access it without going out to the internet and back (seems like a waste). However, this is serving the origin server certs from cloudflare, which causes trust issues

I’m using docker for everything: traefik, cloudflared tunnel, and my services on the same hardware. The tunnel just runs, and it’s configured on cloudflare zero trust to talk directly to the container:port over the docker network.

@IHawkMike@lemmy.world
link
fedilink
English
14M

In that case, if CF is taking to Traefik and not the actual origin server, you just need to forget about the origin certs altogether and use LE certs in Traefik.

@ramielrowe@lemmy.world
link
fedilink
English
3
edit-2
4M

I somewhat wonder if CloudFlare is issuing two different certs. An “internal” cert your servers use to serve to CloudFlare, which uses a private CA only valid for CloudFlare’s internal services. CloudFlare’s tunnel service validates against that internal CA, and then serves traffic using an actual public CA signed cert to public internet traffic.

Honestly though, I kinda think you should just go with serving everything entirely externally. Either you trust CloudFlare’s tunnels, or you don’t. If you don’t trust CloudFlare to protect your services, you shouldn’t be using it at all.

@ramielrowe@lemmy.world
link
fedilink
English
1
edit-2
4M

Here’s a drawing of what I think might be happening to your private traffic: traffic diagram

One major benefit to this approach is CloudFlare does not need to revoke an entire public certificate authority (CA) if a singular private tunnel’s Certificate Authority is compromised.

@shiftymccool@programming.dev
creator
link
fedilink
English
24M

That’s what I’m settling on. However, it’s not just about trust, some of the services I’m exposing deal with moving files and I’m mostly interested in higher speeds associated with local transfers as well as not using up my internet data cap.

That sounds like Cloudflare is giving you certificates intended only to be used for talking to Cloudflare.

You might be able to do it if Cloudflare sends a different SNI. It’s probably better if you get real certificates from Let’s Encrypt and just use those.

Create a post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

  • 1 user online
  • 279 users / day
  • 589 users / week
  • 1.34K users / month
  • 4.55K users / 6 months
  • 1 subscriber
  • 3.47K Posts
  • 69.4K Comments
  • Modlog