Best practice tips/help

[Rob789 (Robbert)]

@francislavoie

Yeah, Caddy may use the TLS-ALPN challenge instead of the HTTP challenge for ACME validation, so your server can work without HTTP. But it’s typically recommended to also serve HTTP so you can serve redirects to your users, and solve the HTTP challenge as a fallback, should the ALPN challenge fail for whatever reason (best to have more than one option for redundancy)

OK, thanks for clarifying that. I’ve opened port 80 permanently now.

@francislavoie

Well, it depends. You were vague on your actual setup, so it’s hard to really talk specifics without being hand-wavey about it all. Best for my time and yours if we talk about specifics here.

Ya, I wasn’t even vague I basically didn’t mention any of it I was aiming for general Q&A but I understand it would depend on specific setups. So to be more specific, I have a Keriomail (exchange) server with several domains and Nextcloud with Collabra that I’m setting up behind Caddy. The below Caddyfile seems to be working although I’m not sure about Nextcloud/Collabra as I broke that VM and still need to fix that.

Caddy 2.3.0

mail.intrafit.nl {
   reverse_proxy /admin/* https://192.168.2.1:4040 {
      transport http {
         tls_insecure_skip_verify
      }
   }
   reverse_proxy https://192.168.2.1 {
      transport http {
         tls_insecure_skip_verify
      }
   }
}

nextcloud.intrafit.nl {
   reverse_proxy https://192.168.2.4 {
      transport http {
         tls_insecure_skip_verify
      }
   }
}

mail.erje.nl {
   reverse_proxy https://192.168.2.1 {
      transport http {
         tls_insecure_skip_verify
      }
   }
}

I had to add tls_insecure_skip_verify because the internal certificates are self-signed. In the documentation it’s written this option should be avoided (with production systems) but was wondering if I should just go plain http instead. I just came across step-ca and wonder if this would be a solution but I haven’t found more clarifying documentation about this.

@francislavoie

Again, this is pretty vague. What are your concerns? Every app has different requirements.

Just general concerns about sleezy people trying to snoop around I found one option posted by @Whitestrake here which is based on IP filtering. But I think doing this dynmically at the end-point level with Fail2ban is more efficient.