Ошибка проверки SSL / сертификата, несмотря на то, что TrustServerCertificate = true в строке подключения

Question

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

Сказавthis:

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

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

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

Dim cnTemp As Connection
Set cnTemp = New Connection
cnTemp.CursorLocation = adUseServer
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;Authentication=SqlPassword;User ID=sa;Password=secret;DataTypeCompatibility=80;"

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

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

Answer 1

Согласно документации MSOLEDB , пара ключевых слов для доверия сертификату сервера должна быть TrustServerCertificate = Да .Попробуйте:

cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;User ID=sa;Password=secret;TrustServerCertificate=Yes;DataTypeCompatibility=80;"

Answer 2

Сначала я хотел бы заявить, что вся заслуга принадлежит @Dan Guzman.Это его ответ / комментарий, который обеспечил решение.

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

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

https://docs.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-2017#table3_1

Он расположен в разделе SQL Server 2017 -> OLE DB -> Applications -> Using connection string keywords with OLE DB Driver for SQL server, поэтому он должен быть правильным.Он состоит из трех разделов;в контексте этого вопроса нас интересует последняя таблица, потому что только эта относится к строкам соединения с ADO.

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

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

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

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

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

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

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

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

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

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

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

https://docs.microsoft.com/en-us/sql/relational-databases/native-client/applications/using-connection-string-keywords-with-sql-server-native-client?view=sql-server-2017

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

Однако этот документ находится в SQL Server 2017 -> Development -> SQL Server Native Client -> Applications -> Using Connection String Keywords.Это означает, что это не относится к нашему случаю, поскольку относится к собственному клиенту сервера SQL (а не к OLE DB), но предоставляет правильную информацию.

Таким образом, у нас есть правильный документ, который предоставляет неверную информацию инеактуальный документ, который предоставляет правильную информацию.Поздравляем, Microsoft, вы снова заставили меня напрасно тратить целый день ...

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

https://docs.microsoft.com/en-us/sql/connect/oledb/features/using-azure-active-directory?view=sql-server-2017#encryption-and-certificate-validation

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

Проверка сертификата

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

Примечание

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

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