Reverse proxy

Responsibilities

Provide HTTP(S) ingress for LEF-hosted services (hostname-based routing).
Enforce audience boundaries (public vs internal) at the routing layer.
Provide a stable “front door” so backends can move without changing public entry points.

Host inventories / IPs / login profiles: see web.core.lef and Servers.
Authoritative service entry points: see Services.
Procedures and troubleshooting: see Proxy & routing and Infra troubleshooting.

See NGINX ingress (public vs internal) for the operational procedure and test checklist.

Public unknown HTTPS cannot be redirected safely. Without a matching certificate, the TLS handshake can’t complete; the public defaults use ssl_reject_handshake on; to prevent “default vhost” leakage.
Internal unknown HTTPS redirects still need a certificate. The internal default :443 uses an internal cert so it can return a redirect. For a clean browser UX, the cert should cover the internal zones you expect (SANs / wildcards).
A wildcard does not cover the zone apex. *.docs.lef does not match docs.lef, so docs.lef needs its own vhost and certificate SAN.
Known-domain checks must not cross public/internal boundaries. This design keys the map by "$server_addr:$host" so internal-only names don’t get redirected on public VIP listeners.
If you issue internal CA certs via HTTP-01 (webroot), keep the ACME challenge location on the internal 192.168.20.2:80 default server too.
Avoid variable-based ssl_certificate_key for root-only keys. When ssl_certificate / ssl_certificate_key use variables, NGINX resolves and loads files at handshake time in worker processes, which commonly triggers Permission denied if your private keys are root:root and not readable by the worker user.