Convert *crt to *p12 failed

[Adity12]

Hi All,

I have issue when try to covert *crt to *p12, which has been signed by CA third party.

The issue is appear message after i executed command " cpopenssl pkcs12 -export -out <final certicate.p12 > -in <combined certificate from CA (server certificate, intermediate, root ).crt > -inkey file < private key from generating csr before send to CA.key  >

show message " no certificate matches private keys"

Has anyone experienced with this issue? i already sure the key file and PEM pass phrase is correct.

I also add capture for this issue.

Thanks Regards

Dio Aditya

[Nüüül]

Hello,

would try this first:

How do I verify that a private key matches a certificate? (OpenSSL) - Powered by Kayako Help Desk So...

openssl rsa -modulus -noout -in myserver.key | openssl md5

openssl x509 -modulus -noout -in myserver.crt | openssl md5

(should work with cpopenssl too)

and compare both outputs, they should be the same.

[Adity12]

Hi,

Thanks for your help,

I already done verify both certificate and private keys, the result output is not same.

so i must another key from CA or other key? because as far i know, when we create *csr at the same time we also create private keys for this *csr and when CA sending the signed certificate we can use this private keys.

Maybe you have any experienced with this issue?

Thanks Regards 

Dio Aditya Pradana

[Nüüül]

Basically the private key seems not to be the private key, used to sign the csr. If in the directory there are more than one private key, use the command from above and check if any´s modulus output matches the one from the csr/cert.

A Private key is only generated if you tell openssl to do so (either in command or openssl config file) 

If you cannot reimagine/recall which key file was generated or if worse it has been overwritten by another key generation task (i.e. because it was generated with default file names) you should create a new pair of key and request then send the csr to the ca owner..

Best would be with unique file names (insert a timestamp or so). 

to me it sounds like the private key has been overwritten 

[Adity12]

Hi @Nüüül and @Vladimir 

Thanks for explanation.

I am still checking from *csr and its private.key

Here what i have done to compare md5 on *crs and private.key the result same, but after get *crt from CA those md5 is different with private.key 

For name private key we using <namedomain><2022>.key ( no spaces ) and for PEM Phrase we using same <namedomain><123>

I also try to change name private keys file from <namedomain><2022> to <namedomain>_<10082022> which is the date this csr is create on member cluster inetfw1, but the result still same.

Thanks Regards

Dio Aditya Pradana

[Vladimir]

Was the key originally generated with the name "<namedomain><2022>.key" or was it renamed after creation?

It does sounds like an incorrect key issue.

Depending on CA and the cert type, you may or may not have options of generating your key pairs. For instance, when requesting S/MIME cert from Sectigo, I had to:

Rename the file : Higher Intelligence LLC_cert_#####_key.pem to Higher_Intelligence_LLC_cert_#####_key.pem

Copy "Privatekey (Higher_Intelligence_LLC_cert_#####_key.pem), myemailcertificate.crt (cert_#####.crt) ,   CA-Bundle file (cert_#####_ca_bundle.crt) files in a directory such as your desktop.

navigate to that directory and execute:

openssl pkcs12 -export -in cert_#####.crt -inkey Higher_Intelligence_LLC_cert_#####_key.pem -certfile cert_#####_ca_bundle.crt -out myemailcertificate.pfx

Where names of the bundles and the keys were generated by CA and not arbitrarily chosen by me.

The option to save the keys locally was only presented once during the cert request process.

[Adity12]

Hi @Vladimir 

yes the original file name is <namedomain><2022>.key, this file is generated at the same time we generate *csr

we are currently using digicert as CA third party, and after that we receive 3 certificate seperate in 3 file DigiCertCA, Server Certificate and TrustedRoot.

when the *csr is generate, we sending those file to vendor CA for signed this *csr, and for private.key we save it on gateway.

we using this command for generating *csr :

Run: #cpopenssl req -new -out <CERT.CSR> -keyout <KEYFILE.KEY> -config $CPDIR/conf/openssl.cnf

Should i must convert this *crt to *p12 on that gateway or i can convert any place, as long i have file .key for those *crt from CA?

Currently i try this on management server and fail, for those gateway i am not yet try that.

Thanks Regards

Dio Aditya Pradana

[Vladimir]

You may be required to add that CA to you Trusted Root CAs objects if performing conversion on unit not used to create csr.

Also, (this is atcually an excerpt from Check Point DLP):

"

• Make sure that the CRT file has the full certificate chain up to a trusted root CA.

  Usually you get the certificate chain from the signing CA. Sometimes it split into separate files. If the signed certificate and the trust chain are in separate files, use a text editor to combine them into one file. Make sure the server certificate is at the top of the CRT file."

  @Timothy_Hall , can you chime in on this?

Thank you,

Vladimir

[Vladimir]

If your key file name contains spaces, try replacing them with the underscore and repeat the conversion process.

Regards,

Vladimir

[Nüüül]

You can basically convert it anywhere, where you have openssl. As long as you keep in mind, that leaving the private key somewhere is not a good idea so you should have a plan where to save the key in a safe space, later on. (In most cases I create the csr "off the box", import the p12 and save the keys etc. in safe spaces.)

And you won´t need to do that (key / csr creation) on the gateways/management server, as certificate is imported via SmartConsole. 

So csr and private key are compatible but the cert is not. when opening the server certificate with windows or issue 

cpopenssl x509 -noout -in <certfile> -text

cpopenssl req -noout -in csr.csr -text

and see, if this is the certificate you expect (see fields like " X509v3 extensions: // X509v3 Subject Alternative Name:" vs  "Requested Extensions: // X509v3 Subject Alternative Name")

Did you edit the openssl.cnf before creating the csr? You should at least configure some names and so on (Hostnames the cert will be issued for) within the file. 

[the_rock]

I agree 100% with @Vladimir . Had client with same issue and it turns out their key file name did indeed contain spaces, so once they fixed that, all worked as expected.

[Adity12]

Hi All,

Yesterday i already try to use tools sslshopper for convert *crt to *p12 and the result seems failed and show message that certificate is error. 

you can see the error on attachment.

Currently i planning to re-generate the *csr and send back to CA, since i find some field like FQDN is not true of FQDN my qustomer, so i can sure this is root cause this issue.

Thanks Regards

Dio Aditya Pradana