this post was submitted on 17 Sep 2024
29 points (100.0% liked)

Selfhosted

40394 readers
388 users here now

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!

founded 2 years ago
MODERATORS
 

Hopefully you all can help!

I've been to hundreds of threads over the last few days trying to puzzle this out, with no luck.

The problem:

  1. Caddy v2 with acme HTTP-1 ACME challenge (Changed from TLS-ALPN challenge)
  2. Cloudflair DNS with proxy ON
  3. All cloudflair https is off
  4. This is a .co domain

Any attempt to get certificates fails with an invalid challenge response. If I try and navigate (or curl) to the challenge directly I always get SSL validation errors as if all the requests are trying to upgrade to HTTPS.

I'm kind of at my wit's end here and am running out of things to try.

If I turn Cloud flare proxy off and go back to TLS-ALPN challenge, everything works as expected. However I do not wish to expose myself directly and want to use the proxy.

What should I be doing?


I have now solved this by using Cloudflair DNS ACME challenge. Cloudflair SSL turned back on. Everything works as expected now, I can have external clients terminate SSL at cloudflair, cloudflair communicate with my proxy through HTTPS, and have internal clients terminate SSL at caddy.

you are viewing a single comment's thread
view the rest of the comments
[–] douglasg14b@lemmy.world 1 points 2 months ago* (last edited 2 months ago) (1 children)

I am doing SSL termination at the handoff which is the caddy proxy. My internal servers have their SSL terminated at caddy, my traffic does not go to the internet.... It loops back from my router to my internal Network.

However DNS still needs to have subdomains in order to get those certificates, this cloudflair DNS. I do not want my IP to be associated with the subdomains, thus exposing it, therefore cloudflair proxy.

You're seeing the errors because the proxy backend is being told to speak HTTPS with Caddy, and it doesn't work like that.

You can have SSL termination at multiple points. Cloudflare can do SSL termination and Cloudflair can also connect to your proxy which also has SSL termination. This is allowed, this works, I have services that do this already. You can have SSL termination at every hop if you want, with different certificates.

That said, I have cloudflair SSL off, as stated in the OP. Cloudflare is not providing a cert, nor is it trying to communicate with my proxy via HTTPS.

Contrary to your statement about this not working that way, cloudflair has no issues proxying to my proxy where I already have valid certs. Or even self signed ones, or even no certs. The only thing that doesn't work is the ACME challenge...


Edit: I have now solved this by using Cloudflair DNS ACME challenge. Cloudflair SSL turned back on. Everything works as expected now, I can have external clients terminate SSL at cloudflair, cloudflair communicate with my proxy through HTTPS, and have internal clients terminate SSL at caddy.

[–] just_another_person@lemmy.world 1 points 2 months ago* (last edited 2 months ago)

Yeah...I'm not sure where you're confused, but that's what I said. You can't have: Client > HTTP Proxy > HTTPS endpoint. It doesn't work that way. Enabling TLS on the forward proxy where the client makes the initial request fixes this...which is what I explained.