Произошла ошибка при попытке сохранить поставщика

Я пытаюсь прочитать закрытый ключ сертификата, который был предоставлен мне сторонним поставщиком услуг, поэтому я могу использовать его для шифрования некоторого XML перед отправкой ему по сети. Я делаю это программно на С#, но я думаю, что это проблема с разрешениями или неправильной настройкой, поэтому я сосредоточусь на фактах, которые кажутся наиболее важными:

• Я не думаю, что эта проблема связана с кодом; мой код работает на других компьютерах, и проблема касается образца кода от Microsoft.
• Сертификат был предоставлен в виде файла PFX и предназначен только для целей тестирования, поэтому он также включает фиктивный центр сертификации.
• Используя MMC.exe, я могу импортировать сертификат в личное хранилище для локального компьютера, прежде чем предоставлять разрешения на закрытый ключ всем соответствующим учетным записям и перетаскивать центр сертификации в доверенные корневые центры сертификации.
• Используя C#, я могу загрузить сертификат (идентифицированный по его отпечатку) и убедиться, что у него есть закрытый ключ, используя X509Certificate2.HasPrivateKey. Однако попытка прочитать ключ вызывает ошибку. В .NET выдается CryptographicException с сообщением «Указан неверный тип поставщика» при попытке доступа к свойству X509Certificate2.PrivateKey. В Win32 вызов метода CryptAcquireCertificatePrivateKey возвращает эквивалентный результат HRESULT, NTE_BAD_PROV_TYPE.
• Это то же самое исключение, которое также возникает при использовании двух собственных примеров кода Microsoft для чтения закрытого ключа сертификата.
• Установка того же сертификата в эквивалентном хранилище для текущего пользователя вместо локального компьютера позволяет успешно загрузить закрытый ключ.
• У меня Windows 8.1 с правами локального администратора, и я пробовал запускать свой код как в обычном, так и в повышенном режимах. Коллеги на Windows 7 и Windows 8 смогли загрузить ключ из хранилища локального компьютера для того же сертификата.
• Я могу успешно прочитать закрытый ключ самозаверяющего тестового сертификата IIS, который находится в том же месте хранилища.
• Я уже ориентируюсь на .NET 4.5 (об этой ошибке сообщалось в некоторых более старых версиях платформы).
• Я не думаю, что это проблема с шаблонами сертификатов, потому что я ожидаю, что это одинаково повлияет как на локальный компьютер, так и на хранилища текущего пользователя?

В отличие от моих коллег, я предпринял несколько предыдущих попыток удалить и переустановить сертификат различными способами, в том числе с помощью диспетчера IIS, а также с использованием более старого сертификата того же эмитента. Я не вижу следов старых или повторяющихся сертификатов в MMC. Однако у меня есть много файлов закрытых ключей одинакового размера, которые, судя по времени последней записи, должны были быть оставлены после моих различных попыток установки. Они находятся в следующих местах для локального компьютера и текущих пользовательских хранилищ соответственно:

C:ProgramDataMicrosoftCryptoRSAMachineKeys

C:UsersAppDataRoamingMicrosoftCryptoRSAS-1-5-21-[остальный идентификатор пользователя]

Итак, может ли кто-нибудь посоветовать:

• Это хорошая идея удалить сертификат с помощью MMC, удалить все те файлы, которые выглядят как потерянные закрытые ключи, а затем переустановить сертификат и повторить попытку?
• Есть ли другие файлы, которые я должен попытаться удалить вручную?
• Есть что-нибудь еще, что я должен попробовать?

ОБНОВЛЕНИЕ. Добавлен пример кода, показывающий попытку чтения закрытого ключа:

static void Main()
{
    // Exception occurs when trying to read the private key after loading certificate from here:
    X509Store store = new X509Store("MY", StoreLocation.LocalMachine);
    // Exception does not occur if certificate was installed to, and loaded from, here:
    //X509Store store = new X509Store("MY", StoreLocation.CurrentUser);

    store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);

    X509Certificate2Collection collection = (X509Certificate2Collection)store.Certificates;
    X509Certificate2Collection fcollection = (X509Certificate2Collection)collection.Find(X509FindType.FindByTimeValid, DateTime.Now, false);
    X509Certificate2Collection scollection = X509Certificate2UI.SelectFromCollection(fcollection, "Test Certificate Select", "Select a certificate from the following list to get information on that certificate", X509SelectionFlag.MultiSelection);
    Console.WriteLine("Number of certificates: {0}{1}", scollection.Count, Environment.NewLine);

    foreach (X509Certificate2 x509 in scollection)
    {
        try
        {
            Console.WriteLine("Private Key: {0}", x509.HasPrivateKey ? x509.PrivateKey.ToXmlString(false) : "[N/A]");
            x509.Reset();
        }
        catch (CryptographicException ex)
        {
            Console.WriteLine(ex.Message);
        }
    }
    store.Close();

    Console.ReadLine();
}

У меня была такая же проблема в Windows 8 и Server 2012/2012 R2 с двумя новыми сертификатами, которые я недавно получил. В Windows 10 проблема больше не возникает (но мне это не помогает, так как код, управляющий сертификатом, используется на сервере). Хотя решение Джо Строммена в принципе работает, другая модель закрытого ключа потребует значительных изменений в коде, использующем сертификаты. Я считаю, что лучшим решением является преобразование закрытого ключа из CNG в RSA, как объяснил Реми Блок здесь.

Remy использует OpenSSL и два старых инструмента для преобразования закрытого ключа, мы хотели автоматизировать его и разработали решение только для OpenSSL. Учитывая MYCERT.pfx с паролем закрытого ключа MYPWD в формате CNG, выполните следующие действия для получения нового CONVERTED.pfx с закрытым ключом в формате RSA и тем же паролем:

1. Извлечь открытые ключи, полную цепочку сертификатов:

OpenSSL pkcs12 -in "MYCERT.pfx" -nokeys -out "MYCERT.cer" -passin "pass:MYPWD"

1. Извлечь закрытый ключ:

OpenSSL pkcs12 -in "MYCERT.pfx" -nocerts -out "MYCERT.pem" -passin "pass:MYPWD" -passout "pass:MYPWD"

1. Преобразование закрытого ключа в формат RSA:

OpenSSL rsa -inform PEM -in "MYCERT.pem" -out "MYCERT.rsa" -passin "pass:MYPWD" -passout "pass:MYPWD"

1. Объедините открытые ключи с закрытым ключом RSA в новый PFX:

OpenSSL pkcs12 -export -in "MYCERT.cer" -inkey "MYCERT.rsa" -out "CONVERTED.pfx" -passin "pass:MYPWD" -passout "pass:MYPWD"

Если вы загрузите преобразованный pfx или импортируете его в хранилище сертификатов Windows вместо pfx формата CNG, проблема исчезнет, ​​и код C# не нужно будет изменять.

Еще одна проблема, с которой я столкнулся при автоматизации: мы используем длинные сгенерированные пароли для закрытого ключа, и пароль может содержать ". Для командной строки OpenSSL символы " внутри пароля должны быть экранированы как "".

В моем случае я пытался использовать самозаверяющий сертификат с командой PowerShell New-SelfSignedCertificate. По умолчанию он будет генерировать сертификат с использованием API CNG (Crypto-Next Generation) вместо старого/классического криптографического CAPI. Некоторые старые фрагменты кода будут иметь проблемы с этим; в моем случае это была более старая версия провайдера IdentityServer STS.

Добавив это в конец моей команды New-SelfSignedCertificate, я решил проблему:

-KeySpec Обмен ключами

Ссылка на переключатель для команды powershell:

https://docs.microsoft.com/en-us/powershell/module/pkiclient/new-selfsignedcertificate?view=win10-ps

Вот еще одна причина, по которой это может произойти, это была странная проблема, и после дня борьбы я решил проблему. В качестве эксперимента я изменил разрешение для папки «C:ProgramDataMicrosoftCryptoRSAMachineKeys», в которой хранятся данные закрытого ключа для сертификатов, использующих хранилище машинных ключей. Когда вы меняете разрешение для этой папки, все закрытые ключи отображаются как «поставщик Microsoft Software KSP», который не является поставщиком (в моем случае они должны быть «поставщиком криптографии Microsoft RSA Schannel»).

Решение. Сбросьте права доступа к папке Machinekeys.

Исходное разрешение для этой папки можно найти здесь. В моем случае я изменил разрешение на «Все», дал разрешения на чтение, где он снял галочку «Особые разрешения». Поэтому я проверил с одним из членов моей команды (щелкните правой кнопкой мыши папку> Свойства> Безопасность> Дополнительно> выберите «Все»> Изменить> Нажмите «Дополнительные настройки» в списке флажков разрешений.

Надеюсь, это спасет чей-то день!

Здесь я нашел ответ источник, ему принадлежит заслуга документирование этого.

В моем случае следующий код отлично работал на локальном хосте (как NET 3.5, так и NET 4.7):

 var certificate = new X509Certificate2(certificateBytes, password);

 string xml = "....";
 XmlDocument xmlDocument = new XmlDocument();
 xmlDocument.PreserveWhitespace = true;
 xmlDocument.LoadXml(xml);

 SignedXml signedXml = new SignedXml(xmlDocument);
 signedXml.SigningKey = certificate.PrivateKey;

 //etc...

Но произошел сбой при развертывании в веб-приложении Azure в certificate.PrivateKey.

Это сработало, изменив код следующим образом:

 var certificate = new X509Certificate2(certificateBytes, password, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);
                                                                   //^ Here
 string xml = "....";
 XmlDocument xmlDocument = new XmlDocument();
 xmlDocument.PreserveWhitespace = true;
 xmlDocument.LoadXml(xml);

 SignedXml signedXml = new SignedXml(xmlDocument);
 signedXml.SigningKey = certificate.GetRSAPrivateKey();
                                      // ^ Here too

 //etc...

Целый день работы, потерянный благодаря Microsoft Azure, еще раз в моей жизни.

Ссылка на Блог Алехандро является ключевым.

Я считаю, что это связано с тем, что сертификат хранится на вашем компьютере с API CNG («Crypto Next-Generation»). Старый .NET API несовместим с ним, поэтому он не работает.

Для этого API можно использовать оболочку Security.Cryptography (доступно на Codeplex). Это добавляет методы расширения к X509Certificate/X509Certificate2, поэтому ваш код будет выглядеть примерно так:

using Security.Cryptography.X509Certificates; // Get extension methods

X509Certificate cert; // Populate from somewhere else...
if (cert.HasCngKey())
{
    var privateKey = cert.GetCngPrivateKey();
}
else
{
    var privateKey = cert.PrivateKey;
}

К сожалению, объектная модель закрытых ключей CNG немного отличается. Я не уверен, что вы можете экспортировать их в XML, как в исходном примере кода… в моем случае мне просто нужно было подписать некоторые данные закрытым ключом.

Как указывалось во многих других ответах, эта проблема возникает, когда закрытый ключ представляет собой ключ Windows Cryptography: Next Generation (CNG) вместо «классического» ключа Windows Cryptographic API (CAPI).

Начиная с .NET Framework 4.6 доступ к закрытому ключу (при условии, что это ключ RSA) можно получить с помощью метода расширения на X509Certificate2: cert.GetRSAPrivateKey().

Когда закрытый ключ хранится в CNG, метод расширения GetRSAPrivateKey вернет объект RSACng (новое для платформы в версии 4.6). Поскольку CNG имеет сквозной доступ для чтения старых программных ключей CAPI, GetRSAPrivateKey обычно возвращает RSACng даже для ключа CAPI; но если CNG не может его загрузить (например, это ключ HSM без драйвера CNG), тогда GetRSAPrivateKey вернет RSACryptoServiceProvider.

Обратите внимание, что тип возвращаемого значения для GetRSAPrivateKey — RSA. Начиная с .NET Framework v4.6 вам не нужно выполнять приведение за пределы RSA для стандартных операций; единственная причина использовать RSACng или RSACryptoServiceProvider — это когда вам нужно взаимодействовать с программами или библиотеками, которые используют NCRYPT_KEY_HANDLE или идентификатор ключа (или открывая постоянный ключ по имени). (В .NET Framework v4.6 было много мест, где входной объект по-прежнему приводился к RSACryptoServiceProvider, но все они были устранены в версии 4.6.2 (конечно, на тот момент это было более двух лет назад)).

Поддержка сертификатов ECDSA была добавлена ​​в 4.6.1 с помощью метода расширения GetECDsaPrivateKey, а DSA был обновлен в 4.6.2 с помощью GetDSAPrivateKey.

В .NET Core возвращаемое значение из Get[Algorithm]PrivateKey меняется в зависимости от ОС. Для RSA это RSACng/RSACryptoServiceProvider в Windows, RSAOpenSsl в Linux (или любой UNIX-подобной ОС, кроме macOS) и закрытый тип в macOS (это означает, что вы не можете это за RSA).

Используя Visual Studio 2019 и IISExpress, я смог исправить эту проблему, удалив следующий флаг при загрузке файла .pfx|.p12:

X509KeyStorageFlags.MachineKeySet

Перед:

X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable

После:

X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable

Обычно я загружаю сертификат следующим образом:

var myCert = new X509Certificate2("mykey.pfx", "mypassword", X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

Это НЕ вызывает исключение, вместо этого исключение возникает при попытке использовать сертификат (или, в моем случае, при попытке получить .PrivateKey). Я обнаружил, что эта проблема может быть вызвана тем, что у вызывающего пользователя недостаточно прав.

Поскольку я полагаюсь на флаг MachineKeySet для некоторых сред, мое текущее решение состоит в том, чтобы проглотить исключение, изменить флаги и повторить попытку. :/

Более органичным решением было бы проверить уровень разрешений и установить этот флаг динамически, однако я не знаю простого способа сделать это, отсюда и запасной вариант.

ПРИМЕЧАНИЕ. Файл .pfx, который я использую, был создан с веб-сайта, использующего библиотеку JavaScript (digitalbazaar/forge), которая НЕ использует поставщики хранилища ключей CNG (Cryptography Next Generation). . вот много распространенных причин для этой же ошибки (наиболее распространенные исправления, связанные с расширениями CNG, которые, к сожалению, даже изменили пространства имен в версиях .NET), которые вызывают ту же ошибку. Microsoft в конечном итоге должна быть более подробной при выдаче ошибок такого типа.

Что сработало для меня: IIS/Пул приложений/Загрузить профиль пользователя = true

Версия Powershell ответа от @berend-engelbrecht, при условии, что openssl установлен через chocolatey

function Fix-Certificates($certPasswordPlain)
{
    $certs = Get-ChildItem -path "*.pfx" -Exclude "*.converted.pfx"
    $certs | ForEach-Object{
        $certFile = $_

        $shortName = [io.path]::GetFileNameWithoutExtension($certFile.Name)
        Write-Host "Importing $shortName"
        $finalPfx = "$shortName.converted.pfx"


        Set-Alias openssl "C:Program FilesOpenSSLbinopenssl.exe"

        # Extract public key
        OpenSSL pkcs12 -in $certFile.Fullname -nokeys -out "$shortName.cer" -passin "pass:$certPasswordPlain"

        # Extract private key
        OpenSSL pkcs12 -in $certFile.Fullname -nocerts -out "$shortName.pem" -passin "pass:$certPasswordPlain" -passout "pass:$certPasswordPlain"

        # Convert private key to RSA format
        OpenSSL rsa -inform PEM -in "$shortName.pem" -out "$shortName.rsa" -passin "pass:$certPasswordPlain" -passout "pass:$certPasswordPlain" 2>$null

        # Merge public keys with RSA private key to new PFX
        OpenSSL pkcs12 -export -in "$shortName.cer" -inkey "$shortName.rsa" -out $finalPfx -passin "pass:$certPasswordPlain" -passout "pass:$certPasswordPlain"

        # Clean up
        Remove-Item "$shortName.pem"
        Remove-Item "$shortName.cer"
        Remove-Item "$shortName.rsa"

        Write-Host "$finalPfx created"
    }
}

# Execute in cert folder
Fix-Certificates password

Я столкнулся с той же проблемой в нашем приложении IIS:

 System.Security.Cryptography.Pkcs.PkcsUtils.CreateSignerEncodeInfo(CmsSigner signer, Boolean silent)
    System.Security.Cryptography.Pkcs.SignedCms.Sign(CmsSigner signer, Boolean silent)
    System.Security.Cryptography.Pkcs.SignedCms.ComputeSignature(CmsSigner signer, Boolean silent)

Регенерация сертификатов, как упоминалось здесь, не помогла. Я также заметил, что тестовое консольное приложение отлично работает под пользователем пула.

Проблема исчезла после очистки параметра «Включить 32-разрядные приложения» для пула приложений IIS.

Для службы .net 4.8 WCF я получал эту ошибку, потому что я (также) не установил версию httpRuntime.

Без набора httpRuntime я получал ошибку всякий раз, когда присутствовала защищенная привязка .net tcp.

<system.web>
    <compilation targetFramework="4.8" />
    <httpRuntime targetFramework="4.8" />
    <!--<customErrors mode="Off" />-->
</system.web>

Я уже настроил необходимые разрешения в mmc.exe -> добавить оснастку -> сертификаты -> личные -> все задачи -> управлять закрытыми ключами -> добавить [имя компьютера]IIS_IUSRS (все мои пулы приложений — это ApplicationPoolIdentity [по умолчанию ] — что покрывается IIS_IUSRS)

Свойства PrivateKey и PublicKey устарели, начиная с NET 4.6. Пожалуйста, используйте:

• cert.GetRSAPrivateKey() или GetECDsaPrivateKey()
• cert.GetRSAPublicKey() или GetECDsaPublicKey()

Отношении

После принятого ответа (с указанием KeySpec) исключение изменилось на System.Security.Cryptography.CryptographicException: Invalid provider type specified.. Я разрешил это исключение, предоставив моему веб-приложению доступ к закрытому ключу (IIS_IUSRS). Я обнаружил, что это также решит проблему с моим исходным сертификатом. Поэтому перед созданием и развертыванием новых сертификатов также проверьте разрешения закрытого ключа.

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

Получите сертификат и извлеките файл pfx из сертификата.

Используйте пароль 123456 ниже, чтобы иметь быстрое решение.

Переименуйте свой файл pfx в «my.pfx», чтобы упростить его, и поместите его в «C: Certi», убедитесь, что в вашей системе уже установлен открытый SSL. откройте cmd в системе Windows и введите —> OpenSSL Сохраняйте спокойствие и просто запускайте их по одному —> скопируйте и вставьте. *Примечание

—passin — ваш пароль к файлу Pfx. —passout — новый пароль для преобразованного файла pfx.

1. pkcs12 -in "C:Certimy.pfx" -nokeys -out "C:CertiMYCERT.cer" -passin "pass:123456"

2. pkcs12 -in "C:Certimy.pfx" -nocerts –out “C:CertiMYCERT.pem" -passin "pass:123456" -passout "pass:123456"

3. rsa -inform PEM -in "C:CertiMYCERT.pem" -out "C:CertiMYCERT.rsa" -passin "pass:123456" -passout "pass:123456"

Если вы столкнулись с проблемой в 3-й команде, перейдите сюда https://decoder.link/converter
Нажмите PKC # 12 на PEM загрузите файл pfx и конвертируйте его онлайн. скачать zip-файл. он содержит 3 файла. просто скопируйте файл «.key», переименуйте его в my.key и поместите в «C:Certi»

4. rsa -in C:Certimy.key -out C:Certidomain-rsa.key

5. pkcs12 -export -in "C:CertiMYCERT.cer" -inkey "C:Certidomain-rsa.key" -out "C:CertiCONVERTED.pfx" -passin "pass:123456" -passout "pass:123456"


**Also, you can try below things if the issue still persists**

• При наличии доступа к пулу приложений или пользователю IIS к папке «обязательно делать»

Путь — > C:ProgramDataMicrosoftCryptoRSAMachineKeys

• Удалить старые ключи (убрать беспорядок)
  Путь — > C:ProgramDataMicrosoftCryptoRSAMachineKeys

Эта ошибка исчезла после того, как я удалил сертификат из хранилища и снова импортировал его из файла .pfx с помощью мастера импорта сертификатов (дважды щелкните файл .pfx) и дополнительной опции импорта.

После проверки опции импорта (тот же шаг, когда вводится пароль):

«Отметьте этот ключ как экспортируемый. Это позволит вам создать резервную копию или перенести ваши ключи позже».

Доступ к приватному ключу теперь можно получить из кода без каких-либо ошибок.

Я также явно выбираю «Личный» магазин на предпоследнем шаге, но я не думаю, что это имеет значение.

Кажется, в Windows 10, если я запущу свою программу без прав администратора (независимо от того, использую ли я свойство PrivateKey или метод расширения GetRSAPrivateKey()), я увижу это исключение (исключение см. в заголовке этой ветки обсуждения). Если я запущу свою программу с правами администратора и использую свойство PrivateKey, я также увижу это исключение. Только если я запущу свою программу с правами администратора и использую метод расширения GetRSAPrivateKey(), я не увижу это исключение.

У меня также была эта проблема, я изменил «.jks» на «.pfx», не вводя пароль, как только я снова изменил тип хранилища ключей с паролем, он успешно работал.

Содержание

1. Как исправить ошибку 5 «Отказано в доступе» в Windows 10?
2. Установка разрешений на папку Temp
3. Добавление текущему пользователю прав администратора
4. Активация встроенной учетной записи администратора
5. Настройка контроля UAC
6. Как исправить ошибку «Отказано в доступе» на Windows?
7. 1. Вы администратор?
8. 2. Исправьте ошибки доступа, отказавшись от прав собственности
9. 3. Просмотр разрешений для папок
10. 4. Дважды проверьте настройки антивируса
11. 5. Проверьте шифрование файлов
12. Исправление ошибки «Отказано в доступе» при работе со службами в Windows 10
13. Исправляем ошибку «Отказано в доступе» при работе со службами в Windows 10
14. Способ 1: Настройка прав доступа системного раздела
15. Способ 2: Редактирование группы Администраторы
16. Способ 3: Проверка определенной службы
17. Способ 4: Включение привилегий для LOCAL SERVER
18. Способ 5: Проверка системы на вирусы

Версия MODX: Revolution

Здравствуйте!
Установил MODX Revolution локально.
Все встало нормально. Когда зашел на сайт, вместо белой страницки увидел ошибку 404. Оказалось при установке не было создано документа Home

Попытался создать дочерний документ, получил ошибку

Как исправить ситуацию. Попробовал переустановить MODX это не помогло, проблема осталась. В чем может быть дело?

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account