10

I am attempting to use OpenSSL to Convert a PEM File and RSA Private Key to a PFX file. Here is the example command I attempted to use:

openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem

In doing so, I receive the following error message:

unable to load private key
9068:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:pem_lib.c:696:Expecting: ANY PRIVATE KEY

The cert file looks like this:

-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----

and the Private Key looks like this:

-----BEGIN RSA PRIVATE KEY-----
....
-----END RSA PRIVATE KEY-----

I did some digging on the error but I have not found a solution yet.

EDIT

After some additional research it appears to be a problem with different openssl versions.

If I run it on my OSX system which is running 0.9.8zh 14 Jan 2016, these statements work fine.

However, if I run it on a Windows Machine with version OpenSSL 1.0.1p 9 Jul 2015 and OpenSSL 1.1.0g 2 Nov 2017, I get the above errors.

thxmike
  • 221
  • 1
  • 2
  • 7
  • 1
    Works for me! Does `openssl rsa -in -noout -text` show details of the key or an error? Maybe the private key file is corrupted? If it works, convert it to a PKCS#8 private key with `openssl pkcs8 -in -topk8 -nocrypt -out ` and attempt to generate a PKCS#12 with that. – garethTheRed Feb 23 '18 at 21:06
  • 1
    @garethTheRed: Thanks. This additional information was very helpful lead me deeper into the problem. – thxmike Mar 01 '18 at 15:45

7 Answers7

5

I was also stuck on same. And as @thxmike said. My case was also similar.

OpenSSL command did not worked as expected for this.
openssl pkcs12 -export -in c.cer -inkey c.key -out d.pfx

So I ended up using Certutil on Windows. As we wanted to add it to Azure.

Note:-
1. Make sure to change .crt to .cer.
2. Make sure to put the .cer and .key files into the same folder and with same name - (c.cer and c.key)

Then run:
certutil -MergePFX c.cer c.pfx

You should get your combined pfx file.
Cheers!

Manish Gupta
  • 151
  • 1
  • 4
2

After some throughout digging, I found that it was the Powershell scripts that generates the key and cert files.

Using Notepad++ on Windows and Tex-Edit Plus on OSX to identify hidden characters, I found that the files had extra [cr] at the end.

Using the command

openssl rsa -in <private key file> -noout -text
openssl x509 -in <cert file> -noout -text

Are good checks for the validity of the files

Since my source was base64 encoded strings, I ended up using the certutil command on Windows(i.e.)

certutil -f -decode cert.enc cert.pem
certutil -f -decode key.enc cert.key

on windows to generate the files. Once the files were correct, the OpenSSL command above worked as expected.

thxmike
  • 221
  • 1
  • 2
  • 7
  • After much searching and everything pointing to openssl (which i could not get working no matter what i tried), I came upon @thxmike solution and it worked first time! – 5202456 Jun 18 '20 at 12:50
1

After having a similar issue, looks like different versions of openssl unpack the pfx archive with different syntax for the private key. It can be a traditional format where the private key start and end with

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

or PKSC#8 syntax with start and end

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

*Note the difference is not just the RSA word.

Therefore you may have to convert the private key from traditional to pksc8 syntax with

openssl pkcs8 -in <private key file> -topk8 -nocrypt -out <new private key file>

https://linux.die.net/man/1/pkcs8

OrigamiEye
  • 326
  • 2
  • 10
  • Keep in mind that none of this happens inside the pfx archive; it's not the whole file that is being stored, but only the actual information about the key. So when exporting to pfx this is purely a problem with the `openssl` program itself not recognizing its own old .pem format, _not_ with the key being put in the archive incorrectly. (And vice versa, when importing from pfx, it doesn't matter how the pfx archive was made, the tool just decides PEM-vs-PKCS#8 output here and now.) – u1686_grawity May 18 '21 at 10:02
  • @user1686 thanks, I haved edited my answer to reflect it is openssl unpacking that sets the syntax not the pfx archive file. – OrigamiEye May 18 '21 at 10:08
0

you certificate cert.pem contains the key as well. Make sure you have the certifacte without the key. Use -nokeys while creating the cert.

0

You might have a password protected key file. I had to remove the passphrase on the key and it worked:

openssl rsa -in encrypted.key -out unencrypted.key

Then use the unencrypted key in your initial command:

openssl pkcs12 -export -out cert.pfx -inkey unencrypted.key -in cert.pem

Phoenix
  • 529
  • 1
  • 7
  • 24
asdf
  • 1
0

Had this same issue. Environment is Ubuntu in WSL2/Windows 11

Error:

unable to load private key
139944805250368:error:0909006C:PEM routines:get_name:
no start line:../crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY

For me, this was a permissions issue. OpenSSL could not access the file, but there is no indication here pointing to that being the issue.

My solution was:

sudo -s
chown -hR root yourdomain.com/
cd yourdomain.com/
openssl pkcs12 -export -out cert.pfx -inkey privkey.pem -in cert.pem

The conversion worked after taking ownership of the directory. After this I copied it to my home folder. Permissions were still funny getting it copied to windows, but after zipping the file up, I could copy it over.

Hope this helps someone!

0

I think the bug is related to openssl version, not sure... the steps bellow may work

openssl pkcs12 -in xxx.pfx -out xxx.nokey.pem -nokeys
openssl pkcs12 -in xxx.pfx -out xxx.withkey.pem
openssl rsa -in xxx.withkey.pem -out xxx.key
cat xxx.nokey.pem xxx.key > xxx.combo.pem 
  • 1
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Sep 30 '22 at 14:43