Set-SqlColumnEncryption не может найти или получить ключ главного столбца из хранилища сертификатов ms при настройке функции Always-Encrypted
Я пытаюсь реализовать функцию Always-Encrypted в нескольких столбцах базы данных MS SQL Server 2016. На самом деле я успешно реализовал это в своей базе данных UAT. Тем не менее, при попытке сделать идентичные шаги в моей производственной БД, я получаю следующую ошибку:
Set-SqlColumnEncryption: не удалось расшифровать ключ шифрования столбца с помощью поставщика хранилища ключей: 'MSSQL_CERTIFICATE_STORE'. Последние 10 байтов зашифрованного ключа шифрования столбца: "xx-xx-xx-xx-xx-xx-xx-xx-xx-xx". Keyset не существует
Некоторые детали: я выполняю команду
Set-SqlColumnEncryption -ColumnEncryptionSettings $l_columnEncryptionSettings -InputObject $l_database
в рамках PowerShell. Главный ключ столбца IS в хранилище пользователей ms sql учетной записи, на которой запущен процесс. Его можно увидеть в certmgr в "Сертификаты - Текущий пользователь \ Персональный \ Сертификаты", и он содержит как открытый, так и закрытый ключ (отображение информации о сертификате показывает "у вас есть закрытый ключ, соответствующий этому сертификату").
Глядя на Always-Encrypted Keys записи в БД, Column Master Key показывает с ключом CurrentUser/my/<fingerprint>, где <fingerprint> действительно соответствует отпечатку сертификата в MSSQL_CERTIFICATE_STORE.
Я видел этот вопрос ( Always Encrypted Feature - Не удалось расшифровать столбец. Вызов из Windows-Service App), но "решение" там либо не применяется (я импортировал открытый и закрытый ключ в хранилище), либо неясно (это упоминает "доступ" к каталогу, но детали того, какой тип доступа не предоставляется, и учетная запись, с которой я имею дело, действительно имеет доступ на чтение к упомянутому каталогу.)
Самое странное, что я уже успешно реализовал его на той же машине для БД UAT (другая БД, тот же экземпляр SQL, другой пользователь), но я не вижу различий между этими двумя настройками.
Кто-нибудь знает, что может быть причиной этой ошибки или как ее исправить? Благодарю.
Изменить: Когда я задал этот вопрос, проблема, казалось, была из-за неправильной настройки функции, поэтому вопрос был разумным. При дальнейшем расследовании (см. Ниже) выяснилось, что происходит повреждение данных, поэтому никто, кроме меня, не мог ответить на это.
1 ответ
CertMgr показывал, что сертификат в локальном хранилище был импортирован с закрытым ключом: при открытии сертификата четко отображалось "У вас есть закрытый ключ, соответствующий этому сертификату", а сертификат был импортирован из файла.pfx, содержащего закрытый ключ., ОДНАКО, я скачал, скомпилировал и запустил инструмент "findprivatekey.exe" от Misrosoft. Я побежал
findprivatekey My currentUser -t "xx xx ... xx"
и как ни странно, он вернулся с
Ошибка FindPrivateKey по следующей причине: невозможно получить имя файла с закрытым ключом
Фактически, независимо от того, как я пытался указать сертификат (отпечаток пальца, CN и т. Д.), Он всегда возвращался с одним и тем же отказом. Я удалил сертификат и снова запустил свой скрипт импорта. Тот же сценарий, другой день. И тогда все заработало.
Я могу только заключить, что каталог, содержащий файл закрытого ключа, был каким-то образом поврежден.
Приложение:
Для других с подобной проблемой, подробности о причине коррупции и ее устранении: На следующий день данные частного сертификата снова исчезли. Технический специалист заметил, что путь к файлу для закрытого ключа (как показано командой findprivatekey сразу после переустановки сертификата) находится в поддереве профиля "Роуминг", хотя учетная запись настроена для локального профиля. Некоторые исследования выявили функцию Windows под названием "Credential Roaming". Внимательно изучив этот документ: https://social.technet.microsoft.com/wiki/contents/articles/11483.credential-roaming.aspx, в конце приведен раздел "Сертификаты становятся непригодными к использованию или обновляются", который в данном случае применяется. Выдача команды certutil -user -repairstore My "{Serialnumer}" исправил проблему.