Search code examples
identityserver4openid-connectasp.net-core-2.2x509certificate2

IdentityServer4 IDX20108 invalid as per HTTPS scheme

I'm new to IdentityServer4 (2.5) and certificate setup so please bear with me. I think that I've chased down everything I could. I am using it with ASP.Net Core 2.2.0 in a proof of concept app. I have OpenIdConnect with an authority app and a client using cookies with X509Certificate2. Works great on my local machine; however, when I deploy to IIS I get this error:

System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://my.com/mpauth/.well-known/openid-configuration'. ---> System.ArgumentException: IDX20108: The address specified 'http://my.com/mpauth/.well-known/openid-configuration/jwks' is not valid as per HTTPS scheme. Please specify an https address for security reasons. If you want to test with http address, set the RequireHttps property  on IDocumentRetriever to false.

The problem is here - http://my.com/mpauth/.well-known/openid-configuration/jwks. If I put that in the browser I get an error; however, if I change http to https I get the data. What setting controls this?

Solution

  • TL;DR

    In most cases IdentityServer defers the base hostname/URI from the incoming request but there might be deployment scenarios which require enforcing it via the IssuerUri and/or PublicOrigin options as documented here.

    More Info

    The URL you are getting in your exception is part of the discovery lookup. It is necessary for validating tokens (e.g. in an applications auth middleware). There should be a first request to .../.well-known/openid-configuration (the main discovery document) that refers to several other URIs and one of them should be the jwks (signing key sets). In most cases the other URIs in openid-configuration will point to the same primary hostname and protocol scheme your identity server is using. In your case it looks like the scheme changes to HTTP which might be unwanted in this day and age.

    Is it possible, that the deployed IdentityServer lives behind a load balancer/SSL termination appliance? This could cause behavior.

    I am not sure about IIS details but there might also be some kind of default hostname/URI thing at play.