This chapter describes how to configure Node Manager according to the Enterprise Deployment recommendations.
This chapter includes the following topics:
Node Manager enables you to start and stop the Administration Server and the Managed Servers.
Oracle 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 are required for WCPHOST1 and WCPHOST2. Although the appropriate host name changes in the steps are required for WCPHOST1 and WCPHOST2, the procedure and syntax are exactly the same.
Oracle recommends placing your Oracle Fusion Middleware deployment's Node Manager's log in a different location from the default (which is inside MW_Home where Node Manager is located).
To change the location of the Node Manager log, edit the nodemanager.properties file located in the following directory:
MW_HOME/wlserver_10.3/common/nodemanager
Oracle recommends locating this file outside of the MW_HOME directory, and inside the admin directory for the deployment.
Add the following line to nodemanager.properties:
LogFile=ORACLE_BASE/admin/nodemanager.log
Restart Node Manager for the change to take effect.
Host name verification enables communication between Node Manager and the Administration Server. This verification requires the use of certificates for the different addresses communicating with the Administration Server.
This section contains the following topics:
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
This section describes the procedure for creating self-signed certificates on SOAHOST1.example.com. Create these certificates using the network name/alias.
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 or shared stores for the certificates used for different purposes (for example, SSL setup for HTTP invocations). In this case, SOAHOST2, WCPHOST1, and WCPHOST2 use the certs directory created for SOAHOST1 certificates.
For information on using trust CA certificates instead, see "Configuring Identity and Trust" in Oracle Fusion Middleware Securing Oracle WebLogic Server.
The passwords 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.
To create self-signed certificates:
Set up your environment by running the WL_HOME/server/bin/setWLSEnv.sh script:
In the Bourne shell, run the following command on SOAHOST1:
.WL_HOME/server/bin/setWLSEnv.sh
Verify that the CLASSPATH environment variable is set:
echo $CLASSPATH
Create a user-defined directory for the certificates:
mkdir ORACLE_BASE/admin/domain-name/certs
Change directory to the user-defined directory:
cd ORACLE_BASE/admin/domain-name/certs
Run the utils.CertGen tool from the user-defined directory to create the certificates for SOAHOST1, SOAHOST1VHN VIP, the Administration Server VIP, WCPHOST1, and all hosts and VIPS in the environment.
Syntax:
java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [host_name]
Example commands:
java utils.CertGen password SOAHOST1.example.com_cert SOAHOST1.example.com_key domestic SOAHOST1.example.com java utils.CertGen password SOAHOST1VHN1.example.com_cert SOAHOST1VHN1.example.com_key domestic SOAHOST1VHN1.example.com java utils.CertGen password SOAHOST2.example.com_cert SOAHOST2.example.com_key domestic SOAHOST2.example.com java utils.CertGen password SOAHOST2VHN1.example.com_cert SOAHOST1VHN2.example.com_key domestic SOAHOST1VHN2.example.com java utils.CertGen password ADMINVHN.example.com_cert ADMINVHN.example.com_key domestic ADMINVHN.example.com java utils.CertGen password WCPHOST1.example.com_cert WCPHOST1.example.com_key domestic WCPHOST1.example.com java utils.CertGen password WCPHOST2.example.com_cert WCPHOST2.example.com_key domestic WCPHOST2.example.com
The procedures described in the previous sections created an identity keystore. Import the certificate and private key for SOAHOST1, SOAHOST1VHN1, ADMINVHN and WCPHOST1 into the Identity Store. Make sure you use a different alias for each of the certificate/key pairs imported.
Follow these steps to create an identity keystore on SOAHOST1:
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/certs).
Note:
The identity store is created (if none exists) when you import a certificate and the corresponding key into the identity store using the utils.ImportPrivateKey utility.Import the certificate and private key for SOAHOST1, SOAHOST1VHN1, SOAHOST2, SOAHOST2VHN1, ADMINVHN, WCPHOST1, and WCPHOST2 into the identity store. Make sure that you use a different alias for each of the certificate/key pairs imported.
Syntax (all on a single line):
java utils.ImportPrivateKey Keystore_File Keystore_Password Certificate_Alias_to_Use Private_Key_Passphrase Certificate_File Private_Key_File [Keystore_Type]
Examples:
java utils.ImportPrivateKey appIdentityKeyStore.jks password appidentitySOAHOST1 password ORACLE_BASE/admin/domain_name/certs/SOAHOST1.example.com_cert.pem ORACLE_BASE/admin/domain_name/certs/SOAHOST1.example.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks password appidentitySOAHOST1VHN1 password ORACLE_BASE/admin/domain_name/certs/SOAHOST1VHN1.example.com_cert.pem ORACLE_BASE/admin/domain_name/certs/SOAHOST1VHN1.example.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks password appidentitySOAHOST2 password ORACLE_BASE/admin/domain_name/certs/SOAHOST2.example.com_cert.pem ORACLE_BASE/admin/domain_name/certs/SOAHOST2.example.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks password appidentitySOAHOST2VHN1 password ORACLE_BASE/admin/domain_name/certs/SOAHOST2VHN1.example.com_cert.pem ORACLE_BASE/admin/domain_name/certs/SOAHOST2VHN1.example.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks password appidentityADMINVHN password ORACLE_BASE/admin/domain_name/certs/ADMINVHN.example.com_cert.pem ORACLE_BASE/admin/domain_name/certs/ADMINVHN.example.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks password appidentityWCPHOST1 password ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_cert.pem ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks password appidentityWCPHOST1 password ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_cert.pem ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_key.pem
Use keytool to list the new aliases in the keystore; for example:
keytool -list -keystore ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks -storepass password
To create the Trust Keystore on SOAHOST1.example.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 keystore 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/certs/appTrustKeyStore.jks
The default password for the standard Java keystore is changeit. Oracle recommends always changing the default password. Use the keytool utility on HOST to do this. The syntax follows:
keytool -storepass -new NewPassword -keystore TrustKeyStore -storepass Original_Password
For example:
keytool -storepass -new password -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 appTrustKeyStore using the keytool utility on HOST. The syntax follows:
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 password
Replicate the keystores to the SOAHOST2, WCPHOST1, and WCPHOST2 servers:
On SOAHOST2, create a user-defined directory for the certificates:
mkdir ORACLE_BASE/admin/domain_name/certs
Copy the keystores from SOAHOST1 to SOAHOST2:
scp SOAHOST1:/ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks \ /ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks scp SOAHOST1:/ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks \ /ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks
Repeat steps a and b for WCPHOST1 and WCPHOST2.
To configure 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; that is, the custom identity alias specifically assigned to that node. For example, on SOAHOST1 use appIdentitySOAHOST1 according to the steps in Section 11.3.3, "Creating a Trust Keystore Using the Keytool Utility":
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=password CustomIdentityAlias=appIdentitySOAHOST1 CustomIdentityPrivateKeyPassPhrase=password
The passphrase entries in the nodemanager.properties file are encrypted when you start Node Manager, as described in Section 11.4, "Starting Node Manager." For security reasons, minimize the time the entries in the nodemanager.properties file are left unencrypted. After you edit the file, start Node Manager as soon as possible so that the entries are encrypted.
When using a common or shared storage installation for MW_HOME, Node Manager is started from different nodes using the same base configuration (nodemanager.properties). Add the certificate for all the nodes that share the binaries to the appIdentityKeyStore.jks identity store by creating the certificate for the new node and import it to appIdentityKeyStore.jks as described in Section 11.3.1, "Generating Self-Signed Certificates Using the utils.CertGen Utility." Once the certificates are available in the store, each Node Manager instance must point to a different identity alias to send the correct certificate to the Administration Server.
The following examples show how to set different environment variables before starting Node Manager in different nodes:
SOAHOST1> cd WL_HOME/server/bin SOAHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1 SOAHOST2> cd WL_HOME/server/bin SOAHOST2> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST2 WCPHOST1> cd WL_HOME/server/bin WCPHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityWCPHOST1 WCPHOST2> cd WL_HOME/server/bin WCPHOST2> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityWCPHOST2
Start Node Manager on SOAHOST1, SOAHOST2, WCPHOST1, and WCPHOST2 using the startNodeManager.sh script.
Note:
If you have not configured and started Node Manager yet, run thesetNMProps.sh script as specified in section Section 8.4.2, "Starting Node Manager on SOAHOST1." This enables the use of the start script which is required for SOA.To start Node Manager on SOAHOST1:
cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1
./startNodeManager.sh
Note:
Ensure that you specify the custom identity alias specifically assigned to each host,appIdentitySOAHOST11 for SOAHOST1 and appIdentitySOAHOST2 for SOAHOST2, and so on.Follow the same step to start Node Manager on SOAHOST2, WCPHOST1, and WCPHOST2.
Configure the WebLogic Servers to use the custom keystores using the Oracle WebLogic Server Administration Console. Complete this procedure for the Administration Server, and all the Managed Servers (WLS_WSMn, WLS_SOAn, WC_Spacesn, WC_Collaborationn, WC_Utilitiesn, and WC_Portletn).
This example follows the recommended directory structure and keystore locations provided in Section 11.3, "Enabling Host Name Verification Certificates for Node Manager."
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.
Click the Change button next to the Keystores field, and then 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/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 11.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/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 11.3.3, "Creating a Trust Keystore Using the Keytool Utility."
As mentioned in the previous step, this attribute may be optional or required depending on the type of keystore.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Click Lock & Edit.
Select Configuration, then SSL.
In the Private Key Alias field, enter the alias you used for the host name the Managed Server listens on.
In the Private Key Passphrase and the Confirm Private Key Passphrase fields, enter the password for the keystore that you created in Section 11.3.3, "Creating a Trust Keystore Using the Keytool Utility."
Click Save.
Click Activate Changes in the Administration Console's Change Center to make the changes take effect.
Restart the server for which the changes have been applied.
Repeat these steps for the Administration Server, and all the Managed Servers (WLS_WSMn, WLS_SOAn, WC_Spacesn, WC_Collaborationn, WC_Utilitiesn, and WC_Portletn).
Verify that the communication between Node Manager, Administration Server and the Managed Servers is correct by enabling hostname verification:
For each server, in the Administration Console, select Configuration, SSL, Advanced, Hostname Verification, and then BEA HostName Verifier.
Restart the servers using the Administration Console.