xECM 24.2 - Digitally Sign the Module - Reposting in CSIDE Category

I decided to try this out today. Since there is a release coming up soon, I tried to do this with a legitimate certificate as opposed to self-signed. From IIS on the host which has the certificate, I exported the PFX file with a password and with the private key. I installed the certificate on the WIndows Server 2019 host where I've been doing my development, and I exported the public key as .cer file to import into my Java JDK cacerts file.

When I ran the signing tool as

java -jar ollsigner-1.3.0.jar -keystore cert/my-pfx-file.pfx -storepass mypasswd -keypass mypassword myospace.oll I get the following error (BTW above is exact syntax from the CSIDE documentation):

Please specify [ollfile] and [alias].
usage: java -jar ollsigner.jar [options] [ollfile|ollfolder] [alias]

Since there is an .OLL file present, that's not the thing that's missing, but it wants the alias for the private key. If I'm using an export from IIS of the existing cert, how do I go about creating an alias in the keystore as the PFX file is a key store?

I want to avoid having to send a whole separate CSR because each certificate request costs money (unless you do LetsEncrypt, but then it's good for only 90 days).

I know the signing process is not mandatory for partners, but customers seeing a partner module "unsigned" will think there is something inherently insecure about it, so partners are ultimately going to have to do this.

-Hugh Ferguson

I was wondering whether I should be using JKS or PKCS12 (which the .PFX file is already in). Based on the instructions, I tried to run the Java utils.ImportPrivateKey class but keep getting a class not found error (is this only available if you have a WebLogic server installed).

Ultimately I am trying to import the private key in with alias which I cannot otherwise do. It's simple enough to convert the PFX file into a JKS keystore, it's just

keytool -importkeystore -srckeystore mypfxfile.pfx -srcstoretype pkcs12 -destkeystore clientcert.jks -deststoretype JKS

But no where does it force you to have an alias.

The earlier part of the article referenced OpenSSL. Big problem with that is trying to find a valid implementation - OpenSSL org doesn't release actual implementations of the standard, just the standard, and you're left fumbling around to find a free one that you can trust.

-Hugh

Keytool list was the thing I needed. First line was the alias it generated. When I used that, the ospace signer worked. I just verified that it works. Here is the full list of steps:

1. From a server where you have your SSL certificate on an IIS machine, you probably have the certificate already installed. At least in my case I did. Run the Manage Computer Certificates from start menu in WIndows, and find your certificate.
2. Right click on the certificate and choose export. Choose to export the private key and make sure you give this export a password;
3. You now have a .pfx file which is a keystore of type pkcs12
4. Run the keytool import step I did above. You will need to have a JDK on your server and the JDK/bin directory in your PATH. The full command is keytool -importkeystore -srckeystore mypfxfile.pfx -srcstoretype pkcs12 -destkeystore yourkeystore.jks -deststoretype JKS
5. In the above you will be prompted for the password for the new key store, then the password for your .pfx file you just created;
6. To get the alias that you are going to need for the signing step, run keytool -v list -keystore yourkeystore.jks | more`
7. You will see an output like this:
   
8. In the above output, you want the whole alias including the brackets;
9. Now you can run the signing tool,for example:

java -jar ollsigner-1.3.0.jar -keystore mykeystore.jks -storepass mypassword -keypass mypassword yourospace.oll {abc-def-blah-blah-blah)

I checked the security section for signed ospaces after I did this, and it did show my ospaces as signed and valid. You will need to add this process to your CI/CD pipeline. The ideal thing is that if you can deposit a cert into CSIDE and have it automatically sign the ospaces as they are built, but for now, this process works, and is repeatable.

Only thing I'm not sure if you need is I exported the public part of my .pfx to a .cer file and imported it into my cacerts file. I don't think that step is necessary - just a carry-over from when I was working in a closed environment where access to the root CA's was not guaranteed.

-Hugh

Found it in the quoted post from above. For 24.4 it's here:

https://support.opentext.com/csm?sys_kb_id=e6094500fbe11250ea40f68ff4efdc2b&id=kb_article_view&sysparm_rank=2&sysparm_tsqueryId=cb72dca4936e5290e502b1eb5cba105b

I got to it by doing a search on ollsigner-24. Oddly searching on ollsigner returned only the code change notes for V 24.4