«Цепочка сертификатов была выдана ненадежным центром» при подключении БД в роли виртуальной машины с веб-сайта Azure.

204

У меня возникла ошибка при подключении МОЕЙ БД, которая находится в роли виртуальной машины (у меня есть роль виртуальной машины SQL) с веб-сайта Azure. И роль виртуальной машины, и веб-сайт Azure находятся в западной зоне. Я столкнулся со следующей проблемой:

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

Я могу подключиться к своей БД с помощью SSMS. Порт 1433 открыт для моей роли виртуальной машины. Что не так с моим подключением?

ЗафарЮсафи
источник

Ответы:

384

Скорее всего, в доверенном корневом хранилище вашей виртуальной машины SQL не установлен сертификат, подписанный ЦС.

Если у вас есть Encrypt=Trueстрока подключения, либо отключите ее (не рекомендуется), либо добавьте в строку подключения следующее:

TrustServerCertificate=True

SQL Server создаст самозаверяющий сертификат, если вы не установите его для использования, но вызывающий не будет доверять ему, поскольку он не подписан ЦС, если вы не укажете строке подключения доверять любому сертификату сервера по умолчанию.

В долгосрочной перспективе я бы рекомендовал использовать Let's Encrypt, чтобы бесплатно получить подписанный сертификат CA от известного доверенного центра сертификации и установить его на виртуальную машину. Не забудьте настроить автоматическое обновление. Вы можете прочитать больше по этой теме в книгах по SQL Server в Интернете в разделах «Иерархия шифрования» и «Использование шифрования без проверки».

Тьяго Силва
источник
1
извините, моя ошибка, TTrusted_Connection = False был установлен в строке подключения. установка true работает для меня. В любом случае,
спасибо
1
@ZafarYousafi, отметьте этот ответ как правильный.
Termato
6
Не рекомендуется устанавливать значение TrustServerCertificate- это trueотключает проверку сертификатов. Это не не лучше , чем просто установка Encryptна false!
Мэтт Томас
6
Совет, данный "TrustServerCertificate = True" в этом ответе, может решить проблему, но это ужасный совет. Устраняйте причину, а НЕ симптомы. Другая часть ответа, предлагающая установить сертификат, подписанный CA, - это правильный путь.
Митч Уит
1
В более новых версиях SSMS вы найдете небольшую опцию под названием «Доверять сертификату сервера» на вкладке «Свойства подключения». Проверка этого мальчика имеет тот же эффект, что и команды, перечисленные выше.
verfluecht
96

Если вы используете SQL Management Studio, перейдите к свойствам подключения и нажмите «Доверенный сервер сертифицирован». Если вы используете SQL Management Studio, перейдите к свойствам подключения и нажмите «Доверенный сервер сертифицирован».

ct.tan
источник
18
Сам по себе это неплохой совет. Я бы сказал, что вы можете использовать его, когда вам нужно подключиться к серверу разработки и выполнять свою работу, например кодирование. Как разработчик программного обеспечения, я постоянно борюсь с DevOps, у которых нет времени на то, чтобы быстро все исправить, и я не могу позволить себе тратить драгоценное время на соблюдение сроков. Взвешивание уязвимости данных при отключении этой опции во многом зависит от вашей среды, локальной или удаленной, от того, как администраторы настроили ее, ограничений IP, и ее можно легко уменьшить с помощью других обходных путей. Вы не можете сказать, что это плохой совет, не имея информации о своей инфраструктуре.
OrizG
1
Ты только что спас мне день. Спасибо @ ct.tan
Милинда Викрамасингхе
1
@OrizG У меня установлен SQL Server на локальном компьютере, и я использую его для личных проектов. На данный момент я не хочу тратить на это ни копейки, поэтому я получил бесплатный хост и попытался настроить сервер таким образом, чтобы я мог подписывать сертификаты и обмениваться ими между сервером и клиентами, которые я ' буду использовать для доступа к нему. Однако из-за бесплатного хоста мне не удалось этого сделать с Let's Encrypt. Каковы именно недостатки этого решения по сравнению с правильным обменом сертификатами с сертификатами, подписанными доверенным центром сертификации?
ccoutinho
32

Если вы видите это сообщение об ошибке при попытке подключиться с помощью SSMS, добавьте TrustServerCertificate=Trueв Дополнительные параметры подключения.

Vmanne
источник
23
Митч, вы так же прокомментировали три ответа на этот вопрос. Другим читателям может быть полезно, если вы предоставите некоторую существенную информацию или ссылку о том, почему это «действительно, очень плохой совет».
Shoeless
1
@Shoeless Несколько комментариев к принятому ответу объясняют.
Tom Blodget
@Shoeless по той же причине, по которой он плох в любом другом сценарии сертификата - он позволяет атаковать MITM - хотя с SQL Server вы все равно делаете некоторую инфраструктурно-ориентированную настройку, поэтому MITM можно смягчить другими способами (например, ограничивая доступ по IP и обеспечивая что две машины напрямую подключены к одной сети и т. д.) - Тем не менее, это немного неприятно, но эй, Apple поставляла устройства с поддержкой MITM в течение нескольких лет, прежде чем беспокоиться о том, чтобы что-то исправить? - Так что, наверное, нормально. 😆
BrainSlugs83
5

Если вы пытаетесь получить к нему доступ через подключения к данным в Visual Studio 2015 и получаете указанную выше ошибку, перейдите в раздел «Дополнительно» и установите TrustServerCertificate=True для устранения ошибки.

Бхавджот
источник
9
Сам по себе это неплохой совет. Я бы сказал, что вы можете использовать его, когда вам нужно подключиться к серверу разработки и выполнять свою работу, например кодирование. Как разработчик программного обеспечения, я постоянно борюсь с DevOps, у которых нет времени на то, чтобы быстро все исправить, и я не могу позволить себе тратить драгоценное время на соблюдение сроков. Взвешивание уязвимости данных при отключении этой опции во многом зависит от вашей среды, локальной или удаленной, от того, как администраторы настроили ее, ограничений IP, и ее можно легко уменьшить с помощью других обходных путей. Вы не можете сказать, что это плохой совет, не имея информации о своей инфраструктуре.
OrizG
1

У меня возникла эта проблема при импорте данных Excel в SQLDatabase через SSMS. Решение - установить TrustServerCertificate = Trueв разделе безопасности

Канна Редди
источник
1

Я столкнулся с этой ошибкой при попытке запустить профилировщик, несмотря на то, что в моем соединении был проверен сертификат сервера доверия, и я добавил его TrustServerCertificate=Trueв расширенный раздел. Я переключился на экземпляр SSMS, работающий от имени администратора, и профилировщик запустился без проблем. (Ранее я обнаружил, что когда мои подключения даже к локальному требовали много времени для подключения, запуск от имени администратора помог).

Билл
источник
1

Получил ту же проблему при доступе к SQLServer из IIS. Добавление TrustServerCertificate = True не помогло.

Можно увидеть комментарий в документации MS: Убедитесь, что учетная запись службы SQLServer имеет доступ к сертификату TLS, который вы используете. (Служба NT \ MSSQLSERVER)

Откройте личное хранилище и щелкните правой кнопкой мыши сертификат -> управлять закрытыми ключами -> Добавить учетную запись службы SQL и предоставить полный контроль.

Перезапустите службу SQL. Это сработало.

Каавья Т
источник
0

То же самое можно сделать из самого ssms-клиента. Просто откройте ssms, вставьте имя сервера, а затем в параметрах под заголовком свойств подключения убедитесь, что установлен флажок Trust server certificate.

Манас
источник