I’m running an IBM Spectrum Protect Operations Centre server using a wildcard certificate. The Spectrum Protect server is actually running WebSphere Liberty server under the hood. WebSphere Liberty requires a pkcs12 certificate, which I’ve been using without problem for six months or so. That is: I’ve converted Let’s Encrypt wildcard certificates twice and successfully imported them into Liberty. Until the last update I did yesterday, where the procedure I have been using generates an error.

I have let’s encrypt installed on a Linux box and performed the update as usual using:/usr/local/bin/certbot -d *.domain.net --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns certonly

The webserver on the Linux box is working fine with the newly updated cert.

To convert for pkcs12 to be imported into the WebSphere liberty server, I issue the following command (which is the same command I’ve used twice before with no problem):openssl pkcs12 -export -out keystore.p12 -inkey privkey.pem -in fullchain.pem -name "default" -password pass:password

This generates a keystore.p12 file, which I copy over to the websphere server and import using the java keystore, using the following process:

The new “default” certificate is highlited in yellow, when I click on “validate” it says “warning: validation failed: Missing intermediate or root certificate”

I have updated Spectrum Protect (and consequently WebSphere Liberty) however this was with a previous version of the certificate made with the same process and everything continued working just fine, until this update.

From searching around the internet, it appears that I’m using the correct method to convert the let’s encrypt supplied files into a pkcs12, but TBH encryption is one of the few areas in IT where I’m at a loss knowledge wise, so I’m just not sure if I’m asking the right questions.

As for the ISRG Root Certificate - I’m not 100% I understand what this is, but what I think I know is that it’s the certificate used to sign the certificates that Let’s encrypt send to me? (I’m painfully aware that I don’t really know much about encryption…) So it forms part of the chain of trust? Does this need to be included into my pkcs12 file for some reason? If so, I don’t understand what it has worked before and not now?

This is simple - these are two certificates. Your domain certificate and the intermediate Let’s Encrypt X3 certificate. First is yours (save it as windows txt file with the file extension .crt), second is Let’s Encrypt X3.

I don’t use OpenSSL, but normally the intermediate certificate should be included in the pkcs12 file.

But I see the DST Root CA X3 as Root-Certificate. The Let’s Encrypt X3 is cross signed with that root certificate.

I have managed to solve the problem with help gratefully received from @JurgenAuer and a contact at IBM - without both of whom I could barely have started working this out.

As noted above, the PKCS12 file was valid.

In order to resolve the problem, I needed to download both the “Let’s Encrypt Authority X3 (IdenTrust Cross Signed)” and the IdenTrust “TrustID X3” root certificate and install them into the key manager as “Signer Certificates”. Then restart WebSphere Liberty Server.

I am at a total loss to explain why it worked for the last 9 months, but am investigating with my contact at IBM.

FYI, manually importing root and especially intermediate certificates isn’t a perfect long-term plan. The protocol is intended that CAs can change intermediates at any time without warning, though it doesn’t happen often; Let’s Encrypt will change to a different default root around 2021.

If you’re automating this, maybe you can script it to check if /etc/letsencrypt/live/example.com/chain.pem has changed and is in the store. (That’s the intermediate.)