A few months ago a colleague who left generated a CA certificate from GoDaddy. I am not sure the exact steps he took but currently we would like to install the CA certificate on a server to fully comply with EFRIS regulations which mandate that clients should transition from self-signed certificates to CA certificates within 3 months of go-live.

Somehow he was able to generate the .p12 private certificate. I suspect he used a desktop application called Keystore Explorer but he set a password on the certificate so I can't use it because I don't know it.

I was able to access the godaddy website and downloaded the original certificate files provided by GoDaddy CA. They are a PEM file, a CRT file and two other files called bundle files.

My wish is to generate the relevant .p12 or .pfx or .jks private certificate out of these PEM and CRT files but I don't know how. I think the public certificate will still be the .crt file.

When I tried to use Keystore Explorer to generate the private key PKCS file, I was able to generate it but it did not have the private key in it and the server gave an error telling me that the private key is missing from the .pfx file. I am not sure what this private key is supposed to be. Is it something I should already have?

I have tried to google for ways to convert a PEM file to a PKCS file but the guides have been so far unclear. For now I am reading this SSL stackexchange post to find out how SSL works. Any help will be greatly appreciated.

  • 1
    Do you have the private key that corresponds with the public key in the PEM and/or CRT file? You'll need it, in order to do anything useful with the certificate. If you don't have it, you may want to just start over with a new keypair and a new CSR. Notwithstanding, you can use openssl pkcs12 to create PKCS#12 or PFX files from PEM or CRT files. See openssl.org/docs/man1.1.1/man1/pkcs12.html for more info.
    – mti2935
    May 22, 2021 at 21:33
  • 1
    1) "generated a CA certificate from GoDaddy." I doubt so. You get certificates from CA such as GoDaddy. You don't generate a "CA certificate". 2) "I was able to generate it but it did not have the private key" Because normally the private key never leaves your side, the CA generates your certificate based on content submitted that does not include the private key. In all cases your certificate provider should be able to help you install the certificate. At worst, you just start from scratch with a new request for certificate, and a new private key. May 22, 2021 at 21:34
  • @mti2935 Will the PKCS#12 file that I will generate be valid to the CA?
    – Gilboot
    May 22, 2021 at 21:44
  • @PatrickMevzek If I make a new request for a certificate from GoDaddy they will charge me double. I need a way to make use of the one they gave me already
    – Gilboot
    May 22, 2021 at 21:45
  • 2
    It's not a matter of whether or not the PKCS#12 file will be valid to the CA, it's a matter of whether or not the PKCS#12 file will be valid to the client. For that, you need the private key that the public key in the PKCS#12 was derived from. After the CA issues and signs the certificate, the CA is out of the loop. See my answer below for more info.
    – mti2935
    May 22, 2021 at 22:25

2 Answers 2


Based on the comments following the question, it seems that you do not have the private key that corresponds with the public key in the certificate files that you have. Without the private key, the certificate is not of much use, as clients will not be able to complete an SSL/TLS handshake with a server secured with this certificate without the server having the private key. See Could a stolen certificate show as trusted? for more info.

If you do not have the private key that the certificate originated from, then you may need to start over, by generating a new private key, then creating a certificate signing request (CSR) from this private key, then submitting the CSR to a certificate authority (CA) who will issue and sign the certificate. These steps can all be completed using openssl.

Many CA's (e.g. Comodo, GeoTrust, etc.) charge less than $10.00 USD for a one-year certificate, so loosing the private key is not a outrageously costly mistake. LetsEncrypt even offers free certificates. Also, some CA's will let you re-key an existing certificate in the event that the private key is lost or stolen. This basically amounts to the CA revoking the old certificate, and issuing a new certificate for the remaining life of the old certificate, where the new certificate is derived from a new private key.

Whichever route you go, the CA will probably issue the new certificate in PEM or CRT format. If your server requires the certificate in PKCS#12 or PFX fornat, you can use openssl pkcs12 to convert it. See https://www.openssl.org/docs/man1.1.1/man1/pkcs12.html for more info.

  • To nitpick: CRT is not a "format". Just an "usual" filename extension, but filenames, including extensions, are in fact irrelevant. I could be as well .cert. Only the content counts, and that content is indeed often PEM, which is Base64 encoding of binary data, or just DER. Same for PFX, not a format, just an "usual" extension name. It could be as well .p12 May 22, 2021 at 22:43
  • @PatrickMevzek So you're saying I can change the extension from CRT to PEM or to CERT and it wont matter at all?
    – Gilboot
    May 24, 2021 at 8:19
  • @Gilboot The filenames do not matter, except in some braindead software that will force files to have given patterns in names to be considered. May 24, 2021 at 14:19
  • @PatrickMevzek If I change the filename how will the software know how to open the file. I've observed that CER, CRT and PEM files can be opened with notepad, however P12 files give weird text when you open them with notepad, they look like this: 0‚ í0‚ ¦ *†H†÷
    – Gilboot
    May 24, 2021 at 14:29
  • 1
    @Gilboot As I said only the content matters. Only some OS rely on the filenames, others are smarter. PEM is a base64 based format, so you see typical ASCII letters and numbers. DER is a binary format, hence you can't expect to load it in notepad and see anything meaningful. May 24, 2021 at 16:04

It is important to understand that .p12 (and .pfx) certificates are "identity" certificates, and that there may be several CA components concatenated in a "stitched-in" manner. The key provided from an initial request may only be a component of the certificate you use of the same name.

So the .p12 he created may have been made by

cat foo.key + bar.pem + somechaincertificate.pem > stitched.txt openssl pkcs12 -export -in stitched.txt -out final.p12 -name 1

You need to know the step by step procedure for this, and your application needs the password. They must have put that somewhere safe.

If this was pressing, forget the costs of starting again with the CA provider, you need to pay a consultant to sort this out. They are worth their wage. Document the procedure.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .