Set-SqlColumnEncryption не может найти или получить ключ главного столбца из хранилища сертификатов ms при настройке функции Always-Encryption

Я пытаюсь реализовать функцию Always-Encrypted для нескольких столбцов базы данных MS SQL Server 2016. Фактически, я успешно реализовал его в своей базе данных UAT. Однако при попытке выполнить те же действия в моей производственной БД я получаю следующую ошибку:

Set-SqlColumnEncryption: не удалось расшифровать ключ шифрования столбца с помощью поставщика хранилища ключей: «MSSQL_CERTIFICATE_STORE». Последние 10 байтов ключа шифрования зашифрованного столбца: «xx-xx-xx-xx-xx-xx-xx-xx-xx-xx». Набор ключей не существует

Некоторые подробности: я выполняю команду

Set-SqlColumnEncryption -ColumnEncryptionSettings $l_columnEncryptionSettings -InputObject $l_database

внутри пауэршелл. Главный ключ столбца находится в пользовательском хранилище ms sql учетной записи, в которой запущен процесс. Его можно увидеть в certmgr в разделе «Сертификаты — Текущий пользователь\Личные\Сертификаты», и он содержит как открытый, так и закрытый ключ (отображение информации о сертификате показывает «у вас есть закрытый ключ, соответствующий этому сертификату»).

введите здесь описание изображения

Глядя на записи Always-Encrypted Keys в БД, Column Master Key отображается с ключевым путем CurrentUser/my/<fingerprint>, где <fingerprint> действительно соответствует отпечатку пальца сертификата в MSSQL_CERTIFICATE_STORE.

Я видел этот вопрос (Функция Always Encrypted - Не удалось расшифровать столбец. Вызов из приложения Windows-Service), но "решение" там либо не применяется (я импортировал открытый и закрытый ключ в хранилище), либо неясно (упоминается «доступ» к каталогу, но подробности о том, какой доступ не предоставляется, и учетная запись, с которой я имею дело, действительно имеют доступ для чтения к указанному каталогу.)

Что самое странное, так это то, что я уже успешно реализовал его на той же машине для БД UAT (разные БД, тот же экземпляр SQL, другой пользователь), но я не вижу различий между двумя настройками.

Кто-нибудь знает, что может быть причиной этой ошибки или как ее исправить? Спасибо.

Редактировать: Когда я задал этот вопрос, проблема оказалась в неправильной настройке функции, поэтому вопрос был разумным. При дальнейшем расследовании (см. ниже) выяснилось, что это повреждение данных, так что никто, кроме меня, не мог ответить на этот вопрос.


powershell windows-services always-encrypted sql-server-2016
person David I. McIntosh    schedule 12.02.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

CertMgr показывал, что сертификат в локальном хранилище был импортирован с закрытым ключом: при открытии сертификата четко показывалось «У вас есть закрытый ключ, соответствующий этому сертификату», а сертификат был импортирован из файла .pfx, содержащего закрытый ключ. . ОДНАКО, я загрузил, скомпилировал и запустил инструмент «findprivatekey.exe» от Misrosoft. я побежал

findprivatekey My currentUser -t "xx xx ... xx"

и как ни странно он вернулся с

Ошибка FindPrivateKey по следующей причине: Не удалось получить имя файла закрытого ключа.

Фактически, как бы я ни пытался указать сертификат (отпечаток пальца, CN и т. д.), он всегда возвращался с одним и тем же сбоем. Я удалил сертификат и повторно запустил сценарий импорта. Тот же сценарий, другой день. И тогда все заработало.

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

Приложение:

Для других с аналогичной проблемой, подробные сведения о причине повреждения и ее исправлении: На следующий день данные частного сертификата снова исчезли. Острый глаз технического специалиста заметил, что путь к файлу для закрытого ключа (как показано командой findprivatekey сразу после переустановки сертификата) находится в поддереве профиля «Роуминг», хотя учетная запись была настроена для локального профиля. Некоторое расследование выявило функцию Windows под названием «Роуминг учетных данных». Просмотрите этот документ: https://social.technet.microsoft.com/wiki/contents/articles/11483.credential-roaming.aspx, в конце находится раздел «Сертификаты становятся непригодными для использования или обновляются», который в данном случае применяется. Ввод команды certutil -user -repairstore My "{Serialnumer}" устранил проблему.

person David I. McIntosh    schedule 12.02.2018