K13 Former Urls are redirecting to http instead of https

Ah thank you Juraj, it looks like the http is coming from our load balancer. Thanks very much!

Sounds like a classic SSL termination issue at the load balancer. Make sure it's passing the 'X-Forwarded-Proto' header so Kentico knows it's an HTTPS request. Enabling 'Enforce HTTPS' in the settings should also help clean up those double redirects. Good luck!

Hi guys,

I know the feedback in this thread is a little old. The problem was put on hold while we were getting a new load balancer/WAF.

We now have full control over the forwarded headers, so we continued investigating. Unfortunately, correctly forwarding X-Forwarded-Proto did not solve the problem.

Our architecture is:

Client HTTPS → FortiWeb → HTTP → IIS :80 → ASP.NET Core The important observation is that the Location header is already HTTP inside the ASP.NET Core application, so FortiWeb is not changing the scheme in the response.

X-Forwarded-Proto=https is correctly processed by ASP.NET Core and results in Request.Scheme=https.

We also changed URLHelper.SSLUrlPort from 0 to 443, but the behavior did not change.

A sanitized log from the problematic request:

Request.Scheme: https Request.IsHttps: True Request.Host: <site-host> Response.Headers.Location: http://<site-host>/testredirect

RequestContext.IsSSL=True URLHelper.SSLUrlPort=443

CurrentSite.DomainName=<site-host>/admin SitePresentationURL=https://<site-host>/

Server VAR: HTTPS=off SERVER_PORT=80 HTTP_X_FORWARDED_PROTO=https HTTP_X_FORWARDED_HOST=

UseForwardedHeaders() is the first relevant middleware in the pipeline.

The Former URL entry exists correctly in CMS_PageFormerUrlPath, and the target URL itself works correctly.

So at this point we have:

• Request.Scheme = https
• Request.IsHttps = true
• X-Forwarded-Proto = https
• RequestContext.IsSSL = true
• URLHelper.SSLUrlPort = 443
• Presentation URL is HTTPS

but Kentico's Former URL handling still generates: Location: http://<site-host>/testredirect

My suspicion is therefore that the HTTP URL is being generated by the Kentico 13 Former URL redirect handling in the ASP.NET Core integration.

Does anyone have a clue what else I could investigate, or which Kentico component/method is responsible for generating the Former URL redirect?

Thanks! Tomek

Is the Presentation URL set with HTTPS protocol? Do you have also the SSL accelerator in place? Could you please reproduce the issue using an out of the box installation and tell us the steps to follow so we can take a deeper look? So far I was unable to reproduce it. I might be missing something.

Hi Juraj, Thanks for the feedback.

The Presentation URL is configured with HTTPS, and we have an SSL accelerator (FortiWeb) in place. I will try to reproduce the issue with an out-of-the-box installation. In the meantime, I found a workaround that changes the Location header from HTTP to HTTPS when the redirect is generated for the same host:

app.UseForwardedHeaders();
app.Use(async (context, next) =>
{
    await next();

    if (context.Response.Headers.TryGetValue(HeaderNames.Location, out var locationValues)
        && Uri.TryCreate(locationValues.ToString(), UriKind.Absolute, out var location)
        && string.Equals(location.Scheme, Uri.UriSchemeHttp, StringComparison.OrdinalIgnoreCase)
        && context.Request.IsHttps
        && string.Equals(location.Host, context.Request.Host.Host, StringComparison.OrdinalIgnoreCase))
    {
        var httpsLocation = new UriBuilder(location) { Scheme = Uri.UriSchemeHttps, Port = -1 };
        context.Response.Headers[HeaderNames.Location] = httpsLocation.Uri.ToString();
    }
});

Best Tomek