This appendix covers several aspects related to Application Configuration Console security.
In keeping with Oracle's mandate to protect customer data, Application Configuration Console observes the following best practices:
Uses the AES (Advanced Encryption Standard) encryption algorithm, with an encryption key size of 128 bits and an encryption mode of CBC (cipher-block chaining).
Imposes 0750 permission on SERVER_INSTALL/appserver/tomcat/logs
Imposes 600 permission on SERVER_INSTALL/appserver/tomcat/conf/Catalina/localhost/*.xml
Imposes 600 permission on SERVER_INSTALL/appserver/tomcat/conf/server.xml
Imposes 600 permission on the following files in SERVER_INSTALL/appserver/tomcat/shared/classes/
java.login.config
mvstore
server_modules_registry.xml
Application Configuration Console stores passwords for keystore and truststore in obfuscated format on the Server:
SERVER_INSTALL/appserver/tomcat/conf/server.xml
And on the Client:
CLIENT_INSTALL/client/runtime/plugins/com.mvalent.integrity_5.3.2/config/client_boot.xml
If you suspect that these files or the keystore have been compromised in any way, contact Oracle support for assistance in changing passwords.
To ensure a secure connection, the Core Server and the Client use the SSL protocol to exchange sensitive information contained in files known as a keystore and a truststore. A keystore contains private keys, and the certificates with their corresponding public keys. A truststore contains certificates from other parties that you expect to communicate with, or from Certificate Authorities that you trust to identify other parties. To learn more about the Java SSL protocol and keystores and truststores, visit the following URL:
http://java.sun.com/docs/books/tutorial/security/sigcert/index.htm
The Core Server generates a self-signed certificate during installation. The keystore files (keystore and truststore) are generated the first time the Client connects to the Server. If something happens to the Client's keystore files (modified or deleted, for example), they are regenerated on the next startup, when you are prompted to accept the certificate. If something happens to the Server's keystore files, however, or if tampering is suspected, then it becomes necessary to generate new keystore files to continue secure operations.
Back up either or both original files if they exist (mvserver.ks
and mvserver.ts
), located in the following directory:
$OACC_INSTALL/com.mvalent.integrity_5.3.2/webserver/tomcat
You will use the keytool
utility that comes with any JDK 1.6 installation to regenerate your keystore files. This utility displays passwords in cleartext so be sure to take the necessary security precautions. Also, you may want to record the values that you supply, such as passwords and paths, as you will need to provide them several times during the process. To learn more about keytool
visit the following URL:
http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html
To generate a new keystore file, proceed as follows:
Open a command shell prompt.
Change directory to the JDK1.6_HOME/bin
directory; to here, for example, if you elected to use the version embedded with the Core Server installation:
$OACC_INSTALL/java/bin
Execute the keystool
command as follows:
keytool -genkey -alias alias_value -keyalg RSA -keysize 1024 -storepass password -keypass password -keystore store_path -storetype jks -dname dname_values
Where:
alias_value is the identifier of the original key created during keystore creation. This value can be any string.
password is a strong password for accessing the keystore file. Tomcat requires that you specify the same value to access the keystore and its private key.
store_path is the path of the keystore file that you are generating.
dbname_values are optional values that identify the owner of the credentials passed from the Server to any Client. For example: "CN=Application Configuration Console Server, OU=Enterprise Manager Grid Control, O=Oracle Corporation,L=Redwood City, S=California, C=US"
Note:
If you receive the following error:"keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect"
, it probably means that the value you specified for store_path
already exists. Move or rename the file and rerun keytool
. If this is not the case, contact support.Verify that the keystore file was created at the specified location. It should be about 2KB in size.
To generate a new truststore file, proceed as follows:
Open a command shell prompt.
Change directory to the JDK1.6_HOME/bin
directory; to here, for example, if you elected to use the version embedded with the Core Server installation:
$OACC_INSTALL/java/bin
Execute the keystool
command as follows:
keytool -genkey -alias alias_value -keyalg RSA -keysize 1024 -storepass password -keypass password -keystore store_path -storetype jks -dname dname_values
Where:
alias_value is the identifier of the original key created during truststore creation. This value can be any string.
password is a strong password for accessing the truststore file. Tomcat requires that you specify the same value to access the truststore and its private key.
store_path is the path of the truststore file that you are generating.
dbname_values are optional values that identify the owner of the credentials passed from the Server to any Client. For example: "CN=Application Configuration Console Server, OU=Enterprise Manager Grid Control, O=Oracle Corporation,L=Redwood City, S=California, C=US"
Note:
If you receive the following error:"keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect"
, it probably means that the value you specified for store_path
already exists. Move or rename the file and rerun keytool
. If this is not the case, contact support.Verify that the truststore file was created at the specified location. It should be about 2KB in size.
Update server.xml
to include the values.
Navigate to the following directory on the Core Server host and open server.xml
in a text or XML editor:
$OACC_INSTALL/appserver/tomcat/conf
At the bottom of the file, locate the XML element <Connector port="9943" ... />
and edit the values of these four properties (keystoreFile, keystorePass, truststoreFile, truststorePass
) with the values specified during keystore/truststore generation.
Save your changes and restart the Core Server. You can restart from command line as follows: $OACC_INSTALL/appserver/tomcat/bin/startup.bat
(for Windows) or startup.sh
for (Linux/UNIX).
Some environments may require a layer of security between the Core Server and the SVN server. This section provides instructions for requiring authentication on the SVN server, and disabling anonymous read and write access.
First, you should encrypt an Application Configuration Console password, using the MVEncryption.bat
file as follows:
Navigate to the following directory:
$OACC_INSTALL/appserver/tomcat/shared/scripts
Run the following command:
MVEncryption.bat mvpassword
Command output resembles the following:
Encrypting [mvpassword]
Encrypted characters: [67|115|98|97|83|81|100|53|82|90|67|122|73|109|99|111|70]
Encrypted string....: [CsbaSQd5RZCzImcoF45kmg=]
Make a copy of the Encrypted string value between the brackets (shown in bold in the example). This is your encrypted password.
Now do the following:
Make the following changes to the svnserve.conf
file in $OACC_INSTALL/svn/db/conf
:
Uncomment the following line:
password-db=mvuserfile
Change the access in the general section to the following values:
[general] anon-access = none auth-access = write
In $OACC_INSTALL/svn/db/conf
, create an ASCII file named mvuserfile with the following contents:
[USERS] mvadmin=unencryptedpassword
Set permissionss on mvuserfile
such that the Application Configuration Console-specific operating system user (OACCUSER
) has at least read access.
Add username and password property values to the following module in server_modules_registry.xml
:
<module name="com.mvalent.service.system.repository.version.impl. subversion.SvnSessionContext"> <property name="username" value="mvadmin"/> <property name="password" value="encryptedpassword"/>\
Make this change to the versions of server_modules_registry.xml
in the following locations:
$OACC_INSTALL/appserver/tomcat/shared/classes/ $OACC_INSTALL/appserver/tomcat/webapps/mvtrack/WEB-INF/classes $OACC_INSTALL/appserver/tomcat/webapps/mvwebreports/WEB-INF/classes
Anonymous read and write access is now disabled on the SVN server.
The Core Tomcat server uses an SSL certificate to ensure secure communication with the Application Configuration Console Clients. If desired, you can use your own certificate instead of the one supplied by Oracle. The certificate can be JKS or PKCS #12 format, and you must have the associated private key. With PKCS #12, for example, do the following:
Stop the Core Server and Clients if they are running.
Use OpenSSL to produce a keystore file from your certificate file:
> openssl pkcs12 -export -in mycertificate.cer -inkey mycertificate.key -out mvserver.ks -name tomcat
Copy the mvserver.ks
file for use by the Clients:
> cp mvserver.ks mvclient.ts
On the Core Server system, rename the existing mvserver.ks
file:
> cd $OACC_INSTALL/com.mvalent.integrity_5.3.2/webserver/tomcat > rename mvserver.ks mvclient.ks.orig
Copy the new mvserver.ks
file that you created in Step 2 to the following directory:
$OACC_INSTALL/com.mvalent.integrity_5.3.2/webserver/tomcat
Open the $OACC_INSTALL/appserver/tomcat/conf/server.xml
file in a text editor.
Move to the end of the file and look for the <Connector>
element that starts with port="9943"
.
Change the keystorePass
attribute in the Connector
element to the password required by your certificate.
Save and close the server.xml
file.
On each Client machine, copy the mvclient.ts
file that you created in Step 3 to the following directory:
$OACC_INSTALL\runtime\plugins\com.mvalent.integrity_5.3.2\config.
On each Client, navigate to the following directory and open client_boot.xml
in a text editor:
$OACC_INSTALL\runtime\plugins\com.mvalent.integrity_5.3.2\config
Change the value of the trustStorePassword
to the password required by your certificate.
Save and close the client_boot.xml
file.
Restart the Core Server and Clients.