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

Mahesh Pinnamaneni

Appreciate if anyone has any info on how to sign the OLL files.

https://forums.opentext.com/forums/developer/discussion/312575/xecm-24-2-digitally-sign-the-module

Dave Carpeneto

Hi - this isn't a required step. Going forward (as of 24.2) Content Server supports signing OSpace files (some of our clients require this for security purposes).

If you are a developer, and are interested in providing signed modules to your client base: have a look at the OLLSigner documentation (in CSIDE: help → Content Server SDK Documentation → OLL Signer User Guide).

Greg Griffiths

more details in the following post on the same topic in another forum here …

https://forums.opentext.com/forums/developer/discussion/312575/xecm-24-2-digitally-sign-the-module

Dave Carpeneto

Thx @Greg Griffiths . I have a hard enough time finding my way about in this forum - I don't even try to look @ the other forums 😉

Greg Griffiths

@Dave Carpeneto happy to help, useful for those of us who use the forums for investigation, such as myself, to find related content :)

HFCDev

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

Dave Carpeneto

Hi @HFCDev - I just realized our docs don't spell out that the OLLSigner utility works with JKS files (not PFX). You'll want to translate the file you have via steps akin to https://www.digicert.com/kb/ssl-support/jks-import-export-java.htm . The JKS file will require you to attach an alias to the certificate(s) it stores, which is what you'll pass to the utility. I'll open up a ticket over here to get the docs revised.

HFCDev

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

Dave Carpeneto

Alias isn't an option for the "importkeystore" option (but it is for the "import" / "importcert" option). Importkeystore is designed to work with things that contain multiple items, and aliases (where they exist) get imported alongside the items they reference.

If the above command worked OK, then what does keytool -v -list -keystore clientcert.jks show? This should provide info on what the alias is for the certificate(s) imported. I think keystore entries need an alias, but I'm not an expert here 😕

HFCDev

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