Moodle unfortunately insists on being able to see the external-facing HTTPS address. Which behind reverse proxies (never heard them called a content switch before) is a pain. There is a config setting for helping to support it though (something like $CFG->sslproxy = true; in config.php) - did you try that?
We decided against SSL offloading for this reason, and actually butchered the wildcard certificate that sits on the reverse proxy and made it Apache-friendly. But a self-signed certificate may work, if only to keep moodle thinking it's an https entity when really people are accessing it via a reverse proxy.
I suspect also you wouldn't be able to reliably point internal traffic to the server, using a self-signed cert. Chrome these days would probably laugh at the idea of letting you access a site using a self-signed cert (I've not touched self-signed for years).
We've used SSL/TLS offloading since 2009 with Moodle 1.9. We have never had any issues with it. Our newest setup has load balancers and reverse proxies with SSL offload happening on the load balancer itself - no issues with Moodle. It doesn't care, unless you're trying to hit a node directly.
It does require $CFG->sslproxy to be set to true, and the moodle wwwroot to be set to https://<site url> - but past that there isn't anything else needed.
The only time it is an issue is if you hit a web-node directly, as it will then redirect back to the address it is configured to use in the config.php.
You could run TLS between the load balancer and the Moodle nodes - but this is really only required if you don't trust the network between them (i.e. if you were using Cloudflare or another cloud service, for example). A self-signed cert would work OK for communication between the load balancer and the web nodes (LB might need a certificate added to trust it), or you could use Lets Encrypt for this part, as they're free.
kindly find the below link to install SSL on content switching (Apache-based load balancer)