WSUS on Server 2025 (downstream/autonomous) fails at SyncConfigUpdatesFromUSS with cert trust error — verified proxy, cert chain, and TLS all functional

Environment:

• Windows Server 2025, WSUS role (WID-backed downstream server)
• Configured as downstream, autonomous (not replica): IsReplicaServer=False, SyncFromMicrosoftUpdate=False, UpstreamWsusServerName set to internal upstream WSUS server, port 8531, SSL
• Internal two-tier AD CS PKI (offline root + enterprise subordinate CA); WSUS SSL cert chain independently verified valid via certutil -verify
• Outbound internet access via Squid proxy at 3128; confirmed functional via raw HTTPS test (Invoke-WebRequest -Proxy returns real 404 from sws.update.microsoft.com) and via manual CONNECT + SslStream handshake (TLS 1.3 negotiates cleanly, real Microsoft cert returned: CN=sws.update.microsoft.com, issuer Microsoft Update Secure Server CA 2.1)

Symptom: Every sync attempt (category-only and full, via both PowerShell StartSynchronizationForCategoryOnly()/StartSynchronization() and the WSUS Configuration Wizard GUI) fails identically:

WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
   at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
   at Microsoft.UpdateServices.ServerSync.ServerSyncCompressionProxy.GetWebResponse(WebRequest webRequest)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetAuthConfig()
   at Microsoft.UpdateServices.ServerSync.ServerSyncLib.InternetGetServerAuthConfig(ServerSyncProxy proxy, WebServiceCommunicationHelper webServiceHelper)
   at Microsoft.UpdateServices.ServerSync.ServerSyncLib.Authenticate(...)
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.SyncConfigUpdatesFromUSS()
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

This is a UssCommunicationError occurring during SyncConfigUpdatesFromUSS — the pre-flight handshake against Microsoft's Update Sync Service — and it blocks the entire subscription pipeline, even though this is a downstream server that should only depend on its internal upstream WSUS server for content. Confirmed via a completely blank product/classification catalog (only the default "Windows Server 2003" seed categories) even after successful test approvals on the upstream server.

Steps already taken, all verified independently but none resolving the error:

1. Confirmed MUUrl = https://sws.update.microsoft.com (current, correct endpoint)
2. wsusutil ConfigureSSLProxy <proxy> <port> -enable — confirmed success message, confirmed squid logs show real TCP_TUNNEL/200 connections to sws.update.microsoft.com on later attempts
3. WSUS-native proxy config ($config.UseProxy, ProxyName, ProxyServerPort) set and confirmed persisted
4. netsh winhttp set proxy set at OS level
5. Machine-wide .NET Framework SchUseStrongCrypto/SystemDefaultTlsVersions registry keys set (both 32/64-bit hives)
6. SChannel protocol registry keys explicitly enabled for TLS 1.2/1.3 (Client+Server) — confirmed via SoftwareDistribution.log showing the flip from implicit ("subkey not found. Protocol is enabled") to explicit ("SCHANNEL Protocol 'TLS 1.2' enabled") after this change
7. w3wp.exe.config — added <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/> per documented Fix 1 for this exact error class; iisreset applied
8. Found and corrected an explicit usesystemdefault="false" proxy override in WsusService.exe.config (separate from w3wp.exe.config — this is the standalone WsusService.exe process's own config, which had been silently ignoring all system/WSUS proxy configuration). Rewrote to explicit proxy address + added the same AppContextSwitchOverrides runtime block. Restarted WsusService.
9. Manually captured and inspected the actual certificate presented by sws.update.microsoft.com via raw TcpClient+SslStream: valid, current, chains to Microsoft Root Certificate Authority 2011 once the intermediate (Microsoft Update Secure Server CA 2.1) was manually imported to fix an initial PartialChain error — after that fix, X509Chain.Build() with RevocationMode=NoCheck returns True cleanly.
10. Disabled MURollupOptin (was True) in case it was triggering an independent USS handshake — no change.

None of the above changed the outcome. Failures range from sub-1-second (suggesting no network attempt) to 19+ seconds (suggesting a genuine handshake attempt that still fails at cert validation) with no consistent pattern tied to which fix was most recently applied.

Question: Is there a known compatibility issue between WSUS on Server 2025 and the current sws.update.microsoft.com TLS/cert requirements specifically in ServerSyncCompressionProxy/SoapHttpClientProtocol, separate from the OS-level/.NET Framework-level TLS configuration surface? Is there a specific KB, Server 2025 cumulative update, or additional config location (beyond machine.config, w3wp.exe.config, and WsusService.exe.config) that governs TLS/cert validation specifically for this legacy SOAP client used by CatalogSyncAgentCore?

Any pointers toward the actual root cause — or confirmation this is a known, currently-unfixed Server 2025 WSUS issue — would be genuinely helpful at this point.