Manipulate a Key File to Create a new PFX Keystore

Dave Calderini, Avaya Advanced Engineering Team

A customer needed us to install a .pfx file to a 3rd party truststore but no one knew what the file’s password as well as that of the associated key were.

We had to use the files that were burned originally and could not burn a new certificate and key because the new certificate needed to have the same expiration date, serial number and certificate authority root CA certificate in the chain. 

It was decided that it was best to preserve the integrity of the original key so making a copy of it was the next step. A new key had to be created that didn’t have a password but was simply a variation of the original one so the new .pfx certificate could be created with the desired password. The new key then was given a password afterwords for security purposes.

A quick check on new .pfx file confirmed we had achieved the desired outcome.

Notice that the original certificate was burned on December 13, 2024. 

So then why was it only valid until June of 2026 and not December of 2026 like it should be since our AOC certificate templates permit a validity of 2 years? When the root CA certificate was interrogated it revealed that it also expires in June 2026. A CA can’t vouch for a signed certificate that is valid beyond its own root certificate’s expiration so the expiry dates and times are identical.

A further requirement of the new .pfx file was that its server entry alias had to be a specific value of “call_blacklist”. Hence the keytool command was used here

We have discovered in other scenarios, particularly with Orchestration Designer, that the certificate being used to replace an old one in the keystore needed to have the same alias as the original one. Thus, the author would encourage following this logic as a best practice moving forward.
 

Manipulating certificate files as discussed above can be done to create a new .pfx keystore when the original key’s password is unknown.