How to get your extension .zip file ready for validation

Steps

Requirements:

1. Export your content from your QRadar system
2. Add a customized manifest.txt to the extension
3. Generate and submit a Certificate Signing Request (CSR)
4. Sign your extension

Step 1: Exporting your extension or content from QRadar

You need to export all your relevant content from your QRadar system. Depending on your content type, follow the steps in one of the following sections:

• Exporting a single application as an extension
• Exporting a multi-application extension or content pack

For more information on exporting content, go to:

https://www.ibm.com/docs/en/qsip/7.4?topic=content-methods-importing-exporting

Exporting a single application as an extension

Before you can export an application from QRadar, you need to know its local ID on your QRadar system.

1. Log in to the QRadar console terminal and type:
   psql -U qradar -c "select id, name from installed_application;"
2. From the resulting list, take a note of your application ID.
3. From the QRadar console’s command line, run the following command to export your extension:
   /opt/qradar/bin/contentManagement.pl -a export -c installed_application -i <4 digit application ID> 

Exporting a multi-application extension or content pack

If you need to produce an extension with more than one application or an extension with more content, you need to define a package file.  The package file lists the content type and ID combinations of all the content you want to include.

1. If you want to export an application with ID 1001 and rules with IDs 1274 and 1275, and a dashboard with ID 10, you need to create a simple text file with the following format:
   • One line for each content type
   • Each line is a comma-separated list
   • The first value is the content type
   • The remaining values are the IDs of the specific instances of that type you want to export
2. Run the following command to view a list of exportable content types:
   /opt/qradar/bin/contentManagement.pl -h export
3. Run the following command to search for specific instances by name to obtain the ID:
   /opt/qradar/bin/contentManagement.pl -c [content type] -r [regex]
   
   Regex can be the full or partial name of the item.
4. For the example, your text file content would look like this:
   installed_application,1001
   customrule,1274,1275
   dashboard,10
5. Run the following command to assemble and export your list of content types:
   /opt/qradar/bin/contentManagement.pl -a export -c package -f package.txt

1. Complete all the fields in Section 2 Extension Details of this Submission Portal.
2. Download the completed manifest.txt by clicking the link in the helptext. 
3. Extract the .zip file generated by the contentManagement.pl export action from the previous step.
4. Add the manifest.txt that was generated by the Submission Portal to the same hierarchical level as the XML file.
5. Rezip the content again and name your .zip file in the format extension name_version.zip

1. Using QRadar or another system with the keytool utility installed, run the following command:
   keytool -genkey -alias codesigningcert -keyalg RSA -keysize 2048 -keystore signingstore.jks
   
   This command generates a jks (Java keystore) object, and a private key inside it, with alias codesigningcert. To build the keystore, the following values are requested:
   • A passphrase for the keystore.
   • Various attributes of the key you are generating – name, organizational unit, organization, municipality, State, or Province, Country code,
   • A passphrase for the key itself.
     
     Supply values as you see fit for you and your organization.
     
     Note: The first attribute is “your first and surname”. Your name is used to populate the Common Name (CN) attribute of the private key Subject. If you are acting as an independent extension creator, supplying your own name is fine. If you are developing an extension on behalf of your employer or as part of a development team, we recommend providing a name representing your team or your project, for example: “IBM QRadar Development team” or “Log Source Management App team”. This recommendation is for both privacy and user trust reasons.   We are enhancing the Extension Management UI to allow users to see signature information so they can verify that the signature seems valid and from an expected author. If a QRadar user checks the signature details, a CN referring to the company/product/project looks more official than a person's name. If your organization has multiple products that may integrate with QRadar, ensure the CN includes more than just the organization name, such as "Organization - Product"
2. Run the following command to create the codesigningcert.csr file:
   keytool -certreq -alias codesigningcert -file codesigningcert.csr -keystore signingstore.jks
   
   This command generates a CSR file called codesigningcert.csr, which you can submit to mailto:ibm_security_qradar_extensions@wwpdl.vnet.ibm.com?subject=Submitting CSR, with a note indicating what company you represent (if any) and the name of your extension.
3. Make sure to save and keep your .jks file and remember the passphrases used in creating the keystore and private key – they are needed for the next step.
4. IBM uses this codesigningcert.csr to issue two signing certificates in your name from each of our CAs. We cannot use them to sign anything without the private key; they are only for your usage.

Results
Allow 1-2 weeks after submission of your codesigningcert.csr submission, you will be provided with a .zip file containing two folders: CA_old and CA_new. The .zip file is not sent from the mailing list address above, as such some mail providers may treat the email as unsolicited spam. If you do not receive your .zip file within two weeks you can reach out to the mailing list again to ask for an update.

Each folder contains three certificates: ca.crt.pem, intermediate.crt.pem, and a certificate generated from your certificate signing request. The ca.crt.pem and intermediate.crt.pem files in each folder are different files, named the same. You will use these certificates in the next step to sign your extension.

Step 4: Signing your extension

First save a backup of the keystore. Next follow these steps.  It is advised to preform each step in the guide one at a time by copying each step and filling out your specific data. Mixing up one path by re-using a command can be enough to put a cert in the wrong place and cause issues during signing. Make note of the advise to save a backup of the keystore before importing any certs. This is the easiest way to revert to a clean slate should you experience issues.

Next following these steps:

1. Create a second copy of your original signingstore.jks called signingstore_old.jks
2. Copy the CA_new folder to the same location where your original signingstore.jks resides. Run the following commands to import each cert into your keystore. These commands can be run on a QRadar system or any other system with a Java SDK installed.
3. Run this command to import the root CA cert: 
   keytool -import -v -trustcacerts -alias root -file CA_new/ca.crt.pem -keystore signingstore.jks
   
   When asked to trust the certificate, respond 'yes'.
4. Run this command to import the intermediate CA cert:
   keytool -import -v -trustcacerts -alias intermediate -file CA_new/intermediate.crt.pem -keystore signingstore.jks
   
   Again, you are prompted for the keystore passphrase. 
5. Run this command to import your own certificate:
   keytool -import -trustcacerts -alias codesigningcert -file CA_new/<your cert> -keystore signingstore.jks
   
   Again, supply passphrase when prompted. This command completes the first keystore.
6. Copy the CA_old folder to the same location where your second signingstore.jks copy resides and run the following commands to import each cert into your keystore.
7. Run this command to import the root CA cert:
   keytool -import -v -trustcacerts -alias root -file CA_old/ca.crt.pem -keystore signingstore_old.jks
   
   When asked to trust the certificate, respond 'yes'.
8. Run this command to import the intermediate CA cert:
   keytool -import -v -trustcacerts -alias intermediate -file CA_old/intermediate.crt.pem -keystore signingstore_old.jks
   
   Again, you are prompted for the keystore passphrase.
9. Finally, run this command to import your own certificate:
   keytool -import -trustcacerts -alias codesigningcert -file CA_old/<your cert> -keystore signingstore_old.jks
   
   Again, supply passphrase when prompted. This command completes the second keystore.
10. You now have two keystores ready to apply two signatures. Sign your extension .zip file with the original keystore:
    jarsigner -keystore signingstore.jks -tsa http://timestamp.digicert.com <your extension> "codesigningcert"
    
    This command prompts you for the keystore password first, then the private key passphrase set in Step 3.
11. Sign your extension .zip file again with the second keystore. Note the required use of the -sigfile parameter here:
    jarsigner -keystore signingstore_old.jks -tsa http://timestamp.digicert.com -sigfile oldcert <your extension> "codesigningcert"
    
    Your extension is now signed. The extension .zip file now includes a META-INF directory directly within in, containing 5 files:
    CODESIGN.RSA
    CODESIGN.SF
    MANIFEST.MF
    OLDCERT.RSA
    OLDCERT.SF
    
    QRadar reads this directory when an extension is uploaded to identify it is:
    • digitally signed, and if so, is it
    • signed by certificates issued by IBM CA

If you previously submitted an extension to IBM Security App Exchange and you still have your two fully constructed signing keystores, you need to repeat steps 10 and 11 to sign new versions.

To publish your extension see: 

https://www.ibm.com/support/pages/node/6256060