"Quote from: Monviech (Cedrik) on January 07, 2025, 05:52:10 PMIf Caddy(Main) and Caddy(Sub) are in a trusted network, you can reverse_proxy between these Caddies without using TLS.I understand. Perhaps a better qualification of one of my use-case is in order.
TLS is only important on the way through untrusted networks, e.g. from Client on the Internet to your Caddy(Main).
Caddy(Main) will hold all certificates and terminate tls. The other Caddies would not need to issue any certificates.
So you do not really need an ACME Server or a ACME Challenge redirection. Just use Plaintext.
- Telegraf, Influx and Grafana stacks are employed for telemetry. Latter two are web-based interfaces which require explicit certificate configuration in order to use http(s). Telegraf client configurations need root_ca for http(s) and host-specific keys if TLS verification option is enabled.
- Now, first-order question I asked myself was: Do I really need to protect telemetry information from telegram clients to influx db server? Not really : is the honest answer. That said, telemetry information reveals plenty about topology. So, having telemetry data streamed using TLS protection does carry benefits
- The certs (for external domain) will now reside on Caddy(master). With ACME server enabled on Caddy, I can have certbot request the necessary certs and auto-provision (e.g. during cert renewal) certs onto appropriate roles
Reference telegraf client information required:
Code Select
## Optional TLS Config for use on HTTP connections.
# tls_ca = "/etc/telegraf/ca.pem"
# tls_cert = "/etc/telegraf/cert.pem"
# tls_key = "/etc/telegraf/key.pem"
## Use TLS but skip chain & host verification
# insecure_skip_verify = false
Similar information is required for influx and Grafana.
Quote from: Monviech (Cedrik) on January 07, 2025, 05:52:10 PMRegarding the build:Thank you for the reference. I understand.
https://caddyserver.com/docs/command-line#caddy-add-package
You can use this to add any package you want from the command line. It will not be persistent though. If the opnsense repo pushes an update at some point you must do it again.
The crowdsec usage I referred to earlier is as follows:
Code Select
--> Global block of Caddyfile (info generated using cscli bouncer add
{
crowdsec {
api_url http://<Opnsense_fw>:8080
api_key <valid_key>
ticker_interval 15s
}
}
--> In the site-block of clients
{
route {
# crowdsec based filtering
crowdsec
... whatever logic is necessary ...
}
}
Quote from: Monviech (Cedrik) on January 07, 2025, 05:52:10 PMCurrently the plugin is rather finished and very specific or overly complicated things will most likely not be added to prevent feature creep.Thank you for sharing the plugin status and roadmap. I only asked about crowdsec modules (which can be used like above) because a log-based integration of crowdsec is already implemented on your plugin for Opnsense. Addition of the few extra parameters required may increase the hardening posture.[/list]
