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