Виправити помилку шифрування SQL Server – рішення одним клацанням миші

Прочитайте помилку - це проблема довіри, а не проблема мережі

Ваша мережа в порядку, і сервер працює. З’єднання досягло SQL Server, сервер запропонував зашифрований канал для входу, але ваш комп’ютер відмовився, оскільки сертифікат, що підтверджує особу сервера, підписаний ніким, кому ваш комп’ютер довіряє. Повна помилка SSMS показує:

За замовчуванням SQL Server захищає вхід за допомогою самопідписаного сертифіката, який створює сам. Самопідписаний сертифікат дійсно шифрує трафік, але він не може підтвердити, що сервер дійсно є вашим сервером, тому клієнти, які вимагають перевіреного шифрування, відхиляють його. Кожне чесне виправлення — це одне з двох: змусити клієнта свідомо прийняти цей конкретний сервер (кроки 2 і 3) або надати серверу сертифікат, якому клієнти довіряють самостійно (крок 4).

Швидке виправлення клієнта в SSMS - Сертифікат довіреного сервера

Це швидкий маршрут, показаний на відео. Це нічого не змінює на сервері; він повідомляє цьому одному підключенню прийняти сертифікат сервера, не перевіряючи, хто його підписав. У вікні Підключення до сервера SSMS клацніть Параметри, щоб відкрити додаткові вкладки, перейдіть на вкладку Властивості з’єднання, встановіть для шифрування значення Обов’язкове (або залиште запропоноване), позначте Сертифікат довіреного сервера та натисніть Під’єднатися. Вхід відбувається одразу.

Те саме виправлення всередині рядка підключення програми

Якщо програма дає збій замість SSMS, той самий перемикач живе в її рядку підключення. Явно додайте два параметри: Encrypt=True вмикає захищений канал, а TrustServerCertificate=True — це написання рядка підключення прапорця SSMS:

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

Використовуйте власне ім’я сервера, базу даних і логін замість наведених у прикладі значень. Компроміс точно такий же, як і прапорець у кроці 2, з однією додатковою небезпекою: пропущена перевірка, вбудована в конфігурацію надісланої програми, застосовується до кожного користувача непомітно та постійно. Зберігайте його в конфігураціях розробки та постановки, а в робочому стані розглядайте його як позичений час, доки сертифікат сервера на кроці 4 не буде на місці.

Правильне виправлення - надайте серверу справжній сертифікат

Постійне відновлення відбувається один раз на сервері, а потім кожен клієнт підключається строго без прапорців і попереджень. Спочатку отримайте сертифікат для повного імені DNS сервера (наприклад, sql01.company.local) від вашого внутрішнього центру сертифікації або загальнодоступного центру сертифікації з використанням автентифікації сервера. Імпортуйте його разом із закритим ключем до сховища сертифікатів локального комп’ютера на машині SQL Server. Потім клацніть сертифікат правою кнопкою миші, виберіть Усі завдання → Керування особистими ключами та надайте обліковому запису служби SQL Server дозвіл Читання для закритого ключа. Відкрийте Диспетчер конфігурації SQL Server, розгорніть Конфігурація мережі SQL Server, клацніть правою кнопкою миші Протоколи для MSSQLSERVER, виберіть Властивості та виберіть сертифікат на вкладці Сертифікат. На вкладці Flags ви також можете встановити ForceEncryption на Yes, щоб кожен клієнт мав шифрувати. Перезапустіть службу SQL Server - зміна нічого не вплине, доки ви не зробите це.

Перевірте виправлення строгим способом

Успішний вхід доводить менше, ніж люди думають, оскільки деякі комбінації налаштувань підключаються без реального захисту. Доведіть обидві половини. По-перше, повторно підключіться від клієнта строгим способом: підключіться, використовуючи ім’я DNS сервера – ім’я всередині сертифіката – встановіть для шифрування значення Обов’язкове та залиште Сертифікат надійного сервера непозначеним. Вхід має бути успішним без попередження. Потім у тому самому сеансі запитайте сервер, чи дійсно з’єднання зашифровано, виконавши цей запит у SSMS:

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option, що показує TRUE, є прохідним балом. FALSE з робочим логіном означає, що з’єднання вдалось через скидання захисту, і завдання не виконано. Це проходження тесту є справжньою фінішною прямою: будь-який правильно налаштований клієнт, включаючи майбутні версії SSMS, тепер підключається з повною перевіркою та без спеціальних налаштувань.