Цепочка сертификатов выпущена центром сертификации не имеющим доверия microsoft sql server

Сначала обратите внимание, что я знаю, что этот вопрос уже задавался несколько раз. Однако принятые (и не принятые) решения, приведенные к настоящему моменту, не работали в моем случае, поэтому с тех пор должно было произойти что-то существенное, что, вероятно, оправдывает повторный запрос.

В настоящее время я пытаюсь обновить приложение Access 2010 .adp до Access 2019 .accdb. Приложение включает в себя много кода VBA, который использует объекты ADO для подключения и работы на сервере Microsoft SQL (в настоящее время: 2008 R2, но скоро будет обновлен).

Я хотел бы сохранить большую часть кода, что означает, что нужно придерживаться ADO, поэтому мы можем использовать новый драйвер SQL-сервера OleDB (который был обновлен / выпущен в 2018 году). Сервер SQL работает на другом компьютере, чем мое клиентское приложение.

Я не могу установить соединение с сервером SQL из VBA. При выполнении следующего фрагмента кода

Я получаю следующую ошибку при выполнении последней строки:

SSL Provider: The certificate chain was issued by an authority which is not trusted.

ОК, нет проблем, в конце концов, мы нашли все остальные вопросы, относящиеся к той же проблеме, и все предлагают одно и то же решение: добавьте Trust Server Certificate=True; в строку подключения.

Ну, попробовал, но, к моему удивлению, все та же ситуация. Затем я попробовал некоторые другие варианты, такие как TrustServerCertificate=True; или использовать true вместо True, но безрезультатно. Я также попытался добавить Use Encryption for Data=True;, который тоже не помог (чего и следовало ожидать). Кроме того, я попробовал некоторые из фрагментов, которые я нашел при исследовании проблемы, но которые не задокументированы Microsoft как допустимые в строках подключения ADO (например, Encrypt=true или Trusted_Connection=true;); конечно, это ухудшало ситуацию, вызывая другие сообщения об ошибках.

Я понял, что могу решить эту проблему, поместив сертификат сервера SQL в хранилище доверенных корневых сертификатов клиента или заставив сервер SQL использовать сертификат, выданный известным доверенным центром сертификации (например, Let’s Encrypt).

Однако я очень хотел бы знать, почему добавление Trust Server Certificate=true; к моей строке подключения не устраняет ошибку и что я должен добавить туда, чтобы отключить проверку сертификата (и, между прочим, я был бы признателен, если бы мы бы не стали обсуждать, почему это будет плохо, это просто разработка и тестирование в надежной закрытой сети, и я знаю о возможных рисках).

Читать также:  Подарочные сертификаты для коллег-мужчин

У меня есть веб-сайт ASP.Net Webforms, работающий в IIS на Windows Server. Также на этом сервере стоит SQL-сервер.

Все работает нормально с сайтом, но теперь я вижу проблемы с использованием DataAdapter для заполнения таблицы.

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

Вышеупомянутое находится в библиотеке и называется так на сайте веб-форм.

var Summaries = MyLibrary.Fetch(ConnectionString, 1, 111, false);

Итак, как я уже сказал, все работало нормально. Теперь, внезапно вышеупомянутое перестало работать, и Summaries всегда пуст.

Для расследования я попробовал следующее.

Создал тест с использованием xUnit с теми же параметрами, что и на сайте. Они были зафиксированы во время отладки, чтобы гарантировать соответствие. Результат вернул 1 элемент.

Затем я запустил хранимую процедуру в SQL Management Studio, и она сопоставила тест xUnit, вернув 1 элемент.

Затем я проверил SQL Profiler, и здесь все показалось немного странным. Когда веб-формы вызывали библиотеку, в трассировке ничего не фиксировалось.

Вышеупомянутая строка сгенерировала следующее исключение.

Возникло исключение: «Microsoft.Data.SqlClient.SqlException» в Microsoft.Data.SqlClient.dll. Соединение с сервером было успешно установлено, но затем во время входа в систему произошла ошибка. (поставщик: поставщик SSL, ошибка: 0 — цепочка сертификатов была выпущена центром, которому не доверяют.)

Осмотрев стек, я увидел много ответов, в которых говорилось, что мне нужно установить сертификат.

У меня вопрос: если это так, то почему и почему именно сейчас? Ничего не изменилось в коде с того момента, когда он работал до сих пор. Веб-сайт и SQL-сервер находятся на одном сервере Windows. Кроме того, почему тест xunit работает без него, а веб-сайт — нет, когда я отлаживаю на одной машине!

Единственные элементы, которые я сейчас изменил, — это установка .Net 6 и вторник патча, в результате которого были обновлены некоторые обновления и перезапущен сервер.

Моя база данных — SQLExpress 2016SP1

Я могу добавить миграцию, но когда я выдаю

В консоли диспетчера пакетов я получаю сообщение об ошибке

Соединение с сервером было успешно установлено, но при входе в систему произошла ошибка. (поставщик: поставщик SSL, ошибка: 0 — цепочка сертификатов была выпущена центром, которому не доверяют.)

Читать также:  Аутентификация по выбранному сертификату не пройдена операция отменена пользователем ацк госзаказ

Строка подключения имеет вид

DbContext — это

Если я жестко закодирую строку подключения внутри реализации IDesignTimeDbContextFactory, я могу запустить миграции.

Жесткое кодирование строки подключения нежелательно, поэтому я хотел бы получить лучший ответ.

Мне непонятно, зачем нужна реализация IDesignTimeDbContextFactory. (без него моя миграция не удалась)

Я обновил свои Startup.cs и Program.cs, чтобы они соответствовали таковым для вновь созданной программы, реализация которой не требуется.

Services.AddMvc (). SetCompatibilityVersion (CompatibilityVersion.Version_2_1); }

Я обновился до VS2017 версии 15.7.3. Когда я решил повторить проблему и создать первую миграцию, личный кабинет отобразил сообщение

The configuration file ‘appsettings.json’ was not found and is not optional

Когда я всегда отмечал эту копию файла, работали и добавление-миграция, и база данных обновления.

2 ответа

Причина, по которой TrustServerCertificate=True в строке подключения не учитывается, имеет две причины. Во-первых, это недопустимое ключевое слово строки соединения ADO classic (ADODB). Согласно Документация по ключевым словам строки подключения объектов данных ActiveX (ADO), пара ключевое слово / значение должна быть Trust Server Certificate=True (пробелы). Ключевое слово полностью игнорируется без пробелов и не является доверенным в результате.

Однако одно это изменение не будет доверять сертификату из-за спецификации Authentication-SqlPassword. Когда указано ключевое слово Authentication, в сноске к документации выдается:

Для повышения безопасности шифрование и проверка сертификата изменено при использовании аутентификации / инициализации токена доступа свойства или соответствующие им ключевые слова строки подключения. Для получения дополнительной информации см. Ссылка для шифрования и проверки сертификата .

Ссылочная ссылка содержит это важное примечание:

Проверкой сертификата также можно управлять через поле «Значение» записи реестра HKEY_LOCAL_MACHINE SOFTWARE Microsoft MSSQLServer Client SNI18.0 GeneralFlags Flag2. Допустимые значения: 0 или 1. Драйвер OLE DB выбирает наиболее безопасный вариант между реестром и настройками свойства соединения / ключевого слова. Таким образом, драйвер будет проверять сертификат сервера, если хотя бы один из параметров реестра / подключения разрешает проверку сертификата сервера.

Одно из решений состоит в том, чтобы просто удалить спецификацию Authentication=SqlPassword, если вам не требуется улучшенная защита, обеспечиваемая доверием сертификата сервера:

2 Окт 2019 в 12:10

Тем не менее, я хотел бы добавить некоторую предысторию, основанную на исследованиях, которые я провел с момента публикации моего вопроса.

Читать также:  Нужно ли оформлять карантинный сертификат при перевозке в пределах одной области

Проблема в том, что документация Microsoft явно неверна. Пожалуйста, посмотрите на следующий документ:

Эта последняя таблица явно показывает, что Authentication=SqlPawword является допустимым в строках соединения ADO / OLE DB (переформатирование шахты, содержимое не изменено):

Аутентификация SSPROP_AUTH_MODE Указывает используемую аутентификацию SQL или Active Directory. Допустимые значения:

(not set): режим аутентификации определяется другими ключевыми словами. ActiveDirectoryPassword: проверка подлинности Active Directory с использованием идентификатора входа и пароля.

ActiveDirectoryIntegrated: встроенная проверка подлинности в Active Directory с использованием учетной записи Windows, вошедшей в систему. полномочия .

ПРИМЕЧАНИЕ. . Рекомендуется, чтобы приложения, использующие ключевые слова аутентификации Integrated Security (или Trusted_Connection) или соответствующие им свойства устанавливают значение ключевого слова Authentication (или его соответствующее свойство) в ActiveDirectoryIntegrated, чтобы включить новый поведение шифрования и проверки сертификата.

SqlPassword: аутентификация с использованием идентификатора входа и пароля.

ПРИМЕЧАНИЕ. . Рекомендуется, чтобы приложения, использующие аутентификацию SQL Server, устанавливали значение ключевого слова Authentication (или его соответствующее свойство) в SqlPassword, чтобы включить новое шифрование и поведение проверки сертификата.

Он также говорит (опять же, форматирование мое, без изменения содержимого):

Сертификат доверенного сервера SSPROP_INIT_TRUST_SERVER_CERTIFICATE Принимает строки «true» и «false» в качестве значений. Значением по умолчанию является «false», что означает, что сертификат сервера будет проверен.

Каждый разумный человек поймет это в том смысле, что Trust Server Certificate=true отключит проверку сертификата.

Но когда вы смотрите здесь

Вы заметите, что этот документ структурирован так же, как и первый, и что в последней таблице не упоминается параметр Authentication.

Кроме того, я нашел следующий документ:

Читая заголовок («Использование Azure Active Directory»), он должен относиться только к Azure. Тем не менее, я подозреваю, что следующий раздел также относится к локальным установкам сервера SQL (форматирование мое, содержимое не изменено):

Для повышения безопасности новые свойства / ключевые слова соединения соответствуют настройке TrustServerCertificate (и соответствующим ключевым словам / свойствам строки подключения) независимо от настройки шифрования клиента. В результате сертификат сервера проверяется по умолчанию.

Поэтому вполне может быть, что мы также должны изменить значения в реестре, чтобы окончательно отключить проверку сертификата при подключении к серверу SQL через ADO / OLE DB.

28 Фев 2020 в 13:37

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *