IDX10803: невозможно создать для получения конфигурации

У меня была та же проблема - кажется, что сертификат SSL не является доверенным. Чтобы решить эту проблему, я переместил экспресс-сертификат IIS «localhost» из Personal CertStore в доверенные корневые центры сертификации, и проблема исчезла.

У меня была эта проблема, и мне нужно было доверять сертификату в соответствии с Robert Muehsig answer.

Но этого самого по себе было недостаточно. Я использую аутентификацию Bearer Token Authentication. Дальнейшее копание показало, что мне нужно установить для флага DelayLoadMetadata значение true.

Итак, в моем запуске веб-API:

app.UseIdentityServerBearerTokenAuthentication(
    new IdentityServerBearerTokenAuthenticationOptions
{
    DelayLoadMetadata=true
});

После этого и изменения доверия к сертификату он начал работать. Я знаю, что это не та же конфигурация, что и исходная проблема, но во время поиска я постоянно натыкался на этот пост, поэтому решил разместить его здесь для всех, кто наткнется на него...

Насколько я помню, эта ошибка возникает в основном из-за проблемы с доверием к сертификату / доступом к сети. Поскольку вы запускаете все компоненты на локальном хосте, это определенно не проблема сети. Я предполагаю, что вы работаете из среды VS Dev.

Пара вещей:

• Попробуйте разместить компоненты на сервере IIS
• Вместо использования localhost создайте самозаверяющий сертификат для своего хоста и попробуйте назначить свое имя хоста в качестве имени субъекта (обратите внимание: сертификат idsrv3test для подписи и самозаверяющий сертификат для хоста SSL)

Кроме того, назначьте разрешения на чтение сертификата, как описано здесь https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Certificates

Если вы все еще сталкиваетесь с этой проблемой, попробуйте отслеживать трафик через Wireshark (в этом случае Fiddler не будет работать).

В целях тестирования я добавил приведенный ниже блок в качестве первой части промежуточного программного обеспечения в моем конвейере. Это фактически будет регистрировать исключение всякий раз, когда оно возникает. Это привело меня к выводу, что мой 500-й на самом деле был 401-м.

        appBuilder.Use(async (context, next) =>
        {
            try
            {
                await next();
            }
            catch(Exception ex)
            {
                Log.Error(ex, "OWIN error.");
            }

        });

Другой разработчик в команде помог найти проблему. На узле проверки подлинности Windows, работающем на порту 44305, отключен анонимный доступ. Когда это было включено, перенаправленный процесс снова начал работать.

К сожалению, на самом деле мы не обнаружили ошибку, но методом проб и ошибок (взломом) она была исправлена. Мой главный вопрос заключался в том, как мне отлаживать приложение OWIN, чтобы я мог видеть детали HTTP 500. Я бы хотел, чтобы журналы IdentityServer3 могли записывать ответ от хоста Win Auth. Кроме того, почему это не код ответа 401?

Это также может быть связано с прокси-аутентификацией. Попробуйте проверить трафик fiddler для вызовов login.microsoftonline.com:XXX и посмотрите, возвращает ли он код ошибки 407.

Если вы видите код ошибки 407, вам необходимо включить прокси-аутентификацию в web.config.

Моя команда столкнулась со следующими проблемами: [Ошибка] Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler: при обработке сообщения возникло исключение. System.InvalidOperationException: IDX10803: невозможно получить конфигурацию из: 'https://[ваш домен сервера идентификации]/.well- известная/openid-конфигурация». ---> System.IO.IOException: IDX10804: невозможно получить документ с: 'https://[ваш сервер идентификации домен].известная/открытая-конфигурация'. ---> System.Net.Http.HttpRequestException: попытка подключения не удалась, поскольку подключенная сторона не ответила должным образом через определенный период времени, или установленное соединение не удалось, поскольку подключенный узел не ответил ---> System.Net.Sockets .SocketException: попытка подключения не удалась, поскольку подключенная сторона не ответила должным образом через определенный период времени, или сбой установленного подключения, поскольку подключенный хост не смог ответить на System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken CancellationToken) --- Конец внутренней трассировки стека исключений ---

Мы потратили много времени, чтобы выяснить причину. Наконец, просто очень простая ошибка, в среде UAT настройка файла hosts была неправильной в «C:\Windows\System32\drivers\etc». Домены, определенные в файле hosts, не соответствуют привязке доменов в IIS.

В моем случае я был тупым и остановил хост IdentityServer. Как только я запустил его, другие службы снова смогли получить метаданные, которые они искали.