Retrieving OpenID-Configuration endpoint fails over SSL

[obosha]

I've tried to replicate in numerous other ways (outside of IdentityServer) to isolate issue but cannot recreate it.

I have a .Net Core Application that has both IdentityServer4 and IdentityServer4.AccessTokenValidation applied to it. The access token validation middleware is used to lock down additional endpoints that I have written myself outside of IdentityServer4 itself.

The token validation apparently calls the .well-known/openid-configuration endpoint to get the discovery document, and this works when I run under HTTP alone. However, if I try to run my service under HTTPS, for some reason the call to get the discovery document fails.

I can retrieve this discovery document just fine from other services, Postman, and Chrome. The SSL cert is trusted, and in my Trusted Root Certification Authorities store, so the problem is not there.

It SEEMS to be something related to my service calling itself for the discovery document. But when I simplify this in a test app that calls itself (in the same way), without all the IS4 dependencies, it works fine.

Any thoughts on why there might be an issue with IS4 and IS4.AccessTokenValidation running in the same app being that it must call itself??

The two most inner errors say: "System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception." and then "The client and server cannot communicate, because they do not possess a common algorithm."

[leastprivilege]

Is that on Azure?

[obosha]

Hi Dominick... no, this is all running locally, but it happens on deployed server running behind IIS as well. In both cases, it's hosted using Kestrel.

I'm going to try put together a small example using your starter "Samples", and if I can replicate with a small project, I'll post to Github for better review.

I'm wondering if it's Kestrel somehow, but I don't understand why I can call the same discovery document from anything outside the service in question and it works fine (it's just the calling of itself that seems to fail).

[obosha]

Here you go Dominick. I was able to replicate the problem easily just using the Startup samples for IdentityServer4.

You can find solution that recreates the problem here: https://github.com/obosha/IdentityServer4

Let me know if you have questions.

[obosha]

Further note, this appears to only happen when targeting NET452. When I run the project as .NetCoreApp, it works fine.

So there must be some conditional code somewhere in the chain of libraries that behaves differently. Trying to figure out which... ugh.

[obosha]

I verified that this is in fact a bug today. Took me about 8 hours to track down the problem. Very frustrating day! :)

I created a pull request with a proposed solution if you're happy with it.

Essentially the problem is that when targeting 452, HttpClient doesn't support the latest TLS algorithms by default, and so you need to add a line of code to "force" it to do so. Without this line of code, it will fail to connect to hosts that are enforcing the later versions of TLS in play today.

Depending on what framework is targeted when deploying IdentityServer4.AccessTokenValidation, it can fall prey to this problem when using NET452.

[leastprivilege]

Will this also work with older servers - like 2012 R2?

[leastprivilege]

..and thanks for researching this!

[obosha]

This is a .Net Framework configuration reality in 4.5, so I'm not sure why OS (e.g. 2012 R2) would have anything to do with it per se.

In the end, and as Dominick noted on the side to me, having the user set the global configuration is likely the preferred approach and thus doesn't belong in this middleware.

My minimal suggestion is that a more specific error message (warning or error) is considered for this problem to help users isolate it much quicker. But other than that, this was just a learning experience. :)

[leastprivilege]

Here are the current docs. Could you please add some text about the error behavior and how to fix it to that. We will soon expand this single page into a whole section about access token validation. But this would be a start.

thanks!

[obosha]

When you say, "here are the current docs", what were you referring to?? Am I missing a link or something?

[leastprivilege]

sorry

https://identityserver4.readthedocs.io/en/release/configuration/apis.html

[obosha]

Thank you. I have updated the documentation and submitted a pull request.

On Wed, Feb 8, 2017 at 12:00 AM, Dominick Baier notifications@github.com wrote:

sorry

https://identityserver4.readthedocs.io/en/release/configuration/apis.html

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/IdentityServer/IdentityServer4.AccessTokenValidation/issues/48#issuecomment-278237097, or mute the thread https://github.com/notifications/unsubscribe-auth/AKFluvZ3e_81k9V4EhnpY2Ci0oy-xZXuks5raVoWgaJpZM4L0mIY .