This chapter describes how to configure Node Manager per the EDG recommendations. Oracle Fusion Middleware EDG recommends using host name verification for the communications between Node Manager and the Administration Server. This requires the use of certificates for the different addresses communicating with the Administration Server. In this chapter, the steps for configuring SOAHOST1 and SOAHOST2 certificates for host name verification are provided. Similar steps would be required for BAMHOST1 and BAMHOST2 in a BAM EDG topology. Although the appropriate hos tname changes in the steps are required for BAM, the procedure and syntax are exactly the same.
Oracle also recommends placing your Oracle Fusion Middleware deployment's NodeManager's log in a different location from the default (which is inside the MW_Home where Node Manager is located). See Section 8.2, "Changing the Location of Node Manager Log" for details.
This chapter includes the following sections:
Section 8.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1"
Section 8.5, "Enabling Host Name Verification Certificates for the Node Manager in SOAHOST2"
Section 8.7, "Configuring WebLogic Servers to Use the Custom Keystores"
The Node Manager enables you to start and stop the Administration Server and the managed servers.
The passwords used in this guide are used only as examples. Use secure passwords in a production environment. For example, use passwords that include both uppercase and lowercase characters as well as numbers.
Edit the nodemanager.properties file located in the MW_HOME/wlserver_10.3/common/nodemanager directory. Add the new location for the LogFile. Oracle recommends locating this file out of the MW_HOME directory, and inside the admin directory for the deployment using the following command:
LogFile=ORACLE_BASE/admin/nodemanager.log
Restart Node Manager for the change to take effect.
Perform these steps to set up host name verification certificates for communication between the Node Manager and the Administration Server.
Step 1: Generating Self-Signed Certificates Using the utils.CertGen Utility
Step 2: Creating an Identity Keystore Using the utils.ImportPrivateKey Utility
Step 4: Configuring Node Manager to Use the Custom Keystores
Follow these steps to create self-signed certificates on SOAHOST1.mycompany.com. These certificates should be created using the network name/alias. When a server is using a virtual hostname it is implied that the server can be migrated from one node to another. Consequently, the directory where keystores and trust keystores are maintained ideally must be located on a shared storage that is accessible from the failover node. For information on using trust CA certificates instead, see "Configuring Identity and Trust" in Oracle Fusion Middleware Securing Oracle WebLogic Server.
Set up your environment by running the WL_HOME/server/bin/setWLSEnv.sh script:
In the Bourne shell, run the following command:
SOAHOST1> . setWLSEnv.sh
Verify that the CLASSPATH environment variable is set:
SOAHOST1> echo $CLASSPATH
Create a user-defined directory for the certificates. For example, create a directory called certs under the ORACLE_BASE/admin/<domain_name>/aserver/<domain_name> directory. Note that certificates can be shared across WLS domains.
SOAHOST1> cd ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/ SOAHOST1> mkdir certs
Note:
The directory where keystores and trust keystores are maintained must be on shared storage that is accessible from all nodes so that when the servers fail over (manually or with server migration), the appropriate certificates can be accessed from the failover node.Oracle recommends using central/shared stores for the certificates used for different purposes, for example, an SSL set up for HTTP invocations.
Change directory to the user-defined directory.
SOAHOST1> cd certs
Run the utils.CertGen tool from the user-defined directory to create the certificates for both SOAHOST1 and ADMINVHN.
Syntax:
java utils.CertGen <key_passphrase> <cert_file_name> <key_file_name> [export | domestic] [hostname]
Examples:
SOAHOST1> java utils.CertGen welcome1 SOAHOST1_cert SOAHOST1_key
domestic SOAHOST1.mycompany.com
SOAHOST1> java utils.CertGen welcome1 SOAHOST1VHN1_cert SOAHOST1VHN1_key
domestic SOAHOST1VHN1.mycompany.com
SOAHOST1> java utils.CertGen welcome1 ADMINVHN_cert ADMINVHN_key
domestic ADMINVHN.mycompany.com
Follow these steps to create an Identity Keystore on SOAHOST1.mycompany.com.
Create a new identity keystore called appIdentityKeyStore using the utils.ImportPrivateKey utility.
Create this keystore under the same directory as the certificates (that is, ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/certs.
Note:
The Identity Store is created (if none exists) when you import a certificate and the corresponding key into the Identity Store using theutils.ImportPrivateKey utility.Import the certificate and private key for both SOAHOST1 and VIPHOST1 into the Identity Store. Make sure that you use a different alias for each of the certificate/key pair imported.
Syntax:
java utils.ImportPrivateKey <keystore_file> <keystore_password> <certificate_alias_to_use> <private_key_passphrase> <certificate_file> <private_key_file> [<keystore_type>]
Examples:
SOAHOST1> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity1 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST1_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST1_key.pem
SOAHOST1> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity2 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST1VHN1_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST1VHN1_key.pem
SOAHOST1> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity3 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/ADMINVHN_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/ADMINVHN_key.pem
Follow these steps to create the Trust Keystore on SOAHOST1.mycompany.com.
Copy the standard java keystore to create the new trust keystore since it already contains most of the root CA certificates needed. Oracle does not recommend modifying the standard Java trust key store directly. Copy the standard Java keystore CA certificates located under the WL_HOME/server/lib directory to the same directory as the certificates. For example:
cp WL_HOME/server/lib/cacerts ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/certs/appTrustKeyStore.jks
The default password for the standard Java keystore is changeit. Oracle recommends always changing the default password. Use the keytool utility to do this. The syntax is:
keytool -storepasswd -new <NewPassword> -keystore <TrustKeyStore> -storepass <Original Password>
For example:
keytool -storepasswd -new welcome1 -keystore appTrustKeyStore.jks -storepass changeit
The CA certificate CertGenCA.der is used to sign all certificates generated by the utils.CertGen tool and is located at WL_HOME/server/lib directory. This CA certificate must be imported into the appTrustKeyStore using the keytool utility. The syntax is:
keytool -import -v -noprompt -trustcacerts -alias <AliasName> -file <CAFileLocation> -keystore <KeyStoreLocation> -storepass <KeyStore Password>
For example:
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file $WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass welcome1
To configure the Node Manager to use the custom keystores, add the following lines to the end of the nodemanager.properties file located in the WL_HOME/common/nodemanager directory:
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=<Identity KeyStore> CustomIdentityKeyStorePassPhrase=<Identity KeyStore Passwd> CustomIdentityAlias=<Identity Key Store Alias> CustomIdentityPrivateKeyPassPhrase=<Private Key used when creating Certificate> Make sure to use the correct value for CustomIdentityAlias for Node Manager listen's addres. For example on SOAHOST1, use appIdentity1 as per the above steps (appIdentity1 mapped to the SOAHOST1 listen address). Example for Node 1: KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/certs/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=welcome1 CustomIdentityAlias=appIdentity1 CustomIdentityPrivateKeyPassPhrase=welcome1
The passphrase entries in the nodemanager.properties file get encrypted when you start Node Manager as described in Section 8.4, "Starting the Node Manager on SOAHOST1." For security reasons, you want to minimize the time the entries in the nodemanager.properties file are left unencrypted. After you edit the file, you should start Node Manager as soon as possible so that the entries get encrypted.
When using a common/shared storage installation for MW_HOME, Node Manager is started from different nodes using the same base configuration (nodemanager.properties). In that case, it is required to add the certificate for all the nodes that share the binaries to the appIdentityKeyStore.jks identity store. To do this, create the certificate for the new node and import it to appIdentityKeyStore.jks as described above. Once the certificates are available in the store, each node manager needs to point to a different identity alias to send the correct certificate to the Administration Server. To do this, set different environment variables before starting Node Manager in the different nodes:
SOAHOST1>cd WL_HOME/server/bin SOAHOST1>export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1 SOAHOSTn>cd WL_HOME/server/bin SOAHOSTn>export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOSTn
Run these commands to start Node Manager on SOAHOST1:
Note:
If you have not configured and started Node Manager for the first time yet, run the setNMProps.sh script as specified in section Section 4.6, "Starting Node Manager on SOAHOST1." This will enable the use of the start script which is required for SOA and/or BAM.SOAHOST1> cd WL_HOME/server/bin SOAHOST1> ./startNodeManager.sh
Perform these steps to set up SSL for communication between the Node Manager and the Administration Server:
Step 1: Generating Self-Signed Certificates Using the utils.CertGen Utility
Step 2: Importing Identities in SOAHOST2 using the "utils.ImportPrivateKey" Utility
Step 4: Configuring Node Manager to Use the Custom Keystores
Follow these steps to create self-signed certificates on SOAHOST2.mycompany.com. These certificates should be created using the network name/alias.
Set up your environment by running the WL_HOME/server/bin/setWLSEnv.sh script:
In the Bourne shell, run the following command:
SOAHOST2> . setWLSEnv.sh
Verify that the CLASSPATH environment variable is set:
SOAHOST2> echo $CLASSPATH
The directory where keystores and trust keystores are maintained must be on shared storage that is accessible from all nodes so that when the Administration Server or SOA servers fail over, (manually or with server migration), the appropriate certificates can be accessed. In this case, SOAHOST2 uses the cert directory created for SOAHOST1 certificates. If you are maintaining duplicated stores, create user-defined directory for the certificates.
SOAHOST2> mkdir certs
Change directory to the user-defined directory.
SOAHOST2> cd certs
Run the utils.CertGen tool from the user-defined directory to create the certificates for both SOAHOST2 and VIPHOST1.
Syntax:
java utils.CertGen <key_passphrase> <cert_file_name> <key_file_name> [export | domestic] [hostname]
Examples:
SOAHOST2> java utils.CertGen welcome1 SOAHOST2_cert SOAHOST2_key
domestic SOAHOST2.mycompany.com
SOAHOST2> java utils.CertGen welcome1 SOAHOST2VHN1_cert SOAHOST2VHN1_key
domestic SOAHOST2VHN1.mycompany.com
Follow these steps to create an Identity Keystore on SOAHOST2.mycompany.com.
The procedures described in the previous sections created an Identity keystore that resides in a shared storage. In this section new keys for SOAHOST2 are added to the store. Import the certificate and private key for both SOAHOST2 and SOAHOST2VHN1 into the Identity Store. Make sure you use a different alias for each of the certificate/key pairs imported.
Syntax:
java utils.ImportPrivateKey <keystore_file> <keystore_password> <certificate_alias_to_use> <private_key_passphrase> <certificate_file> <private_key_file> [<keystore_type>]
Examples:
SOAHOST2> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity3 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2_key.pem
SOAHOST2> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity4 welcome1
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2VHN1_cert.pem
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/SOAHOST2VHN1_key.pem
Follow these steps to configure the Node Manager to use the custom keystores.
Add the following lines to the end of the nodemanager.properties file located in the WL_HOME/common/nodemanager directory.
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=<Identity KeyStore>
CustomIdentityKeyStorePassPhrase=<Identity KeyStore Passwd>
CustomIdentityAlias=<Identity Key Store Alias>
CustomIdentityPrivateKeyPassPhrase=<Private Key used when creating Certificate>
Make sure to use the correct value for CustomIdentityAlias on each node. For example, on SOAHOST2, use "appIdentity3".
Example for Node 2:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityAlias=appIdentity3
CustomIdentityPrivateKeyPassPhrase=welcome1
Note:
The passphrase entries in thenodemanager.properties file get encrypted when you start Node Manager, as described in Section 8.6, "Starting the Node Manager on SOAHOST2."
For security reasons, you want to minimize the time the entries in the nodemanager.properties file are left unencrypted. After you edit the file, you should start Node Manager as soon as possible so that the entries get encrypted.
Run these commands to start Node Manager on SOAHOST2:
Note:
If you have not configured and started Node Manager for the first time yet, run the setNMProps.sh script as specified in section Section 4.15, "Starting Node Manager on SOAHOST2." This will enable the use of the start script which is required for SOA and/or BAM.
SOAHOST2> cd WL_HOME/server/bin
SOAHOST2> ./startNodeManager.sh
To configure the identity and trust keystores:
Log in to the Administration Console, and click Lock & Edit.
In the left pane, expand Environment, and select Servers.
Click the name of the server for which you want to configure the identity and trust keystores.
Select Configuration, and then Keystores.
In the Keystores field, select the "Custom Identity and Custom Trust" method for storing and managing private keys/digital certificate pairs and trusted CA certificates.
In the Identity section, define attributes for the identity keystore.
Custom Identity Keystore: Enter the fully qualified path to the identity keystore:
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
Custom Identity Keystore Type: Leave this field blank, it defaults to JKS.
Custom Identity Keystore Passphrase: Enter the password Keystore_Password you provided in Section 8.3.2, "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility."
This attribute may be optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server reads only from the keystore, so whether or not you define this property depends on the requirements of the keystore.
In the Trust section, define properties for the trust keystore:
Custom Trust Keystore: Enter the fully qualified path to the trust keystore:
ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appTrustKeyStore.jks
Custom Trust Keystore Type: Leave this field blank, it defaults to JKS.
Custom Trust Keystore Passphrase: The password you provided in as New_Password in Section 8.3.3, "Creating a Trust Keystore Using the Keytool Utility."
This attribute may be optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server reads only from the keystore, so whether or not you define this property depends on the requirements of the keystore.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Execute these steps for the Administration Server, the WLS_WSMn and the WLS_SOAn servers.