Update SSL configurations to V9.0 configuration definitions after migration

When migrating to v9.0, we can update the format for SSL configuration or we can continue to use the format of the earlier version. If we encounter errors with our existing administration scripts for SSL configurations, use this task to manually convert our SSL configuration to the v9.0 format.

When migrating to v9.0, we can use the WASPreUpgrade command to save the configuration of our previously installed version into a migration-specific backup directory. When migration is complete, we can use the WASPostUpgrade command to retrieve the saved configuration and WASPostUpgrade script to migrate the previous configuration. The -scriptCompatibility parameter for the WASPostUpgrade command specifies whether to maintain the 6.1 or above configuration definitions or to upgrade the format to v9.0 configuration definitions. If we used the default value, or -scriptCompatibility true when migrating, we do not need to perform this task. If we set the scriptCompatibility parameter to false during migration, you may notice that our existing administration scripts for SSL configurations do not work correctly. If this occurs, use this task to convert our 6.1 or above SSL configuration definitions to v9.0 This process creates a new SSL configuration based on the existing configuration.

Follow the steps below to modify the existing SSL configuration:

<repertoire xmi:id="SSLConfig_1" alias="Node02/DefaultSSLSettings">

    <setting xmi:id="SecureSocketLayer_1" keyFileName="install_root/etc/MyServerKeyFile.jks"
                                          keyFilePassword="password" 
                                          keyFileFormat="JKS" 
                                          trustFileName="install_root/etc/MyServerTrustFile.jks"
                                          trustFilePassword="password" 
                                          trustFileFormat="JKS" 
                                          clientAuthentication="false" 
                                          securityLevel="HIGH" 
                                          enableCryptoHardwareSupport="false">
    
        <cryptoHardware xmi:id="CryptoHardwareToken_1" tokenType="" 
                                                       libraryFile="" 
                                                       password="{custom}"/>
    
        <properties xmi:id="Property_6" name="com.ibm.ssl.protocol" value="SSL"/>
        <properties xmi:id="Property_7" name="com.ibm.ssl.contextProvider" value="IBMJSSE2"/>

    </setting>

</repertoire>

Procedure

1. Create a key store that references the key store attributes in the old configuration.

   1. In the existing configuration, find the keyFileName, keyFilePassword, and keyFileFormat attributes.

      keyFileName="${install_root}/etc/MyServerKeyFile.jks" 
      keyFilePassword="password" 
      keyFileFormat="JKS"
      

   2. Use the keyFileName, keyFilePassword, and keyFileFormat attributes to create a new KeyStore object. For this example, set the name as "DefaultSSLSettings_KeyStore".

      Using Jacl:

      $AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_KeyStore -keyStoreLocation ${install_root}/etc/MyServerKeyFile.jks -keyStoreType JKS -keyStorePassword password -keyStorePasswordVerify password }
      depfeat

      The resulting configuration object in the security.xml file is:

      <keyStores xmi:id="KeyStore_1" name="DefaultSSLSettings_KeyStore" 
                                     password="password" 
                                     provider="IBMJCE" 
                                     location="install_root/etc/MyServerKeyFile.jks" 
                                     type="JKS" 
                                     fileBased="true" 
                                     managementScope="ManagementScope_1"/>
      

      If we specify the cryptoHardware values in the configuration, create the KeyStore object using these values instead. Associate the -keyStoreLocation parameter with the libraryFile attribute, the -keyStoreType parameter with the tokenType attribute, and the -keyStorePassword parameter with the password attribute.

      <cryptoHardware xmi:id="CryptoHardwareToken_1" 
                      tokenType="" 
                      libraryFile="" 
                      password=""/>
      

2. Create a trust store that references the trust store attributes from the existing configuration.

   1. Find the trustFileName, trustFilePassword, and trustFileFormat attributes in the existing configuration.

      trustFileName="install_root/etc/MyServerTrustFile.jks" 
      trustFilePassword="password" 
      trustFileFormat="JKS"
      

   2. Use the trustFileName, trustFilePassword, and trustFileFormat attributes to create a new KeyStore object. For this example, set the name as "DefaultSSLSettings_TrustStore".

      Using Jacl:

      $AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_TrustStore -keyStoreLocation install_root/etc/MyServerTrustFile.jks -keyStoreType JKS -keyStorePassword password -keyStorePasswordVerify password }

      The resulting configuration object in the security.xml file is:

      <keyStores xmi:id="KeyStore_2" name="DefaultSSLSettings_TrustStore" 
                                     password="password" 
                                     provider="IBMJCE" 
                                     location="install_root/etc/MyServerTrustFile.jks" 
                                     type="JKS" 
                                     fileBased="true" 
                                     managementScope="ManagementScope_1"/>
      

3. Create a new SSL configuration using the new key store and trust store.

   Include any other attributes from the existing configuration which are still valid. Use a new alias for your updated SSL configuration. We can not create an SSL configuration with the same name as our existing configuration.

   Using Jacl:

   $AdminTask createSSLConfig {-alias DefaultSSLSettings -trustStoreName DefaultSSLSettings_TrustStore -keyStoreName DefaultSSLSettings_KeyStore -keyManagerName IbmX509 -trustManagerName IbmX509 -clientAuthentication true -securityLevel HIGH -jsseProvider IBMJSSE2 -sslProtocol SSL }

Results

The new SSL configuration is:

<repertoire xmi:id="SSLConfig_1" alias="DefaultSSLSettings" 
                                 managementScope="ManagementScope_1">

    <setting xmi:id="SecureSocketLayer_1" clientAuthentication="true" 
                                          securityLevel="HIGH" 
                                          enabledCiphers="" 
                                          jsseProvider="IBMJSSE2" 
                                          sslProtocol="SSL" 
                                          keyStore="KeyStore_1" 
                                          trustStore="KeyStore_2" 
                                          trustManager="TrustManager_1" 
                                          keyManager="KeyManager_1"/>

</repertoire>

The default management scope is used if it is not specified.

Related tasks:

Migrate administrative scripts

WASPostUpgrade command

WASPreUpgrade command

+

Search Tips   |   Advanced Search

Update SSL configurations to V9.0 configuration definitions after migration

When migrating to v9.0, we can update the format for SSL configuration or we can continue to use the format of the earlier version. If we encounter errors with our existing administration scripts for SSL configurations, use this task to manually convert our SSL configuration to the v9.0 format.

When migrating to v9.0, we can use the WASPreUpgrade command to save the configuration of our previously installed version into a migration-specific backup directory. When migration is complete, we can use the WASPostUpgrade command to retrieve the saved configuration and WASPostUpgrade script to migrate the previous configuration. The -scriptCompatibility parameter for the WASPostUpgrade command specifies whether to maintain the 6.1 or above configuration definitions or to upgrade the format to v9.0 configuration definitions. If we used the default value, or -scriptCompatibility true when migrating, we do not need to perform this task. If we set the scriptCompatibility parameter to false during migration, you may notice that our existing administration scripts for SSL configurations do not work correctly. If this occurs, use this task to convert our 6.1 or above SSL configuration definitions to v9.0 This process creates a new SSL configuration based on the existing configuration.

Follow the steps below to modify the existing SSL configuration:

<repertoire xmi:id="SSLConfig_1" alias="Node02/DefaultSSLSettings">

    <setting xmi:id="SecureSocketLayer_1" keyFileName="install_root/etc/MyServerKeyFile.jks"
                                          keyFilePassword="password" 
                                          keyFileFormat="JKS" 
                                          trustFileName="install_root/etc/MyServerTrustFile.jks"
                                          trustFilePassword="password" 
                                          trustFileFormat="JKS" 
                                          clientAuthentication="false" 
                                          securityLevel="HIGH" 
                                          enableCryptoHardwareSupport="false">
    
        <cryptoHardware xmi:id="CryptoHardwareToken_1" tokenType="" 
                                                       libraryFile="" 
                                                       password="{custom}"/>
    
        <properties xmi:id="Property_6" name="com.ibm.ssl.protocol" value="SSL"/>
        <properties xmi:id="Property_7" name="com.ibm.ssl.contextProvider" value="IBMJSSE2"/>

    </setting>

</repertoire>

Procedure

1. Create a key store that references the key store attributes in the old configuration.

   1. In the existing configuration, find the keyFileName, keyFilePassword, and keyFileFormat attributes.

      keyFileName="${install_root}/etc/MyServerKeyFile.jks" 
      keyFilePassword="password" 
      keyFileFormat="JKS"
      

   2. Use the keyFileName, keyFilePassword, and keyFileFormat attributes to create a new KeyStore object. For this example, set the name as "DefaultSSLSettings_KeyStore".

      Using Jacl:

      $AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_KeyStore -keyStoreLocation ${install_root}/etc/MyServerKeyFile.jks -keyStoreType JKS -keyStorePassword password -keyStorePasswordVerify password }
      depfeat

      The resulting configuration object in the security.xml file is:

      <keyStores xmi:id="KeyStore_1" name="DefaultSSLSettings_KeyStore" 
                                     password="password" 
                                     provider="IBMJCE" 
                                     location="install_root/etc/MyServerKeyFile.jks" 
                                     type="JKS" 
                                     fileBased="true" 
                                     managementScope="ManagementScope_1"/>
      

      If we specify the cryptoHardware values in the configuration, create the KeyStore object using these values instead. Associate the -keyStoreLocation parameter with the libraryFile attribute, the -keyStoreType parameter with the tokenType attribute, and the -keyStorePassword parameter with the password attribute.

      <cryptoHardware xmi:id="CryptoHardwareToken_1" 
                      tokenType="" 
                      libraryFile="" 
                      password=""/>
      

2. Create a trust store that references the trust store attributes from the existing configuration.

   1. Find the trustFileName, trustFilePassword, and trustFileFormat attributes in the existing configuration.

      trustFileName="install_root/etc/MyServerTrustFile.jks" 
      trustFilePassword="password" 
      trustFileFormat="JKS"
      

   2. Use the trustFileName, trustFilePassword, and trustFileFormat attributes to create a new KeyStore object. For this example, set the name as "DefaultSSLSettings_TrustStore".

      Using Jacl:

      $AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_TrustStore -keyStoreLocation install_root/etc/MyServerTrustFile.jks -keyStoreType JKS -keyStorePassword password -keyStorePasswordVerify password }

      The resulting configuration object in the security.xml file is:

      <keyStores xmi:id="KeyStore_2" name="DefaultSSLSettings_TrustStore" 
                                     password="password" 
                                     provider="IBMJCE" 
                                     location="install_root/etc/MyServerTrustFile.jks" 
                                     type="JKS" 
                                     fileBased="true" 
                                     managementScope="ManagementScope_1"/>
      

3. Create a new SSL configuration using the new key store and trust store.

   Include any other attributes from the existing configuration which are still valid. Use a new alias for your updated SSL configuration. We can not create an SSL configuration with the same name as our existing configuration.

   Using Jacl:

   $AdminTask createSSLConfig {-alias DefaultSSLSettings -trustStoreName DefaultSSLSettings_TrustStore -keyStoreName DefaultSSLSettings_KeyStore -keyManagerName IbmX509 -trustManagerName IbmX509 -clientAuthentication true -securityLevel HIGH -jsseProvider IBMJSSE2 -sslProtocol SSL }

Results

The new SSL configuration is:

<repertoire xmi:id="SSLConfig_1" alias="DefaultSSLSettings" 
                                 managementScope="ManagementScope_1">

    <setting xmi:id="SecureSocketLayer_1" clientAuthentication="true" 
                                          securityLevel="HIGH" 
                                          enabledCiphers="" 
                                          jsseProvider="IBMJSSE2" 
                                          sslProtocol="SSL" 
                                          keyStore="KeyStore_1" 
                                          trustStore="KeyStore_2" 
                                          trustManager="TrustManager_1" 
                                          keyManager="KeyManager_1"/>

</repertoire>

The default management scope is used if it is not specified.

Related tasks:

Migrate administrative scripts

WASPostUpgrade command

WASPreUpgrade command

+

Search Tips   |   Advanced Search

Update SSL configurations to V9.0 configuration definitions after migration

When migrating to v9.0, we can update the format for SSL configuration or we can continue to use the format of the earlier version. If we encounter errors with our existing administration scripts for SSL configurations, use this task to manually convert our SSL configuration to the v9.0 format.

When migrating to v9.0, we can use the WASPreUpgrade command to save the configuration of our previously installed version into a migration-specific backup directory. When migration is complete, we can use the WASPostUpgrade command to retrieve the saved configuration and WASPostUpgrade script to migrate the previous configuration. The -scriptCompatibility parameter for the WASPostUpgrade command specifies whether to maintain the 6.1 or above configuration definitions or to upgrade the format to v9.0 configuration definitions. If we used the default value, or -scriptCompatibility true when migrating, we do not need to perform this task. If we set the scriptCompatibility parameter to false during migration, you may notice that our existing administration scripts for SSL configurations do not work correctly. If this occurs, use this task to convert our 6.1 or above SSL configuration definitions to v9.0 This process creates a new SSL configuration based on the existing configuration.

Follow the steps below to modify the existing SSL configuration:

<repertoire xmi:id="SSLConfig_1" alias="Node02/DefaultSSLSettings">

    <setting xmi:id="SecureSocketLayer_1" keyFileName="install_root/etc/MyServerKeyFile.jks"
                                          keyFilePassword="password" 
                                          keyFileFormat="JKS" 
                                          trustFileName="install_root/etc/MyServerTrustFile.jks"
                                          trustFilePassword="password" 
                                          trustFileFormat="JKS" 
                                          clientAuthentication="false" 
                                          securityLevel="HIGH" 
                                          enableCryptoHardwareSupport="false">
    
        <cryptoHardware xmi:id="CryptoHardwareToken_1" tokenType="" 
                                                       libraryFile="" 
                                                       password="{custom}"/>
    
        <properties xmi:id="Property_6" name="com.ibm.ssl.protocol" value="SSL"/>
        <properties xmi:id="Property_7" name="com.ibm.ssl.contextProvider" value="IBMJSSE2"/>

    </setting>

</repertoire>

Procedure

1. Create a key store that references the key store attributes in the old configuration.

   1. In the existing configuration, find the keyFileName, keyFilePassword, and keyFileFormat attributes.

      keyFileName="${install_root}/etc/MyServerKeyFile.jks" 
      keyFilePassword="password" 
      keyFileFormat="JKS"
      

   2. Use the keyFileName, keyFilePassword, and keyFileFormat attributes to create a new KeyStore object. For this example, set the name as "DefaultSSLSettings_KeyStore".

      Using Jacl:

      $AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_KeyStore -keyStoreLocation ${install_root}/etc/MyServerKeyFile.jks -keyStoreType JKS -keyStorePassword password -keyStorePasswordVerify password }
      depfeat

      The resulting configuration object in the security.xml file is:

      <keyStores xmi:id="KeyStore_1" name="DefaultSSLSettings_KeyStore" 
                                     password="password" 
                                     provider="IBMJCE" 
                                     location="install_root/etc/MyServerKeyFile.jks" 
                                     type="JKS" 
                                     fileBased="true" 
                                     managementScope="ManagementScope_1"/>
      

      If we specify the cryptoHardware values in the configuration, create the KeyStore object using these values instead. Associate the -keyStoreLocation parameter with the libraryFile attribute, the -keyStoreType parameter with the tokenType attribute, and the -keyStorePassword parameter with the password attribute.

      <cryptoHardware xmi:id="CryptoHardwareToken_1" 
                      tokenType="" 
                      libraryFile="" 
                      password=""/>
      

2. Create a trust store that references the trust store attributes from the existing configuration.

   1. Find the trustFileName, trustFilePassword, and trustFileFormat attributes in the existing configuration.

      trustFileName="install_root/etc/MyServerTrustFile.jks" 
      trustFilePassword="password" 
      trustFileFormat="JKS"
      

   2. Use the trustFileName, trustFilePassword, and trustFileFormat attributes to create a new KeyStore object. For this example, set the name as "DefaultSSLSettings_TrustStore".

      Using Jacl:

      $AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_TrustStore -keyStoreLocation install_root/etc/MyServerTrustFile.jks -keyStoreType JKS -keyStorePassword password -keyStorePasswordVerify password }

      The resulting configuration object in the security.xml file is:

      <keyStores xmi:id="KeyStore_2" name="DefaultSSLSettings_TrustStore" 
                                     password="password" 
                                     provider="IBMJCE" 
                                     location="install_root/etc/MyServerTrustFile.jks" 
                                     type="JKS" 
                                     fileBased="true" 
                                     managementScope="ManagementScope_1"/>
      

3. Create a new SSL configuration using the new key store and trust store.

   Include any other attributes from the existing configuration which are still valid. Use a new alias for your updated SSL configuration. We can not create an SSL configuration with the same name as our existing configuration.

   Using Jacl:

   $AdminTask createSSLConfig {-alias DefaultSSLSettings -trustStoreName DefaultSSLSettings_TrustStore -keyStoreName DefaultSSLSettings_KeyStore -keyManagerName IbmX509 -trustManagerName IbmX509 -clientAuthentication true -securityLevel HIGH -jsseProvider IBMJSSE2 -sslProtocol SSL }

Results

The new SSL configuration is:

<repertoire xmi:id="SSLConfig_1" alias="DefaultSSLSettings" 
                                 managementScope="ManagementScope_1">

    <setting xmi:id="SecureSocketLayer_1" clientAuthentication="true" 
                                          securityLevel="HIGH" 
                                          enabledCiphers="" 
                                          jsseProvider="IBMJSSE2" 
                                          sslProtocol="SSL" 
                                          keyStore="KeyStore_1" 
                                          trustStore="KeyStore_2" 
                                          trustManager="TrustManager_1" 
                                          keyManager="KeyManager_1"/>

</repertoire>

The default management scope is used if it is not specified.

Related tasks:

Migrate administrative scripts

WASPostUpgrade command

WASPreUpgrade command

+

Search Tips   |   Advanced Search

Update SSL configurations to V9.0 configuration definitions after migration

When migrating to v9.0, we can update the format for SSL configuration or we can continue to use the format of the earlier version. If we encounter errors with our existing administration scripts for SSL configurations, use this task to manually convert our SSL configuration to the v9.0 format.

When migrating to v9.0, we can use the WASPreUpgrade command to save the configuration of our previously installed version into a migration-specific backup directory. When migration is complete, we can use the WASPostUpgrade command to retrieve the saved configuration and WASPostUpgrade script to migrate the previous configuration. The -scriptCompatibility parameter for the WASPostUpgrade command specifies whether to maintain the 6.1 or above configuration definitions or to upgrade the format to v9.0 configuration definitions. If we used the default value, or -scriptCompatibility true when migrating, we do not need to perform this task. If we set the scriptCompatibility parameter to false during migration, you may notice that our existing administration scripts for SSL configurations do not work correctly. If this occurs, use this task to convert our 6.1 or above SSL configuration definitions to v9.0 This process creates a new SSL configuration based on the existing configuration.

Follow the steps below to modify the existing SSL configuration:

<repertoire xmi:id="SSLConfig_1" alias="Node02/DefaultSSLSettings">

    <setting xmi:id="SecureSocketLayer_1" keyFileName="install_root/etc/MyServerKeyFile.jks"
                                          keyFilePassword="password" 
                                          keyFileFormat="JKS" 
                                          trustFileName="install_root/etc/MyServerTrustFile.jks"
                                          trustFilePassword="password" 
                                          trustFileFormat="JKS" 
                                          clientAuthentication="false" 
                                          securityLevel="HIGH" 
                                          enableCryptoHardwareSupport="false">
    
        <cryptoHardware xmi:id="CryptoHardwareToken_1" tokenType="" 
                                                       libraryFile="" 
                                                       password="{custom}"/>
    
        <properties xmi:id="Property_6" name="com.ibm.ssl.protocol" value="SSL"/>
        <properties xmi:id="Property_7" name="com.ibm.ssl.contextProvider" value="IBMJSSE2"/>

    </setting>

</repertoire>

Procedure

1. Create a key store that references the key store attributes in the old configuration.

   1. In the existing configuration, find the keyFileName, keyFilePassword, and keyFileFormat attributes.

      keyFileName="${install_root}/etc/MyServerKeyFile.jks" 
      keyFilePassword="password" 
      keyFileFormat="JKS"
      

   2. Use the keyFileName, keyFilePassword, and keyFileFormat attributes to create a new KeyStore object. For this example, set the name as "DefaultSSLSettings_KeyStore".

      Using Jacl:

      $AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_KeyStore -keyStoreLocation ${install_root}/etc/MyServerKeyFile.jks -keyStoreType JKS -keyStorePassword password -keyStorePasswordVerify password }
      depfeat

      The resulting configuration object in the security.xml file is:

      <keyStores xmi:id="KeyStore_1" name="DefaultSSLSettings_KeyStore" 
                                     password="password" 
                                     provider="IBMJCE" 
                                     location="install_root/etc/MyServerKeyFile.jks" 
                                     type="JKS" 
                                     fileBased="true" 
                                     managementScope="ManagementScope_1"/>
      

      If we specify the cryptoHardware values in the configuration, create the KeyStore object using these values instead. Associate the -keyStoreLocation parameter with the libraryFile attribute, the -keyStoreType parameter with the tokenType attribute, and the -keyStorePassword parameter with the password attribute.

      <cryptoHardware xmi:id="CryptoHardwareToken_1" 
                      tokenType="" 
                      libraryFile="" 
                      password=""/>
      

2. Create a trust store that references the trust store attributes from the existing configuration.

   1. Find the trustFileName, trustFilePassword, and trustFileFormat attributes in the existing configuration.

      trustFileName="install_root/etc/MyServerTrustFile.jks" 
      trustFilePassword="password" 
      trustFileFormat="JKS"
      

   2. Use the trustFileName, trustFilePassword, and trustFileFormat attributes to create a new KeyStore object. For this example, set the name as "DefaultSSLSettings_TrustStore".

      Using Jacl:

      $AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_TrustStore -keyStoreLocation install_root/etc/MyServerTrustFile.jks -keyStoreType JKS -keyStorePassword password -keyStorePasswordVerify password }

      The resulting configuration object in the security.xml file is:

      <keyStores xmi:id="KeyStore_2" name="DefaultSSLSettings_TrustStore" 
                                     password="password" 
                                     provider="IBMJCE" 
                                     location="install_root/etc/MyServerTrustFile.jks" 
                                     type="JKS" 
                                     fileBased="true" 
                                     managementScope="ManagementScope_1"/>
      

3. Create a new SSL configuration using the new key store and trust store.

   Include any other attributes from the existing configuration which are still valid. Use a new alias for your updated SSL configuration. We can not create an SSL configuration with the same name as our existing configuration.

   Using Jacl:

   $AdminTask createSSLConfig {-alias DefaultSSLSettings -trustStoreName DefaultSSLSettings_TrustStore -keyStoreName DefaultSSLSettings_KeyStore -keyManagerName IbmX509 -trustManagerName IbmX509 -clientAuthentication true -securityLevel HIGH -jsseProvider IBMJSSE2 -sslProtocol SSL }

Results

The new SSL configuration is:

<repertoire xmi:id="SSLConfig_1" alias="DefaultSSLSettings" 
                                 managementScope="ManagementScope_1">

    <setting xmi:id="SecureSocketLayer_1" clientAuthentication="true" 
                                          securityLevel="HIGH" 
                                          enabledCiphers="" 
                                          jsseProvider="IBMJSSE2" 
                                          sslProtocol="SSL" 
                                          keyStore="KeyStore_1" 
                                          trustStore="KeyStore_2" 
                                          trustManager="TrustManager_1" 
                                          keyManager="KeyManager_1"/>

</repertoire>

The default management scope is used if it is not specified.

Related tasks:

Migrate administrative scripts

WASPostUpgrade command

WASPreUpgrade command