"Issuer name does not match authority" error when using reverse proxy in front of SSL terminating load-balancer

Question

I am trying to deploy our data API using APIgee proxy. The data API is using .NET Core 3.0 on an IIS server on AWS EC2 instance:

When I make a call to the data API using Apigee proxy I am getting this exception on the IIS server:

Category: IdentityServer4.AccessTokenValidation.IdentityServerAuthenticationHandler
EventId: 0
RequestId: 80003dde-0002-fe00-b63f-84710c7967bb
RequestPath: /v0.1/wells/dpr
SpanId: |74716527-4b0a0a0f46d32af3.
TraceId: 74716527-4b0a0a0f46d32af3
ParentId: 

Policy error while contacting the discovery endpoint https://example.com: Issuer name does not match authority: http://example.com

Exception: 
System.InvalidOperationException: Policy error while contacting the discovery endpoint https://example.com: Issuer name does not match authority: http://example.com
   at IdentityModel.AspNetCore.OAuth2Introspection.PostConfigureOAuth2IntrospectionOptions.GetIntrospectionEndpointFromDiscoveryDocument(OAuth2IntrospectionOptions options)
   at IdentityModel.AspNetCore.OAuth2Introspection.PostConfigureOAuth2IntrospectionOptions.InitializeIntrospectionClient(OAuth2IntrospectionOptions options)
   at IdentityModel.AspNetCore.OAuth2Introspection.OAuth2IntrospectionHandler.LoadClaimsForToken(String token)
   at IdentityModel.AspNetCore.OAuth2Introspection.OAuth2IntrospectionHandler.HandleAuthenticateAsync()
   at Microsoft.AspNetCore.Authentication.AuthenticationHandler`1.AuthenticateAsync()
   at Microsoft.AspNetCore.Authentication.AuthenticationService.AuthenticateAsync(HttpContext context, String scheme)
   at IdentityServer4.AccessTokenValidation.IdentityServerAuthenticationHandler.HandleAuthenticateAsync()

From what I can see, the issue here is that the Loab-balancer is performing the SSL termination and making a call to the IIS server using HTTP and not HTTPS that is why the issuer name does not match. I have tried adding UseForwardedHeaders line to our .NET Core API:

public static IApplicationBuilder UseIdServer(this IApplicationBuilder app)
{
        app.UseForwardedHeaders(new ForwardedHeadersOptions
        {
            ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
        });
        app.UseIdentityServer();

        return app;
}

which is called here

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app
        .UseCORS()
        .UseCustomCookiePolicy(env)
        .UseIdServer()
        .UseRouting()
        .UseAuth()
        .UseEndpoints(endpoints =>
        {
            endpoints.MapControllers();
        });
}

However, that did not fix the issue.

Update 1: I have also tried configuring the ForwardedHeaders like that in my startup.cs as suggested on the MS docs without success:

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders =
            ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    });
...
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseForwardedHeaders();
    ...
}

Update 2 I tried overriding the request schema to https in the Configure method in Startup.cs as suggested in MS docs:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.Use((context, next) =>
    {
        context.Request.Scheme = "https";
        return next();
    });
    ...
}

That has resolved the issue. However, I am wondering how I can properly configure the X-Forwarded-* headers in the middleware.

Update 3 Thanks to @Chen who pointed me to resource which stated that I can configure the ForwardedHeaders in the Configure method like so

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
...
    app.UseForwardedHeaders(new ForwardedHeadersOptions
    {
        ForwardedHeaders = ForwardedHeaders.XForwardedProto
    });

...
}

Previously I tried the same but I used both ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto. For some reason, using just ForwardedHeaders.XForwardedProto resolved the issue.