In our BPM development community many developers and testers have to set up BPM environments using some automated process - sometimes multiple times a day. I see many of them carelessly "clicking away" the certificate warning that their browsers bring up when accessing such an out-of-the-box environment. This is a habbit that is probably also common for many service consultants and customers who frequently interact with a proof-of-concept type of environment that is not set up to use "proper" SSL certificates. This is a habbit that must be discouraged as the same warning has to be taken very seriously when accessing a serious environment!
For the purposes in this blog post, I'll refer to environments that are set up for small testing exercises, possibly on a single laptop, as proof-of-concept PoC environments.
If you routinely set up such PoC environments you get new SSL certificates for each environment - including a new root signer certificate for each environment. This requires you to import the new signer into all the different clients that you have - most prominently: browsers.
You can create a signer certificate yourself (or use one from your current environment) and refer to it when creating a new environment using the BPMConfig tool. WebSphere will then issue node level certificates signed by this signer and all your clients stay happy.
Using the same signer certificate for multiple environments is also useful when setting up a Process Center environment with one or more connected online Process Servers. By using the same signer certificate for all cells, there is no need for certificate exchange between the cells.
Finding the root signer in your current BPM environment
By default the view in WebSphere's admin console under Security > SSL certificate and key management > Key stores and certificates shows SSL certificate stores only. Switch to view the root key store:
This translates to, e.g.
Alternative: create your own signer using IBM SDK for Java's keytool
IBM SDK for Java comes with a command line utilty that is more powerful than the graphical "iKeyMan" utility that many already know. If your BPM environment is on Java 6, keytool is not the most powerful. I use the one from Java 8 on Windows to call from c:\ibm\java8\sdk\bin
keytool.exe -genkeypair -keystore \ssl\bpm\root-key.p12 -storetype PKCS12 -storepass passw0rd -keypass passw0rd -keyalg RSA -alias root -ext bc:c -dname cn=root,o=bpm -validity 3650
keytool.exe -exportcert -keystore \ssl\bpm\root-key.p12 -storetype PKCS12 -storepass passw0rd -alias root -rfc > \ssl\bpm\root.cer
This creates a directory c:\ssl\bpm containing two files:
- root-key.p12 containing a self-signed certificate which is good for ~10 years and can be used to sign other certificates. By default the certificate has a 2048 bit RSA public/private key pair and uses a SHA-256 signing algorithm (which browsers will demand starting 2016). This keystore contains both: the public and the private key. This is what production operators keep in a vault.
- The certificate containing the public key is extracted as a .cer file so we can import it into any clients that needs to trust it.
Pointing to an existing signer certificate when creating your PoC environment
When you use the BPMConfig utility to create a PoC BPM environment, you typically feed it with a properties file that is based on an example you found in the BPM\samples\config\standard sub-directory of your BPM installation.
It contains a property that allows you to pass additional parameters to the manageprofiles command.
I used the following options
- importSigningCertKS: tell the command to use an existing key store with an existing signing key
- importSigningCertKSAlias: point to the key in the key store using the key alias (if you are reusing a keystore from a BPM environment, the alias is root)
- importSigningCertKSPassword: password for the key
- keyStorePassword: key store password (WebSphere default is WebAS)
- importSigningCertKSType: the file format of the keystore. cWAS typically uses PKCS12 so that's what I created with keytool, too.
bpm.dmgr.profileOptions=-importSigningCertKS c:/ssl/bpm/root-key.p12 -importSigningCertKSAlias root -importSigningCertKSPassword passw0rd -keyStorePassword passw0rd -importSigningCertKSType PKCS12
Importing the signer certificate into your browser and OS trust store
When creating the keystore containing the signer certificate using keytool, I already exported the public certificate part into a dedicated .cer file.
If you are reusing the keystore of an existing BPM environment, you need to do that on either the root-key.p12 keystore or the CellDefaultTrustStore (<dmgr_profile_root>/config/cells/trust.p12):
keytool.exe -exportcert -keystore C:\ibm\BPM\v8.5\profiles\DmgrProfile\config\cells\nodename1Node01Cell\trust.p12 -storetype PKCS12 -storepass WebAS -alias root -rfc > \ssl\bpm\bpm-root.cer
Chrome and Internet Explorer / Edge use the operating default keystores / truststores. In order to import a certificate on Windows, you simply double click the .cer file, verify the certificate details and hit the "install certificate" button. Make sure to select the truststore as "trusted root ceritification authorities".
This is VERY SIGNIFICANT trust decision, so Windows comes up with a confirmation dialog and possibly User Account Control (UAC) requires you to provide admin credentials.
This allows you to access BPM without certificate warnings from IE, Edge and Chrome.
Firefox users, please go to Tools > Options > Advanced > Certificates > Show certificates
Under "Authorities" you can import your signer cert and specify the purposes for which the signer's signature can be trusted. Here, it is sufficient to identify web sites.