Applies to version: 2026.1 and above; author: Tadeusz Baum, Lily Adamowicz

Related documentation

A detailed description of the functionalities mentioned herein and their configuration can be found in the following sections of the WEBCON Help:

• Authentication providers
• Alternative Application Addresses

Other related Community articles include:

• SSL Offloading vs WEBCON BPS Portal

Introduction

Publishing a .NET application behind a reverse proxy is one of the most common deployment scenarios. In this model, the end user communicates exclusively with a public HTTPS endpoint, while traffic is then forwarded to the application layer running inside the infrastructure. This publication model separates the entry layer from the application itself, simplifies certificate management, and limits the direct exposure of the IIS server to the Internet.

In the scenario described here, the reverse proxy accepts external traffic, handles the HTTPS connection, and forwards requests to IIS and then to the .NET application, in this case WEBCON. In such a setup, it is essential not only to route traffic correctly, but also to preserve information about the client’s original request. Microsoft explicitly states that applications running behind a proxy or load balancer must receive information about the original scheme, host, and client address. Otherwise, they may generate incorrect URLs, redirects, or authentication-related data.

IMPORTANT: Starting with version 2026, the ForceHttpsOnProxy setting is no longer supported. If a 2025 environment relied on this mechanism, after upgrading you must configure the reverse proxy and forwarded headers handling according to the instructions below. Otherwise, the application may interpret traffic as HTTP rather than HTTPS, which can result in incorrect redirects, external authentication errors, and invalid URL generation.

Assumptions

This article describes a reference publication model in which the communication path is as follows:

Client → HTTPS → reverse proxy → HTTP/HTTPS → IIS → WEBCON

In this setup, the user accesses the application through a single public HTTPS endpoint, while the IIS server and the application itself do not need to be exposed directly to the Internet. The reverse proxy layer acts as the public entry point. A similar publication model and SSL offloading approach are described in a separate article.

Upgrading an environment from version 2025 to 2026

In environments that previously used the ForceHttpsOnProxy setting, upgrading the platform to version 2026 alone does not guarantee that the existing behavior will be preserved. After the upgrade, you must ensure that the reverse proxy forwards the X-Forwarded-* headers and that the application processes them correctly.

Without this configuration, the Portal may interpret requests as HTTP rather than HTTPS. In practice, this most often results in incorrect redirects and issues with external authentication, for example through ADFS or Microsoft Entra ID, when the generated redirect_uri does not match the public HTTPS address.

If the environment worked correctly before the upgrade by using ForceHttpsOnProxy, then after migrating to version 2026 you should verify the reverse proxy configuration, the way headers are forwarded, and the handling of forwarded headers on the application side.

Why reverse proxy configuration matters

The most common issue in this type of environment is not forwarding the request to the backend itself, but the fact that the application begins to “see” internal traffic instead of the user’s original request. If the public HTTPS connection terminates at the reverse proxy and the request is then forwarded to IIS over HTTP, the application may incorrectly assume that the client connected over HTTP. This typically leads to problems with redirects, incorrectly generated links, and difficulties with external authentication. In such scenarios, Microsoft recommends using headers forwarded by the proxy and processing them on the application side.

In practice, this means that the reverse proxy should forward to the application at least the following information:

• the public host,
• the original request scheme, that is, HTTP or HTTPS,
• the client’s source IP address.

This information is typically passed using the X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-For headers. At the same time, the public host should not be accepted unconditionally. On both the reverse proxy and application sides, it is advisable to restrict accepted hostnames to known, valid values in order to avoid issues caused by an unexpected Host header.

Preparing the environment

Before starting the configuration, it is worth defining the target public hostname of the service, for example app.example.com, as well as the TLS termination model. In the scenario presented here, the certificate is installed on the reverse proxy server, which handles the HTTPS connection from the user side. On the infrastructure side, network communication rules should also be planned so that Internet traffic is directed exclusively to the reverse proxy layer, while access to IIS is limited to the internal network or only to the reverse proxy server.

From a network perspective, this usually means:

• exposing port 443 on the reverse proxy server,
• optionally keeping port 80 available only for redirection to HTTPS,
• allowing communication from the reverse proxy to IIS only over an internally defined port,
• preserving information about the IP address or address range of the reverse proxy server, as this will be required when configuring trusted proxies on the application side.

Configuring trusted Proxies

For an application running behind a reverse proxy to correctly interpret forwarded headers, the proxy server must be marked as trusted.

If the reverse proxy runs on the same server as the application and forwards traffic to localhost, additional configuration is usually not required. The localhost address is treated as trusted by default.

If the reverse proxy runs on a different server, its IP address or IP range must be added to the list of trusted proxies. To support this, the application provides configuration under the Security:ForwardedHeaders node, which can be set in the standard configuration files or by using environment variables.

Available options:

• ForwardedHeaders – the list of headers to be processed; by default: X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host,
• KnownProxies – the list of trusted proxy server addresses; by default, it contains only localhost,
• KnownIpNetworks – the list of trusted networks; useful when the proxy is assigned a dynamic IP address; empty by default.

Sample configuration:

"Security": {
    "ForwardedHeaders": {
      "ForwardedHeaders": [
        "XForwardedFor",
        "XForwardedProto",
        "XForwardedHost"
      ],
      "KnownProxies": [
        "10.234.111.4"
      ],
      "KnownIpNetworks": [
        "10.0.0.0/8"
      ]
    }
  }

In specific cases, it is also possible to enable forwarded headers processing without validating trusted proxies. However, Microsoft does not recommend this approach, as it may introduce a security vulnerability. To enable it, set the ASPNETCORE_FORWARDEDHEADERS_ENABLED environment variable to true.

Detailed information about how this mechanism works, as well as configuration guidance for specific reverse proxy servers, can be found in the Microsoft documentation.

Post-deployment testing

After completing the configuration, it is worth performing several basic tests to confirm that the entire communication path is working correctly.

First, verify that HTTP requests are redirected to HTTPS and that the user always reaches the public address with a valid certificate. Next, check whether the application opens correctly under the public hostname and does not generate incorrect absolute links. If external authentication is used, confirm that the redirect_uri parameter contains an https://... address rather than http://.... The final step should be to ensure that the IIS server is not directly reachable from the Internet and that access to the backend is restricted to the Nginx server or the administrative network.

Common Issues

If the application redirects the user to HTTP instead of HTTPS, this usually indicates that X-Forwarded-Proto is not being handled correctly or that the proxy is not trusted. If an external authentication flow fails with a redirect_uri mismatch error, the most common cause is a discrepancy between the application’s public address and what the backend recognizes as the request scheme and host. In turn, if the client’s correct IP address is missing from the logs, this most often points to a problem with forwarding or processing X-Forwarded-For. These scenarios are consistent with the typical issues described in the ASP.NET Core documentation for applications running behind a proxy.