Answer
This is expected, deliberate behavior — the application must always be accessed via its configured System URL (also called the access point or public URL), and MWS validates the incoming request's Host header against that specific configured System URL rather than accepting any DNS-resolvable, certificate-valid hostname. If there's a proxy, load balancer, or DNS layer in front of MWS, it needs to forward that exact System/public URL as the Host header on every request. Trying to access the application via any hostname other than its configured System URL — even one that resolves correctly and passes certificate validation — produces this same 403 error, since the mismatch is checked at the Host-header level, not at the DNS/certificate level.