#.net-core
Вопрос:
У меня есть API .net Core 3.1, работающий на коробке redhat linux. Поставщик, с которым разговаривает мой API, вчера обновил его, и с тех пор мы не смогли подключиться к их сервису из самого API. Первоначально наши попытки завить URL-адрес также не увенчались успехом, пока они не исправили ситуацию с сертификатом SSL на своей стороне. Теперь завиток работает нормально (без -k, конечно, просто «завиток -v %FullUrl%») Он возвращает ожидаемые XML — данные из их сервиса.
Однако сам API по-прежнему не поддерживает SSL-соединение с той же ошибкой, которую он получал все это время. «Не удалось установить SSL-соединение, см. Внутреннее исключение. — Внутреннее исключение: Удаленный сертификат недействителен в соответствии с процедурой проверки.» Я попытался перезапустить службу API, а затем перезагрузить всю коробку Linux, но безрезультатно. Я хотел бы иметь возможность лучше регистрировать шаги попытки подключения SSL, но я не смог найти в Google ничего, что, по-видимому, работает для .net core, всего несколько версий .net framework, которые кажутся многообещающими… Если бы я мог заставить их работать на .net core!
Все, что связано с сертификатом, кажется, устранено, потому что, как уже упоминалось, завиток работает просто отлично. Кроме того, openssl s_client для их хоста работает нормально. Идеи заканчиваются, и вот я здесь. Заранее спасибо!
Комментарии:
1. Привет, есть ли какой-нибудь способ доверять сертификату SSL, как в SQL-соединении, ничего не навязывая? Вы пробовали почтальона, чтобы узнать, можете ли вы отладить какую-либо дополнительную информацию?
2. Да, я мог бы просто обойти проверку сертификата, но это открывает возможности для атак MitM. Звонки почтальона тоже работают нормально по какой-то причине. Просто API не удается подключиться по протоколу SSL.
3. Доверительный сертификат не является постоянным решением. Просто чтобы посмотреть, работает ли все остальное. У вас есть «useSSL»: true где — то в настройках? Также в Startup.cs у вас есть app.UseHttpsRedirection();? SSL всегда сложен. Посмотрите, совпадают ли домены в версии cert, шифров, TLS.
Ответ №1:
Окончательный ответ здесь был на самом деле довольно шокирующим. Я собрал консольное приложение, которое регистрировало множество битов информации о соединении SSL, включая множество точек данных в каждом сертификате в цепочке. Оказалось, что .net Core получал другой сертификат, чем curl или openssl. 2-й из 3 сертификатов в цепочке. Сертификат был «деактивирован» через openssl, но поскольку он не был удален, .net Core все равно его забрал. Все, что я видел, говорит о том, что .net Core использует те же сертификаты для подключения, что и openssl, но это совершенно очевидно ЛОЖЬ! 🙂