nx_aw_mtls_inject.nx

nx_aw_mtls_inject.nx -- inject the VERIFIED mTLS client identity into the decrypted HTTP request as an X-Nishi-Cert-Identity header, so the loopback backend can serve-by-identity. This is the genuinely NEW logic of the sovereign mTLS carrier (the TLS handshake + the reverse-proxy mechanics are already proven: run_ecdsa_mtls loopback+interop 6/6, nx_aw_tlsproxy live for the CMS admin). THE PROXY IS THE TRUST BOUNDARY (rule 12, defensive at boundaries). Two invariants, both security-floor: 1. ALWAYS strip any client-supplied X-Nishi-Cert-Identity header from the request -- else a NO-cert client simply sends its own and the backend trusts a SPOOFED identity. Strip happens for every auth value (0/1/-1) and only inside the HEADER section (a body that happens to contain the string is left verbatim). 2. Inject the REAL identity ONLY when auth==1 (a client cert was PRESENTED and its CertificateVerify VERIFIED this handshake). auth==0 (no cert) or auth==-1 (bad cert) => no identity injected = request- not-require / NEVER-LOCKOUT (the backend falls back to its X-Nishi-Session header path exactly as today). Identity = the cert Subject CN (hex(user_id_hash)) via the canonical nx_mtls_cert_identity -- the SAME stable id the OPAQUE/HR stack keys on, so the backend maps it with the existing uidhex->handle index. license_tier: ORIGINAL expect_exit: 0