Support container-scoped CA roots for BaseContainer proxy workloads

[caarlos0]

Description of the new feature / enhancement

Allow callers to supply public CA certificates that are trusted only inside a BaseContainer, so workloads can use a host-side TLS-intercepting proxy without installing its CA into LocalMachine\Root.

The intended use case is:

1. A proxy runs on the host and presents HTTPS certificates signed by a custom CA.
2. A workload runs in a BaseContainer and connects through that proxy.
3. The CA is installed only in the host user's CurrentUser\Root, or is supplied explicitly to MXC.
4. The workload should be able to trust the explicitly authorized CA without an administrator changing machine-wide trust.

The reporter's existing tests work with the CA in machine roots, but not user roots. Application-specific CA files are a workaround, not transparent support for unmodified Windows TLS clients.

This request is for explicit, container-scoped trust provisioning. It does not require automatically importing all host user roots, sharing private keys, or disabling certificate verification.

Proposed technical implementation details

First establish the supported Windows mechanism. MXC currently passes proxy configuration through the PSEC contract, whose ProxyInfo contains only a URL. It does not provision a certificate store. Adding an MXC configuration field alone is insufficient.

Relevant code at the investigated revision:

• PSEC contract
• BaseContainer policy construction
• Security environment creation and process attachment

Live investigation

A standalone native probe used MXC's generated PSEC bindings on Windows build 26696.1000. The OS advertised PSEC 1.1 and support flags 0xF.

The probe created a temporary CA and server certificate, ran a loopback HTTP CONNECT proxy that terminated TLS, and launched separate native processes in the same security environment. Processes confirmed TokenIsAppContainer=1 and the same AppContainer SID. A second security environment used a different SID as an isolation control.

Attempt	Observed result
CertOpenStore(CERT_STORE_PROV_SYSTEM_W, ..., CERT_SYSTEM_STORE_CURRENT_USER, L"ROOT"), followed by CertAddEncodedCertificateToStore inside BaseContainer	Store opening succeeded; insertion failed with 0x80070005 (E_ACCESSDENIED).
WinRT CertificateStores::GetStoreByName(StandardCertificateStoreNames::TrustedRootCertificationAuthorities()).Add(...)	Reported success, but the CA was not found by the subsequent app-store query and did not establish native trust.
Fresh process in the same security environment after the WinRT operation	Still failed SSL chain validation with 0x800B0109 (CERT_E_UNTRUSTEDROOT).
Real WinHTTP HTTPS request through the host proxy	Failed with 12175 (ERROR_WINHTTP_SECURE_FAILURE); the secure-failure callback reported 0x8 (INVALID_CA).
Repeat with sharedUserCertificates	Did not fix either import/trust path.
Windows curl without an explicit CA file	Failed with SEC_E_UNTRUSTED_ROOT.
Windows curl with --cacert pointing to the same public CA	Successfully received the HTTPS test response from inside BaseContainer.

Both curl controls used --ssl-revoke-best-effort because the disposable test CA had no revocation endpoint. Neither used --insecure; certificate-chain and hostname verification remained enabled.

The probe did not install its CA in the host user or machine root stores. Their registry stores were checked for the probe certificates afterward, and all proxy listeners were stopped.

These results establish that the two tested import approaches do not provide the required native trust on this build. They do not establish that every Windows mechanism is unavailable or that an OS update is necessarily required.

Windows dependency / open question

What supported API can provision root trust for an unpackaged BaseContainer created through CreateProcessSecurityEnvironment, such that WinHTTP/Schannel clients in that environment use it?

• If an existing mechanism supports this, wire it into MXC before workload startup.
• Otherwise, coordinate Windows support for container-scoped root provisioning, then expose it through MXC.
• Do not use host root-store mutation, undocumented registry manipulation, or an application-specific CA environment variable as a substitute for native container-wide trust.

Acceptance criteria

• An explicitly supplied public CA allows an unmodified WinHTTP client inside the target BaseContainer to complete HTTPS with normal certificate verification.
• A separate container without that CA remains unable to trust it.
• Neither the host user root store nor the machine root store is modified.
• Omission preserves existing behavior. Unsupported hosts or containment tiers reject the requested feature rather than silently ignoring it.
• Provisioning failures prevent workload startup, and certificate state has a defined cleanup/lifetime contract.
• The development contract, generated artifacts, affected SDK surfaces, documentation, and host-dependent regression coverage are updated together.
• Documentation distinguishes Windows-native trust from applications that maintain independent CA bundles.