Enabling a NIST SP800-131a compliant environment

You can configure IBM® Business Automation Workflow to support the National Institute of Standards and Technology (NIST) SP800-131a security standard. SP800-131a requires longer key lengths and stronger cryptography than other standards, such as FIPS 140-2. SP800-131a requires Transport Layer Security (TLS) V1.2.

1. Generate or import certificates and activate SSL on the directory server. This step varies depending on the LDAP server you are using.
2. Add the signer certificate of your LDAP server to the truststore of your application server.
3. Enable the SP 800-131a standard for IBM Business Automation Workflow.
   For updates to the administrative console, see Transitioning WebSphere Application Server to the SP800-131 security standard.

   Note: In a clustered environment, before you run the syncNode.bat or syncNode.sh command, change to strict mode and update the ssl.client.props configuration file, which is at ProcessDesignerInstallation Path/resources/ssl.client.props. You are prompted to accept the self-signed certificate into the truststore before the changes can be propagated. For background information and details, refer to Configuring WebSphere Application Server for SP800-131 standard strict mode.
4. Enable TLS V1.2 for all clients.
   Specify the Secure Sockets Layer (SSL) protocol to be used for client applications, such as the wsadmin command or the Process Designer. For the wsadmin command, see Transitioning WebSphere Application Server to the SP800-131 security standard. For the Process Designer, update the ssl.client.props configuration file, which is at ProcessDesignerInstallation Path/resources/ssl.client.props.
5. Configure SSL communication for Workflow Center and Workflow Server.
   See Configuring Secure Sockets Layer (SSL) communication in a network deployment environment.

   Note: After you convert the certificates to the NIST SP 800-131a standard in a clustered environment that includes a Workflow Center cluster and a Workflow Server cluster, add the Workflow Server signer to the Workflow Center truststore and add the Workflow Center signer to the Workflow Server truststore.
6. Specify that SSL is used for Enterprise JavaBeans (EJB) method calls.
   1. In the administrative console, click Security > Global security > RMI/IIOP Security > CSIv2 inbound communications.
   2. Select SSL-required in the Transport pull-down menu.
   3. In the administrative console, click Security > Global security > RMI/IIOP Security > CSIv2 outbound communications.
   4. Select SSL-required in the Transport pull-down menu.
7. Switch the data sources to SSL:
   • If you are using Oracle, perform step 7.a.
   • If you are using SQLServer, perform step 7.b.
   • If you are using Db2, perform step 7.c.

   1. If you are using Oracle, perform the following actions:
      1. The following configuration example assumes that SSL client authentication is enabled and the Public-Key Cryptography Standards 12 (PKCS12) wallet is being used in Oracle. You must generate a keystore and a certificate on the Oracle server. The following keytool command generates a self-signed Java KeyStore (JKS) format keystore:

         keytool -genkey -keyalg RSA -alias server_key_alias -keystore full_path_of_server_keystore_file.jks -dname “CN=machine_name” -storepass server_keystore_password -validity 360 -keysize 2048 -keypass server_key_password

         For example:

          keytool -genkey -keyalg RSA -alias dbserverkey -keystore /home/oracle/keystore/serverdbkeystore.jks -dname "CN=myOracleServer.company.com" -storepass Password -validity 3600 -keysize 2048 -keypass Password

         The following keytool command exports the keys of the Oracle server into a certificate:

         keytool -export -alias server_key_alias -storepass server_keystore_password -file full_path_of_server_certificate_file.cer -keystore lfull_path_of_server_JKS_file.jks

         For example:

         keytool -export -alias dbserverkey -storepass Password -file /home/oracle/keystore/servercertificate.cer -keystore /home/oracle/keystore/serverdbkeystore.jks

      2. Import the signer certificate for the database into the IBM WebSphere® Application Server Java cacerts truststore by running the following command:

         WAS_HOME/java/bin/keytool -import -file full_path_of_certificate_file -keystore WAS_HOME/java/jre/lib/security/cacerts -alias alias_of_certificate_file -storepass ts_password

         where WAS_HOME is the WebSphere Application Server home directory, full_path_of_certificate_file is the full path of the certificate file, alias_of_certificate_file is the alias of the certificate file, and ts_password is the truststore password.
      3. Because the WebSphere Application Server is a client to the Oracle server, the WebSphere Application Server is referred to as client and Oracle server is referred to as server in the following commands.
         1. Create the Java keystore on WebSphere Application Server by running the following command:

            WAS_HOME/java/bin/keytool -genkey -keyalg RSA -alias client_key_alias -keystore client_keystore_file.jks -dname “CN=computer_name” -storepass client_keystore_password -validity 360 -keysize 2048 -keypass client_key_password

            where WAS_HOME is the WebSphere Application Server home directory. For example:

            keytool -genkey -keyalg RSA -alias dbclientkey -keystore clientdbkeystore.jks -dname "CN=myserver.company.com" -storepass Password -validity 360 -keysize 2048 -keypass Password

         2. Export the keys of WebSphere Application Server into a certificate by running the following command:

            keytool -export -alias client_key_alias -storepass client_keystore_password -file full_path_of_client_certificate_file.cer -keystore full_path_of_client_JKS_file

            For example:

            keytool -export -alias dbclientkey -storepass Password -file /root/keystoreDir/clientcertificate.cer -keystore /root/keystoreDir/clientdbkeystore.jks

      4. Copy the certificate of the WebSphere Application Server to the Oracle server computer, then import the certificate into Oracle's keystore by running the following command:

         keytool -import -v -trustcacerts -alias client_key_alias -keypass client_key_password -file full_path_of_client_certificate_file.cer -keystore full_path_of_server_JKS_file -storepass server_keystore_password

         For example:

         keytool -import -v -trustcacerts -alias dbclientkey -keypass Password -file D:\serverkeystore\clientcertificate.cer -keystore D:\serverkeystore\serverdbkeystore.jks -storepass Password

      5. Copy the certificate of the Oracle server to the WebSphere Application Server computer, and import the certificate into the WebSphere Application Server keystore by running the following command:

         keytool -import -v -trustcacerts -alias server_key_alias -keypass server_key_password -file full_path_of_server_certificate -keystore full_path_of_client_keystore -storepass client_keystore_password

         For example:

         keytool -import -v -trustcacerts -alias dbserverkey -keypass Password -file /home/oracle/clientkeysore/servercertificate.cer -keystore /home/oracle/clientKeystore/clientkeystore.jks -storepass Password

      6. 1. On the Oracle server, create an empty wallet from the keystore by using the orapki command:

            orapki wallet create -wallet wallet_directory -auto_login -pwd wallet_password

            For example:

            orapki wallet create -wallet /home/oracle/serverKeystore -auto_login -pwd walletPassword1!

         2. Convert the JKS file to a wallet file by running the orapki command:

            orapki wallet jks_to_pkcs12 -wallet wallet_directory -pwd wallet_password -keystore full_path_of_server_keystore -jkspwd server_keystore_password

            For example:

            orapki wallet jks_to_pkcs12 -wallet /home/oracle/serverKeystore -pwd walletPassword1! -keystore /home/oracle/serverKeystore/serverdbkeystore.jks -jkspwd Password

         3. Ensure that the Oracle wallet has the keys by running the following command:

            orapki wallet display -wallet wallet_directory

         4. Copy the ewallet.p12 file to the WebSphere Application Server computer, if WebSphere Application Server and Oracle are installed on different computers.
      7. Ensure that the .ora files contain the required contents. On Oracle, the listener.ora file should contain:

         LISTENER = (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcps)(HOST=servername)(PORT=2484))
         ) WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=directory_of_the_wallet)))
         SSL_CLIENT_AUTHENTICATION=TRUE

         The SQLNET.ora file should contain:

         SQLNET.AUTHENTICATION_SERVICES = (TCPS,NTS)
         SSL_CLIENT_AUTHENTICATION = TRUE
         WALLET_LOCATION = (SOURCE=  (METHOD=File)  (METHOD_DATA=   (DIRECTORY=directory_of_the_wallet)))

         The tnsname.ora file should contain:

         ORCL =
           (DESCRIPTION =
             (ADDRESS_LIST =
               (ADDRESS = (PROTOCOL = TCP)(HOST = 0.0.0.0)(PORT = 1521))
                   (ADDRESS = (PROTOCOL = TCPS)(HOST = servername)(PORT = 2484))
             )
             (CONNECT_DATA =
               (SERVICE_NAME = orcl)
             )
           )

         Stop and start the listener to apply the changes.
      8. Add the Oracle certificate to the WebSphere Application Server CellDefaultTrustStore.
         1. Log in to the WebSphere Application Server Admin Console.
         2. Go to Security > SSL certificate and key management then click Key stores and certificates > CellDefaultTrustStore and click Signer certificates under Additional Properties and click the Retrieve from port button.
         3. Enter the information for the Oracle server. This information includes hostnames, the configured SSL port, and an alias, so that you can later identify it in the keystore.
         4. Click Retrieve signer information to show the details of the certificate, and to confirm that the Oracle server is listening on the port.
         5. Click OK to save the configuration.
      9. Set up the data source to use SSL by adding custom properties for the data sources which you wish to secure with SSL encryption.
         1. Log in to the WebSphere Application Server Admin Console, and go to Resources > JDBC > Data sources.
         2. This step uses the BPM Process Server data source, namely TeamWorksDB, but other data sources follow the same steps. Click BPM Process Server data source under Additional Properties and click the Custom Properties link.
         3. Click New. Add a property named connectionProperties with a value of

            javax.net.ssl.trustStore=wallet_directory/ewallet.p12;javax.net.ssl.trustStoreType=PKCS12;javax.net.ssl.trustStorePassword=wallet_password;oracle.net.ssl_version=1.0

            For Example, connectionProperties could have a value similar to:

            javax.net.ssl.trustStore=/root/keystoreDir/ewallet.p12;javax.net.ssl.trustStoreType=PKCS12;javax.net.ssl.trustStorePassword=walletPassword1!;oracle.net.ssl_version=1.0

         4. Go to the main data source configuration page and scroll to the bottom where the connection properties are and update the URL to the SSL value to

            jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=db_host_name)(PORT=security_port_number))(CONNECT_DATA=(SERVICE_NAME=database_alias)))

            For example, the SSL value may look similar to

            jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=9.110.86.237)(PORT=2484))(CONNECT_DATA=(SERVICE_NAME=orcl)))

         5. Click OK and then click Save directly to the master configuration.
         6. Click Test connection to test the connection to Oracle server through the secured port. You might need to click Synchronize before testing the connection.
         7. Repeat for any other data sources you wish to secure with SSL encryption.
   2. If you are using SQLServer, perform the following actions:
      1. Configure the SQLServer to use encrypted communications and export the server certificate as described in Enable Encrypted Connections to the Database Engine.
      2. Import the signer certificate for the database into the WebSphere Application Server Java cacerts truststore, for example, by running the following command:

         WAS_HOME/java/bin/keytool -import -file full_path_of_certificate_file -keystore WAS_HOME/java/jre/lib/security/cacerts -alias alias_of_certificate_file -storepass ts_password

         where WAS_HOME is the WebSphere Application Server home directory, full_path_of_certificate_file is the full path of the certificate file, alias_of_certificate_file is the alias of the certificate file, and ts_password is the truststore password.
      3. Set up the data source to use SSL. Add following custom properties for each data source:

         Table 1. Data source custom properties for SQLServer database

         Custom property name	Value	Notes
         encrypt	true	Specify that the SQL Server uses SSL encryption for communication with the database
         hostNameInCertificate	host_name_of_SQLServer	The host name used to validate the SSL certificate of the database
         trustServerCertificate	false	JDBC Driver to validate the SSL certificate of the database
         trustStore	WAS_HOME/java/jre/lib/security/cacerts	The fully qualified path to the certificate truststore file
         trustStorePassword	ts_password	The password for the truststore
         trustStoreType	JKS	The certificate type of the truststore is Java KeyStore

      4. Test the data source connection to the SQLServer.
   3. If you are using Db2, perform the following actions:
      1. To create a keystore with IBM Global Security Kit (GSKit), you need to add a root CA certificate into your keystore. To do this, see Creating a keystore with GSKit. You can also add self-sign certificates for servers in your network. See Self-signing digital certificates.
      2. To configure TLS support for Db2 see Configuring TLS support in a Db2 instance.
      3. Import the signer certificate for the database into the WebSphere Application Server truststore. Before the JDBC driver can use SSL to communicate with the database, the truststore that it uses requires the database's signer certificate. To get the signer certificate into the appropriate truststores:
         1. Go to Security > SSL certificate and key management and click Key stores and certificates under Related Items.
         2. Click CellDefaultTrustStore to go to the application server's default truststore.
         3. Click Signer certificates under Additional properties.
         4. On the Signer Certificates page, click Retrieve from port to retrieve the Db2's signer certificate.
         5. On the Retrieve from port page, enter the following values:

            Table 2.

            Field	Value	Notes
            Host	hostname	Host where Db2 is running
            Port	50443	Port on which Db2 is listening for SSL communication.
            Alias	MyRootCA or myselfsigned;	Keep this value consistent with the certification label used to create a keystore with GSKit in the first step of switching the data sources to SSL for Db2

         6. Click Retrieve signer information.
         7. Click Save.
      4. Set up the data source to use SSL:
         1. Go to Resources > JDBC > Data sources and click the data source to update to use SSL. For example, the data source could be jdbc/TeamWorksDB.
         2. Under the Additional Properties section, click the Custom properties link, find the sslConnection property, change the value to true, and save the changes. If the sslConnection property is not already in the list of custom properties, add the sslConnection custom property of type boolean to the data source and set the value to true. To add this custom property, go to the data source page and click Custom properties in the Additional Properties section. On the Custom Properties page, click New to create the sslConnection property.
         3. Go to the data source configuration page and update the port number in the common and required data source properties sections. This value should be the same as the ssl_svcename value that was set in the step to configure TLS support for Db2.
         4. Repeat steps 1-3 to configure other data sources that you wish to secure with SSL encryption.
         5. Synchronize and restart your node agents and application servers.
         6. Test the connection to ensure that your configurations are applied.
8. Switch the distribution and consistency services (DCS) transport link to SSL.
   1. In the WebSphere Application Server administrative console, click Servers > Core Groups > Core group settings.
   2. Click DefaultCoreGroup.
   3. Select DCS-Secure from the Channel framework pull-down menu.
   4. Save your changes and restart the server.
9. Disable unencrypted ports.
   1. In the WebSphere Application Server administrative console, click System administration > Deployment manager > Configuration > Ports.
   2. Click each instance of View associated transports.
   3. Disable each transport chain that shows Enabled in the SSL Enabled column.
      1. Click the name of the transport chain and clear the Enabled checkbox.
      2. Click OK.
      3. Click System administration > Nodes.
      4. Click each node and select the Local Topology tab.
      5. Expand the node name and expand Servers.
      6. Click the managed node and select the Configuration tab.
      7. Click Ports and click each instance of View associated transports.
      8. Disable each Transport Chain that shows Enabled in the SSL Enabled column.
      9. Click Save directly to master configuration.
      10. Stop the nodes, node agents, and deployment manager.
      11. Restart the deployment manager.
      12. Synchronize the configuration changes across each of the federated nodes by clicking System administration > Nodes. Select all the nodes and then click Full Resynchronize.
      13. Restart the node agents and nodes.