Error in pkcs12 openssl

pkcs12 error #12227


I want to combine the ca certification file and ca key file to pkcs12 file, the openssl-1.1.1g works ok but the openssl-3.0 reports error. the ca-cert.pem is my ca certification file and ca-key.key is my ca private key file , ca.p12 is my output file. I use the command as follow:
openssl pkcs12 -export -in ca/ca-cert.pem -inkey ca/ca-key.key -out ca/ca.p12
Enter Export Password:
Verifying — Enter Export Password:
ECF30000:error::digital envelope routines:evp_generic_fetch:fetch failed:crypto\evp\evp_fetch.c:307:Default library context, Algorithm (RC2-40-CBC), Properties ()
ECF30000:error::digital envelope routines:EVP_CipherInit_ex:initialization error:crypto\evp\evp_enc.c:176:
ECF30000:error::digital envelope routines:EVP_PBE_CipherInit:keygen failure:crypto\evp\evp_pbe.c:132:
ECF30000:error::PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error:crypto\pkcs12\p12_decr.c:37:
ECF30000:error::PKCS12 routines:PKCS12_item_i2d_encrypt:encrypt error:crypto\pkcs12\p12_decr.c:133:
ECF30000:error::PKCS12 routines:PKCS12_pack_p7encdata:encrypt error:crypto\pkcs12\p12_add.c:119:

The text was updated successfully, but these errors were encountered:

You may notice the algorithm it cant load is RC2-40-CBC, This algorithm lives in the ‘legacy’ provider now.
Add the following to your command line..

You may notice the algorithm it cant load is RC2-40-CBC, This algorithm lives in the ‘legacy’ provider now.
Add the following to your command line..


Unable to load certificates when trying to generate pfx file

I have been struggling for the last three hours trying to create an . pfx file using OpenSSL . I have been following this document and have been following the instructions under the Get a certificate using OpenSSL header.

I am at the step here: openssl pkcs12 -export -out myserver.pfx -inkey myserver.key -in myserver.crt and am using the OpenSSL.exe console.

I get the error: unable to load certificates

I have also tried this: x509 -text -in myserver.key and received the error: 0906D06D06C:PEM_read_bio:no start line:.\crypto\pem\pem_lib.b.c:703:Expecting: TRUSTED CERTIFICATE I also get that error if I try myserver.crt.

I seem to get it no matter what I do.

Can someone please help?

2 Answers 2

I get the error: unable to load certificates

myserver.crt needs to be in PEM format. Does it have —— BEGIN CERTIFICATE —— and —— END CERTIFICATE —— ?

myserver.crt should actually be a chain of certificates (and not just the one server certificate). The chain should include all intermediate certificates needed by the client to verify the chain.

You send all the intermediate certificates to solve the «which directory» problem. The «which directory» is a well know problem in PKI. Essentially, the client does not know where to go to fetch the missing intermediate cert. To avoid the problem, you send all intermediates.

I often use Startcom because they offer free Class 1 certificates. When I get the signed server certificate from them (for example, www-example-com.crt), I add their Class 1 Server Intermediate to it. I get their Class 1 Server Intermediate from their website at Startcom CA certs. The one I use is .

With the www-example-com.crt , my server certificate looks like:

For completeness, the private key (for example, www-example-com.key ) is also in PEM format. It uses ——BEGIN RSA PRIVATE KEY—— and ——END RSA PRIVATE KEY—— .

With my server certificate in PEM format (and with the required intermediates) and private key, I then issue the following (which looks like the same command you are using):

When clients connect, they use the Startcom CA. So, to test the connection (after loading into IIS):

The command should complete with «Verify OK»:

I have also tried this: x509 -text -in myserver.key and received the error.

x509 is for certificates. If you want to dump a key, use OpenSSL’s pkey command. See the docs on OpenSSL’s pkey(1) command.


openssl pkcs12 using stdin reports unable to load certificates — should it be able to? #10517


For years, I have been using the following one-liner to alter the «CSP» setting of any given PFX, without any issue:

«Recently», this has started failing with the error message:

Читайте также:  The connection was reset wordpress error

I’m running from distro-packaged versions, which appear to be based on 1.0.2g (Ubuntu Xenial) and 1.0.1e-fips (CentOS 6), so I know I’m not running latest source, and I don’t want to raise a bug based on the behaviour of these older versions, without first verifying my findings and understanding (hence the question).

My understanding is that openssl pkcs12 accepts input from stdin by default when -in is not passed: input should consist of PEM-armoured base64 objects, where at least one must be a certificate and (where -inkey is not passed) the other must be its key.

This understanding is based on the documentation for -in and -inkey in man pkcs12 , which reads:

-in filename
The filename to read certificates and private keys from, standard input by default. They must all be in PEM format. The order doesn’t matter but one private key and its corresponding certificate should be present. If additional certificates are present they will also be included in the PKCS#12 file.

-inkey filename
file to read private key from. If not present then a private key must be present in the input file.

But, at the moment, I can’t get any stdin-based form of openssl pkcs12 to actually parse input to that understanding.

So far, my repeatable test is:

$ openssl req -x509 -subj ‘/’ -newkey rsa:2048 -keyout src.key -out src.crt

$ openssl pkcs12 -export -in src.crt -inkey src.key -out src.pfx

PFX is usually created elsewhere and given to me to fix, so no access to original key and cert

$ openssl pkcs12 -in src.pfx | openssl pkcs12 -export -CSP ‘Microsoft Enhanced RSA and AES Cryptographic Provider’ -out fixed.pfx

Things that work

Parsing the output of pkcs12 as x509 :

$ openssl pkcs12 -in src.pfx | openssl x509 -text

Parsing the output of pkcs12 as pkey :

$ openssl pkcs12 -in src.pfx | openssl pkey -text

Exporting to intermediary temp files, then using -in and -inkey :

$ openssl pkcs12 -in src.pfx | openssl x509 -out inter.crt

$ openssl pkcs12 -in src.pfx | openssl pkey -out inter.key

$ openssl pkcs12 -export -in inter.crt -inkey inter.key -out fixed.pfx -CSP ‘Microsoft Enhanced RSA and AES Cryptographic Provider’

Bash process substitution (with appropriate password handling):

$ openssl pkcs12 -export -in

Related things that don’t work

Concatenating the output of x509 and pkey files, and passing by stdin:

$ cat inter.crt inter.key | openssl pkcs12 -export -CSP ‘Microsoft Enhanced RSA and AES Cryptographic Provider’ -out inter.pfx

Executing both x509 and pkey in a subshell, and passing by stdin:

$ ( openssl pkcs12 -in test.pfx | openssl x509 -outform PEM; openssl pkcs12 -in test.pfx | openssl pkey -outform PEM; ) | openssl pkcs12 -export -CSP ‘Microsoft Enhanced RSA and AES Cryptographic Provider’ -out fixed.pfx

The text was updated successfully, but these errors were encountered:

For years, I have been using the following one-liner to alter the «CSP» setting of any given PFX, without any issue:

I couldn’t get this one-lliner to work with any version of OpenSSL. I tried all the way back to 1.0.1 which you mentioned in your post. So if this worked «recently», I’m intrigued! Do you know which version of OpenSSL this worked on?

The pkcs12 app reads things from the input file in multiple passes. First it opens the file, looks for a key in it, and then reads that key. Next it opens the file again, looks for certificates in it and reads all of those. The difference between stdin and a normal file is that you can’t go back with stdin! It’s one pass only. So what is happening in your test case is that it sucks in all of the data looking for a key first of all. The key happens to be the last thing that it reads from stdin. Next it tries to find certificates, but it’s already read all the data and there is nothing left to read in — hence the «unable to load certificate» error message.

Читайте также:  Что значит эта ошибка http error 500

A possible workaround is to use the «-nokeys» option to the pkcs12 app. This prevents the reading and writing of the keys (in spite of the documentation which suggests this is about suppression of writing keys only).

The only «fix» I can think of would be to read all the data into a temporary file somewhere (or possibly just into memory), so that we can make multiple passes over it. But I’m more tempted to just treat this as a documentation issue, and document the restrictions associated with stdin. We should also update the documentation for the «nokeys» option.

@mattcaswell — thanks for looking for me. With regards to trying to determine exactly when it stopped working, I’m sorry I couldn’t be specific.

The one-liner is in a script I wrote a long time ago, which resides on a utility CentOS6 VM I have. The script has been used a number of times successfully in the past, but the server’s filesystem does not track birth time, so I can’t see when the script was written.

Your description of how pkcs12 works does shed some light on things however, and revising both the failing «related» tests to emit the key before the cert does succeed. Is it possible that, at some point, the output of pkcs12 was changed to emit cert before key, where it once emitted key before cert?

For completeness, a rough history of the versions of openssl that I have been using previously is below. Looking back through my certificate archive, I’ve got a successful output from October 2017 and I think my first failing one was December 2018, so the pertinent update is probably the jump from openssl-1.0.1e-16.el6_5.7.i686 to openssl-1.0.1e-42.el6.i686 — I’m not sure how well the distro-packaged versioning ties with the formal releases, though:

Is it possible that, at some point, the output of pkcs12 was changed to emit cert before key, where it once emitted key before cert?

That is certainly a plausible explanation


© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.


Troubleshoot PKCS#12 File Installation Failure with Non-FIPS Compliant PBE Algorithms

Available Languages

Download Options

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.



This document describes how to troubleshoot the installation failure of a Public Key Cryptography Standards (PKCS)#12 file with non-Federal Information Processing Standard (FIPS) compliant Password-Based Encryption (PBE) algorithms via Cisco Firepower Management Center (FMC). It explains a procedure to identify it and to create a new compliant bundle with OpenSSL.

Background Information

The Cisco Firepower Threat Defense (FTD) supports compliance with FIPS 140 when you enable Common Criteria (CC) or Unified Capabilities Approved Products List (UCAP) mode on a managed device. This configuration is part of a FMC Platform Settings policy. After applied, the fips enable command appears in the show running-config output of FTD.

Читайте также:  Error in invoking target agent nmhs

PKCS#12 defines a file format used to bundle a private key and the respective identity certificate. There is the option to include any root or intermediate certificate that belongs to the validation chain as well. PBE algorithms protect the certificates and private key portions of the PKCS#12 file. As a result of the combination of the Message Authentication Scheme (MD2/MD5/SHA1) and the Encryption scheme (RC2/RC4/DES), there are multiple PBE algorithms but the only one that is FIPS compliant is PBE-SHA1-3DES.

Note: To learn more about FIPS in Cisco products navigate to FIPS 140.

Note: To learn more about the security certifications standards available for FTD and FMC navigate to the Security Certifications Compliance chapter of the FMC Configuration Guide.



Cisco recommends that you have knowledge of these topics:

  • Public Key Infrastructure (PKI)
  • OpenSSL

Components Used

The information in this document is based on these software versions:

  • FMCv — (build 57)
  • FTDv — 6.5.0 (build 115)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Note: The approach described in this document can be implemented to any other platform with a similar issue, for instance, a Cisco Adaptive Security Appliance (ASA), since the issue is with the certificate being non-FIPS compliant.

Note: This document does not address the condition where the PKCS#12 components themselves are not compliant by any other reason like the Rivest, Shamir, Adleman (RSA) key length or the Signature algorithm used to sign the identity certificate. In such cases, certificates need to be re-issued to be FIPS compliant.


When FIPS mode is enabled in FTD, certificate installation might fail if the PBE algorithms used to protect the PKCS#12 file are not FIPS compliant.

Note: Find a step-by-step procedure on how to install a PKCS#12 file using the FMC in PKCS12 Enrollment section of Certificate Installation and Renewal on FTD managed by FMC.

If certificate installation fails for this reason, PKI debugs prints error below:

You can also confirm with OpenSSL that the PKCS#12 at hand includes non-compliant FIPS PBE algorithms.

In previous output there are two PBE algorithms, pbeWithSHA1And40BitRC2-CBC and pbeWithSHA1And3-KeyTripleDES-CBC, which protect the certificates and private key respectively. The first one is not FIPS compliant.


The solution is to configure PBE-SHA1-3DES algorithm for both certificate and private key protection. In the above example, only the certificate algorithm needs to be changed. First, you need to get the Privacy-Enhanced Mail (PEM) version of the original PKCS#12 file leveraging OpenSSL.

Last, you need to use below command with the FIPS compliant PBE algorithm using the PEM file obtained in the previous step to generate a brand new PKCS#12 file:

Note: If the algorithm to protect the private key needs to be changed as well, you can append the -keypbe keyword followed by PBE-SHA1-3DES to the same command: pkcs12 -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -export -in -out -out


Use the same OpenSSL command to obtain information about the PKCS#12 file structure to confirm FIPS algorithms are in use:

Now PKI debugs shows output below when certificate installation succeeds.

Finally, the FMC shows both CA and Identity certificates as available:


Оцените статью