Криптопро tls ошибка 0x80090014 при обращении к csp указан неправильный тип поставщика

Настроим вашу электронную подпись под ключ за 30 минут!

Оставьте заявку и получите консультацию.

Мы готовы помочь!

Задайте свой вопрос специалисту в конце статьи. Отвечаем быстро и по существу. К комментариям

Выпустим и настроим электронную подпись для сотрудника прямо в день обращения!

Оставьте заявку и получите консультацию.

Подберем USB-носитель для ЭП. Доставка — в любую точку России!

Оставьте заявку и получите консультацию в течение 5 минут.

Наш каталог продукции

У нас Вы найдете широкий ассортимент товаров в сегментах
кассового, торгового, весового, банковского и офисного оборудования.

Посмотреть весь каталог

Я пытаюсь прочитать закрытый ключ сертификата, который был предоставлен мне сторонним поставщиком услуг, поэтому я могу использовать его для шифрования некоторого 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», не вводя пароль, как только я снова изменил тип хранилища ключей с паролем, он успешно работал.

using (X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine))
                {
                    store.Open(OpenFlags.ReadOnly);
                    var certCollection = store.Certificates;
                    var currentCerts = certCollection.Find(X509FindType.FindBySubjectDistinguishedName, CNName, true);

20/10/2018 11:56:38 AM - APWLLWS130 - Error - Failed to get the Certificate's private key. Thumbprint:*.xxx.com, O
=XXX, L=XXX, S=XXX, C=CA. Error: FABRIC_E_CERTIFICATE_NOT_FOUND
20/10/2018 11:56:38 AM - APWLLWS130 - Error - Failed to get private key file. x509FindValue: *.XX.com, O=XX, L=XX, S=XX, C=XX, x509StoreName: My, findType: FindBySubjectName, Error FABRIC_E_CERTIFICATE_NOT_FOUND

================ Certificate 6 ================
X509 Certificate:
Version: 3
Serial Number: XXXX
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Issuer:
    CN=Entrust Certification Authority - L1K
    OU=(c) 2012 Entrust, Inc. - for authorized use only
    OU=See www.entrust.net/legal-terms
    O=Entrust, Inc.
    C=US
  Name Hash(sha1): cc6d221cf6b4552c2f87915f5afef0e1eece83cc
  Name Hash(md5): d28ad6c84bf87658d9937c2df7b35db9

 NotBefore: 5/04/2016 6:21 AM
 NotAfter: 5/04/2019 6:51 AM

Subject:
    CN=*.XXX.com
    O=XXX Limited
    L=XXX
    S=British Columbia
    C=CA
  Name Hash(sha1): dbdd4f61a6bb62aeee8d7797b74be619e5c325bc
  Name Hash(md5): 6e18fd16dc14bdecfc3fbd1c76bfde9e

Public Key Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA
    Algorithm Parameters:
    05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
    0000  30 82 01 0a 02 82 01 01  00 cf 0c d5 f1 26 0d d2
    0010  d5 9f eb e7 15 3c 68 14  ac 12 60 e4 f6 11 95 1d
    0020  1d 6f 0e ab 29 7f 7c 47  f9 b5 21 12 88 a0 b8 13
    0030  d1 97 fe d7 d9 92 55 ed  2f 4b 9a ab 22 b2 01 16
    0040  60 1c c1 c8 de 2b 2b 06  d6 14 cc 97 29 72 9a da
    0050  9a f7 8f b6 c8 53 da 50  b0 4e bc 6e cd 52 ea 2b
    0060  ce cd 61 19 e5 3a 8d 4f  f9 5e 85 3e 6c 6a 09 2e
    0070  f7 ea 72 35 3c 55 0a 73  08 a7 e9 61 68 3f 33 5b
    0080  38 e8 8a 84 0a a9 0c 6e  43 24 91 05 6f 0d 7b 9e
    0090  47 c1 98 86 b8 28 c2 f3  90 45 25 03 d5 b2 6f 29
    00a0  a2 0c 9a 9e 54 e5 8b ca  61 47 67 15 ab 0f 24 68
    00b0  25 71 b2 4e b3 4e b9 63  3e 45 6a 93 e8 60 bb f3
    00c0  5e e0 c2 11 53 7b 5c 66  1a 40 e3 ba 54 32 13 f1
    00d0  cf 6e dc 53 fe c9 fb 05  e1 5a c8 77 01 c5 b2 af
    00e0  7b 79 fc 6b e3 0c c8 17  fd 29 df 6b 5c 0a a2 f3
    00f0  6b 83 f0 68 5b da 12 87  0f 59 39 2a d1 23 39 99
    0100  57 37 33 a5 0b a8 b5 9c  cb 02 03 01 00 01
Certificate Extensions: 9
    2.5.29.15: Flags = 0, Length = 4
    Key Usage
        Digital Signature, Key Encipherment (a0)

    2.5.29.37: Flags = 0, Length = 16
    Enhanced Key Usage
        Server Authentication (1.3.6.1.5.5.7.3.1)
        Client Authentication (1.3.6.1.5.5.7.3.2)

    2.5.29.31: Flags = 0, Length = 2c
    CRL Distribution Points
        [1]CRL Distribution Point
             Distribution Point Name:
                  Full Name:
                       URL=http://crl.entrust.net/level1k.crl

    2.5.29.32: Flags = 0, Length = 44
    Certificate Policies
        [1]Certificate Policy:
             Policy Identifier=2.16.840.1.114028.10.1.5
             [1,1]Policy Qualifier Info:
                  Policy Qualifier Id=CPS
                  Qualifier:
                       http://www.entrust.net/rpa
        [2]Certificate Policy:
             Policy Identifier=2.23.140.1.2.2

    1.3.6.1.5.5.7.1.1: Flags = 0, Length = 5c
    Authority Information Access
        [1]Authority Info Access
             Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
             Alternative Name:
                  URL=http://ocsp.entrust.net
        [2]Authority Info Access
             Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
             Alternative Name:
                  URL=http://aia.entrust.net/l1k-chain256.cer

    2.5.29.17: Flags = 0, Length = 22
    Subject Alternative Name
        DNS Name=*.XXXX
        DNS Name=XXXX

    2.5.29.35: Flags = 0, Length = 18
    Authority Key Identifier
        KeyID=82 a2 70 74 dd bc 53 3f cf 7b d4 f7 cd 7f a7 60 c6 0a 4c bf

    2.5.29.14: Flags = 0, Length = 16
    Subject Key Identifier
        f9 c8 19 ed c4 e0 9f 4f 1f 55 a3 9e 75 a3 8e ab 16 78 41 66

    2.5.29.19: Flags = 0, Length = 2
    Basic Constraints
        Subject Type=End Entity
        Path Length Constraint=None

Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Signature: UnusedBits=0
    0000  a0 c1 64 2f c5 49 3e 3c  f2 ea a2 b5 d6 7e d5 61
    0010  29 ba 07 bd 9b b7 b8 1f  4c ef 8a f7 65 ce 8e 03
    0020  8c 15 f0 d1 4c 69 3a 2e  9a b5 07 89 be dc 77 c3
    0030  77 91 db 25 83 11 1d 8a  40 a5 12 64 f4 7c a3 bd
    0040  0d eb ac 0c 13 3e 0c 2e  09 cf 73 72 f4 8d 02 3b
    0050  37 0b a3 c2 01 04 9b f0  1f fb 87 36 90 0f 66 10
    0060  8e e3 8a e2 86 a0 4c 65  3f 36 fb 15 a2 ac 57 fd
    0070  c5 94 5b 2d f3 cd 63 30  8e 60 98 ae df 91 0e d9
    0080  bd 60 33 4f 75 d6 92 62  f3 19 1f 93 6b bd e6 8f
    0090  83 34 88 c8 48 87 44 70  e8 96 23 d1 c6 63 82 c5
    00a0  2b e9 77 44 5f 4b d6 8c  a2 da be b3 56 02 70 eb
    00b0  23 b9 c6 46 b1 29 32 48  d8 46 c3 ed 35 1f cd 65
    00c0  57 02 8c 03 b9 61 c6 20  ce 06 f9 6d d1 8b 2a 79
    00d0  f7 8d 87 d6 a7 0d fe 69  85 b0 af d6 4e b8 2b 22
    00e0  7a ea 50 88 2b 25 d7 b1  d0 23 16 e9 9a 2d a3 6b
    00f0  7b aa 95 3a 3c 44 dd c8  15 41 94 dd 81 c5 de b0
Non-root Certificate
Key Id Hash(rfc-sha1): f9c819edc4e09f4f1f55a39e75a38eab16784166
Key Id Hash(sha1): daac6db6c7bc544e39c991a629a2280619fd6e6d
Key Id Hash(md5): 64c265f978b95775601823308ec52b63
Key Id Hash(sha256): 25107e721d662078a6680ca105162294c9e3755af53a13a6a248d49ad9d29043
Cert Hash(md5): c3b91d6fd29a96692ae3f0920a31f8ca
Cert Hash(sha1): 15cf70a8ffa6049e17915afd55ff7bc25eb19eb2
Cert Hash(sha256): 50bdd8af8d096446918837f877a8c9f8e8fdeb7e4bd545323490a987954b267a
Signature Hash: 7c9ec9cf0c20b31530805d5bc34efad1a11d390d652ed0040cedc0e1dc9f2080

  CERT_SUBJECT_PUBLIC_KEY_MD5_HASH_PROP_ID(25):
    64c265f978b95775601823308ec52b63

  CERT_MD5_HASH_PROP_ID(4):
    c3b91d6fd29a96692ae3f0920a31f8ca

  CERT_SHA1_HASH_PROP_ID(3):
    15cf70a8ffa6049e17915afd55ff7bc25eb19eb2

  CERT_FRIENDLY_NAME_PROP_ID(11):
    wildcard.XXX.com_2016

  CERT_KEY_PROV_INFO_PROP_ID(2):
    Key Container = {B9ED4E08-E960-484A-8461-A8197761782C}
  Unique container name: 0e4122029ed9cd31a8781f880191ea36_2ab40618-dac2-4d86-9224-489cfd1e8af0
    Provider = Microsoft RSA SChannel Cryptographic Provider
    ProviderType = c
  Flags = 20 (32)
    CRYPT_MACHINE_KEYSET -- 20 (32)
    KeySpec = 1 -- AT_KEYEXCHANGE

  CERT_KEY_IDENTIFIER_PROP_ID(20):
    f9c819edc4e09f4f1f55a39e75a38eab16784166

  CERT_SIGNATURE_HASH_PROP_ID(15) disallowedHash:
 7c9ec9cf0c20b31530805d5bc34efad1a11d390d652ed0040cedc0e1dc9f2080

  CERT_SUBJECT_PUB_KEY_BIT_LENGTH_PROP_ID(92):
    0x00000800 (2048)

  CERT_ISSUER_PUBLIC_KEY_MD5_HASH_PROP_ID(24):
    930ed2707d249c195a1bf719ff95c4c2

  CERT_ACCESS_STATE_PROP_ID(14):
  AccessState = 6
    CERT_ACCESS_STATE_SYSTEM_STORE_FLAG -- 2
    CERT_ACCESS_STATE_LM_SYSTEM_STORE_FLAG -- 4

  Provider = Microsoft RSA SChannel Cryptographic Provider
  ProviderType = c
  Unique container name: 0e4122029ed9cd31a8781f880191ea36_2ab40618-dac2-4d86-9224-489cfd1e8af0
  RSA
  PP_KEYSTORAGE = 1
    CRYPT_SEC_DESCR -- 1
  KP_PERMISSIONS = 3b (59)
    CRYPT_ENCRYPT -- 1
    CRYPT_DECRYPT -- 2
    CRYPT_READ -- 8
    CRYPT_WRITE -- 10 (16)
    CRYPT_MAC -- 20 (32)

  D:AI(A;;GAGR;;;SY)(A;;GAGR;;;NS)(A;;GAGR;;;BA)(A;;GR;;;S-1-5-5-0-190452580)

    Allow Full Control  NT AUTHORITYSYSTEM
    Allow Full Control  NT AUTHORITYNETWORK SERVICE
    Allow Full Control  BUILTINAdministrators
    Allow Read  NT AUTHORITYLogonSessionId_0_190452580

Private key is NOT exportable
Encryption test passed

Александр Киреев

Эксперт отдела автоматизации и развития бизнеса Online-kassa.ru. Бизнес-тренер и аналитик, отвечает за работу с ключевыми клиентами.