Crypto rsa machinekeys ошибка открытия

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

Реми использует 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 вместо формата pgx CNG, проблема исчезнет, ​​и код C# не нужно менять.

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

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

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

KeyExchange

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

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

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

Решение: сбросьте разрешения для папки Machine key s

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

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

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

В моем случае следующий код работал локально (как 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»). Старый API.NET не совместим с ним, поэтому он не работает.

Вы можете использовать оболочку Security.Cryptography для этого API ( доступно на 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 (конечно, это более 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). Я обнаружил, что эта проблема может быть вызвана тем, что у вызывающего пользователя недостаточно прав.

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

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

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

Я пробовал все в этом посте, но для меня решение было:

1. Импортируйте исходный файл.p12 на мою локальную машину
2. Экспортируйте его как файл.pfx, отметив параметры «Экспортировать все расширенные свойства» и «Включить все сертификаты в путь сертификации, если это возможно».

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

   var certificate = new X509Certificate2(certKeyFilePath, passCode,
   X509KeyStorageFlags.Exportable | X509KeyStorageFlags.MachineKeySet |       
   X509KeyStorageFlags.PersistKeySet );
   

Что свойства PrivateKey и ОткрытыйКлючи устарел, начинающиеся с NET 4.6. Пожалуйста, используйте:

• сертификат.GetRSAPrivateKey() или GetECDsaPrivateKey()
• сертификат.GetRSAPublicKey() или GetECDsaPublicKey()

С уважением

У меня тоже была эта проблема и после попытки внесения предложений в этот пост безуспешно. Я смог решить свою проблему, перезагрузив сертификат с помощью утилиты сертификатов Digicert https://www.digicert.com/util/. Это позволяет выбрать провайдера для загрузки сертификата. В моем случае загрузка сертификата в провайдер криптографических провайдеров Microsoft RSA Schannel, где я ожидал, что он будет в первую очередь, решает проблему.

Я столкнулся с той же проблемой в нашем приложении 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.

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

user58107

11 ноя ’20 в 12:59
2020-11-11 12:59

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

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

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

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

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

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

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

Проблема в том, что ваш код не может прочитать файл 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"

если вы столкнулись с проблемой в третьей команде, перейдите сюда 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) и дополнительной опции импорта.

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

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

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

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

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

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

Обновление CSP до поставщика хранилища ключей программного обеспечения Microsoft на основе этих инструкций устранило проблемы.

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

У меня была очень странная проблема с импортированным PFX из OpenSSL в системе Linux и ADWS (веб-служба Active Directory).

При использовании графического пользовательского интерфейса импорта сертификата через оснастку MMC сертификат был успешно импортирован, и ADWS смогла его найти и загрузить.

При использовании этой команды с Powershell сертификат был успешно импортирован, но ADWS выдавал ошибку Event ID 1402.

Import-PfxCertificate -FilePath C:UsersAdministratorDesktopdc01.test.pfx `
   -CertStoreLocation 'Cert:LocalMachineMy' -Password (ConvertTo-SecureString 'Password123!' -AsPlainText -Force)

Веб-службам Active Directory не удалось обработать сертификат сервера. Для использования соединений SSL/TLS требуется сертификат. Чтобы использовать соединения SSL/TLS, убедитесь, что на машине установлен действительный сертификат проверки подлинности сервера от доверенного центра сертификации (ЦС).

Включение отладки было причиной:

ADWSHostFactory: [01.04.2023, 21:55:59] [6] ProvisionCertificate: поймано исключение CryptographicException: System.Security.Cryptography.CryptographicException: указан недопустимый тип поставщика.

   в System.Security.Cryptography.Utils.CreateProvHandle(параметры CspParameters, логическое значение randomKeyContainer)
   в System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, параметры CspParameters, логические значения randomKeyContainer, Int32 dwKeySize, SafeProvHandle и safeProvHandle, SafeKeyHandle и safeKeyHandle)
   в System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
   в System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32 dwKeySize, параметры CspParameters, логическое значение useDefaultKeySize)
   в System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey()
   в Microsoft.ActiveDirectory.WebServices.ADWSHostFactory.ProvisionCertificate(хост ServiceHost)

Я был в тупике и попробовал некоторые другие решения здесь, но ничего не сработало.

К счастью, я обнаружил это руководство в Component Space (https://www.componentspace.com/Forums/1578/SHA256-and-Converting-the-Cryptographic-Service-Provider-Type), в котором упоминается, что провайдер криптографии является проблемой, как и много других по этому вопросу.

Я не видел способа изменить это с помощью powershell, но вы можете сделать это с помощью certutil.

   certutil.exe -p 'Пароль123!' -csp "Microsoft Enhanced RSA and AES Cryptographic Provider" -importPFX C:UsersAdministratorDesktopdc01.test.pfx

Сертификат теперь работает так, как если бы я добавил его через графический интерфейс.

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