PKCS12 Generated but Certificate Chain Not valid

Hi Guys,

I'm using a platform called Manage Engine Service Desk MSP to run an IT Helpdesk, but I am having an issue getting the SSL certificate into a format that it will take. I think the PFX is being built right, but I am seeing an issue in the logs saying Certificate Chain is not Valid & Key Protection Algorithm Not Found. I'm guessing the algorithm that openssl is using to convert from the .pem to the .pfx may be something that isn't supported by the proprietary webserver that ManageEngine uses? Is there a way to change it? And any ideas what I should change it too? It looks like it's using a Java Engine to import the cert:
Verbatim Error is: Caused by: java.security.KeyStoreException: Key protection algorithm not found: java.security.KeyStoreException: Certificate chain is not valid

Just to confirm, the PFX exports, and on Windows it imports perfectly, I just think it's something that is unique to the process that is importing the certificate on this device.

My domain is: support.wellconnected.it

I ran this command: openssl pkcs12 -export -out /home/certificate.pfx -inkey /etc/letsencrypt/live/support.wellconnected.it/privkey.pem -in /etc/letsencrypt/live/support.wellconnected.it/cert.pem -certfile /etc/letsencrypt/live/support.wellconnected.it/fullchain.pem -passout pass:$$$$$$$$$$$$$$$

It produced this output: A PFX file(when importing into Windows it's full chain), but when importing into my software running on Ubuntu I get the errors listed - Chain Not Valid & Key Protection Algorithm not Found.

The operating system my web server runs on is (include version): Ubuntu 20.04

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Yes

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbox 1.22.0

Any assistance is greatly appreciated.

1 Like

I'm definitely not a Java expert, but I didn't think a Java KeyStore file was the same as a PFX (PKCS12) file. Their docs def talk about using Java's keytool to manipulate keystore files.

https://www.manageengine.com/products/service-desk-msp/help/installation-guide/documents/install-ssl.html

But since you've likely created the private key via an ACME client, the process is probably slightly different and may look something like this:

3 Likes

Try:

openssl pkcs12 -export \
 -out   /home/certificate.pfx \
 -inkey /etc/letsencrypt/live/support.wellconnected.it/privkey.pem \
 -in    /etc/letsencrypt/live/support.wellconnected.it/fullchain.pem \
 -passout pass:$$$$$$$$$$$$$$$
1 Like

Hey @rmbolger ,

It's strange, they've got multiple different documentation locations - this one is the one we used for our Windows install that worked well.

Basically if it's a PFX, you bypass the keystore process, and just add the certificate directly into the code(otherwise we'd need to manually upload the certificate every ~90days).

I'm leaning back towards the main issue being to do with the algorithm strength / type not being supported by the Java engine that's ingesting the certificate.

1 Like

It's quite possible I just stumbled onto an old version of the doc. I've read newer versions of Java do support PKCS12 and no longer default to the old keystore formats. But I'd also think that if they were on a newer version, they'd support most of the relatively modern algorithms and key sizes.

Sorry I couldn't be more help. I'd give @rg305's modified command a try too.

2 Likes

It worked for this topic:

1 Like

@rg305

Unfortunately the same error, even using the fullchain as the in file.

I wonder if it's maybe on the Certbot side that's causing the issue?

Even if I import the certificates into my Windows machine, and then re-export and try and import them onto the Linux box via the GUI the process dies.

The error message leads me to believe that could still be a main contributing factor, but I'm just not sure if it's at the PEM to PFX part that I need to adjust it, or if it's at the actual Certbot point.

Is there a way to manipulate that information on the fly while it's generating the cert's?

1 Like

My (complete!) guess would be that your system doesn't trust the root certificate (.e.g. it doesn't have ISRG Root X1 in it's trust store, and if it has DST Root CA X3 then it doesn't like the fact that's expired).

See the Installing the Root Certificate file section here maybe? ServiceDesk Plus - Installing SSL Certificate

2 Likes

@webprofusion
Good guess, just checked and there is no DST Root, and the ISRG X1 is in the cert store.

So I don't believe it's a trust thing from that POV.

3 Likes

It may not be useful to you but here is how we recommend doing it for Tomcat 9.x on Windows using Certify The Web : Apache Tomcat | Certify The Web Docs - I don't know which version of Tomcat Manage Engine is using. Basically we just give it the pfx (which we've already built) and set the specific options (e.g. key store type).

Check that your trust store also includes the current R3 intermediate certificate.

2 Likes

@webprofusion can I say, your solution CertifyTheWeb is hands down one of the best and easiest pieces of software to use.
It was great when I was playing around with things on a Windows box.

I may get CTW to generate the certificate and see if I can import it using the GUI, and then hopefully after that I can swap back to the certbot process.

I actually wish you had developed a CTW equivalent for Linux, would make everyone's life a million times easier, your software 'just works'.

3 Likes

@webprofusion
I think you may be onto something, I've just manually checked all of the certs in the folder and it doesn't look like the intermediate certificate is there.

But even when I publish the full chain as a PFX(thanks to CTW) it still doesn't verify.

But I do wonder if that's where our issue lies.

I wonder if I redo the cert as a ZeroSSL and run it if it'll be fine.

Will test and come back to you.

1 Like

@webprofusion

You were right, as soon as I did a ZeroSSL cert it went straight through.

Is there a way to download the Intermediate so that it accepts it? Rather than having to learn the command line process for ZeroSSL?

Thanks for all of your assistance with this BTW.

3 Likes

Thanks, a Linux version is in the works. It will hopefully be released this year but I'm the only developer and I've been promising a linux version for a while now :slight_smile:

Note that you can use CTW for ZeroSSL (or any other ACME CA) as well: Certificate Authorities | Certify The Web Docs

Regarding your Let's Encrypt cert problem I still think it sounds like ISRG Root X1 (issued by ISRG Root X1) is not in the trust store, possibly it needs R3 (issued by ISRG Root X1) as well. You can grab the various root and intermediate certs for Lets Encrypt here: Chain of Trust - Let's Encrypt - you'll note that there are 2 ISRG Root X1 certs. An ISRG Root X1 issued by DST Root CA X3 (the expired root) and also an ISRG Root X1 (issued by ISRG Root X1).

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.