Practices for Lesson 11 Practices Overview
Practice 11-1: Investigating SSL Problems
Duration: 40 minutes Skills Learned
At the end of this practice, you should be able to:
• Manage and monitor the SSL subsystem
• Analyze SSL debug messages
• Analyze and update keystore contents
• Troubleshoot invalid and untrusted certificates Overview
Recall that SSL for Java applications involves keystore files to securely house private and public keys. Identity keystores provide keys to establish one-way SSL connections with clients, while trust keystores provide keys to validate other systems’ identities. Trust keystores are used by the server to establish incoming two-way SSL connections and for initiating outbound SSL connections.
Due to the confidential nature of patients’ data, the MedRec application has been updated to require SSL communication between browser clients and the server. Additionally, the
application has been updated so that any outbound JMS message exchanges that involve patient data are also secured. This lab environment is depicted in the following diagram:
Instructions
1. Set up the practice.
a. Locate a Lab Framework prompt or start a new one. Change directories to
<CURRENT_LAB>.
b. Execute the following:
ant setup_exercise The Lab Framework:
− Generates new self-signed certificates for MedRecSvr1 and MedRecSvr2
− Configures SSL for MedRecSvr1
− Defines a new server MedRecSvr2 that also supports SSL
− Adds a JMS server and queue to MedRecSvr2
− Deploys a new version of the MedRec application that requires SSL and also sends JMS messages to MedRecSvr2
2. Observe SSL startup errors.
a. Launch the console and view the configuration for MedRecSvr1.
Oracle University and Sentra inversiones y servicios LTDA use only
b. Under Configuration > General, confirm that the server is enabled for SSL:
c. Click the Configuration > Keystores tab. Note the file name and location of this server’s Custom Identity Keystore.
d. Click the Configuration > SSL tab. Note the Private Key Alias in the keystore that this server is using.
e. Launch another Web browser and access the MedRec application by using the standard server port:
http://localhost:7021/medrec/index.action
Notice that the server automatically redirects the browser to the SSL port, due to the settings in the application’s web.xml descriptor.
f. Confirm that the browser is unable to access the SSL port. For example:
g. Inspect the latest server output for MedRecSvr1. Verify that several errors were reported when trying to start the SSL port, similar to:
<Notice> <Security> <BEA-090171> <Loading the identity
certificate and private key stored under the alias server1 from the JKS keystore file ... mycompany_medrec.jks.>
<Error> <WebLogicServer> <BEA-000297> <Inconsistent security configuration, java.lang.RuntimeException: Cannot convert identity certificate>
<Error> <Server> <BEA-002618> <An invalid attempt was made to configure a channel for unconfigured protocol "Cannot convert identity certificate".>
3. Debug SSL startup activities.
a. Lock the console. Edit MedRecSvr1.
b. Click the Debug tab.
c. Locate and expand the weblogic > security > ssl debug scope.
d. Select the check box for the DebugSecuritySSL attribute and click the Enable button.
e. Activate your changes.
f. Click the Control tab.
g. In the Server Status table, click the Restart SSL button. Then click Yes to confirm.
h. View the ServerLog for MedRecSvr1. Locate an SSL debug message related to loading the server’s identity certificate:
<Debug> <SecuritySSL> <BEA-000000> <Loaded public identity certificate chain:>
<Debug> <SecuritySSL> <BEA-000000> <Subject: CN=localhost, OU=Medical Services, O=My Company, L=Palo Alto, ST=California,
Oracle University and Sentra inversiones y servicios LTDA use only
C=US; Issuer: CN=localhost, OU=Medical Services, O=My Company, L=Palo Alto, ST=California, C=US>
Tip: You may need to click Customize this table to clear out the WLDF Query Expression from a previous practice for these messages to be displayed. Also, remember that you can search for messages of a specific severity or subsystem by using the WLDF Query Expression.
i. Search for a debug message describing the cause of the SSL startup failure:
<Debug> <SecuritySSL> <BEA-000000> <Cannot convert identity certificate
java.security.cert.CertificateParsingException: PKIX:
Unsupported OID in the AlgorithmIdentifier object:
1.2.840.113549.1.1.11
This message suggests that the algorithm or “cipher” used by the certificate is not supported.
4. Analyze and update keystore contents.
After conversations with the right people in IT, you have obtained the necessary keystore and certificate passwords.
a. From your Lab Framework prompt, navigate to <LAB_WORK>/domains/
MedRecDomain.
b. Execute the following:
keytool -list –v -keystore mycompany_medrec.jks -storepass storepass
Tip: For convenience, these commands are also available at
<CURRENT_LAB>/resources/keytool.txt.
c. Keytool indicates that there is an entry in this keystore named server1. In the details for this certificate, locate the algorithm being used:
SHA1: 56:B5:92:C7:72:6E:C2:69:E8:...
Signature algorithm name: SHA256withRSA
Our current JDK/WLS installation does not support this algorithm. We will replace this entry with a new certificate based on a supported algorithm.
d. Use keytool to delete this entry from the keystore:
keytool -delete -keystore mycompany_medrec.jks -storepass storepass -alias server1
e. Add a new self-signed certificate to the keystore, using the same alias and password:
DNAME="CN=localhost, OU=Medical Services, O=My Company, L=Palo Alto, S=California, C=US"
keytool -genkeypair -keystore mycompany_medrec.jks
-storepass storepass -alias server1 –keypass server1pass –dname "$DNAME" –keysize 512 –keyalg RSA –sigalg MD5withRSA f. Use keytool to verify the new contents of the keystore.
5. Debug SSL communication.
a. Return to the console and repeat the previous steps to Restart SSL on MedRecSvr1.
Oracle University and Sentra inversiones y servicios LTDA use only
b. View the latest messages in the server log. Confirm that the server’s identify certificate was successfully loaded and that the SSL port was opened. For example:
<Debug> <SecuritySSL> <BEA-000000> <SSLContextManager:
initializing SSL context for channel DefaultSecure>
...
<Notice> <Security> <BEA-090171> <Loading the identity
certificate and private key stored under the alias server1 from the JKS keystore file
/home/oracle/wls11g_trouble/work/domains/MedRecDomain/mycompany_
medrec.jks.>
<Debug> <SecuritySSL> <BEA-000000> <Loaded public identity certificate chain:>
<Debug> <SecuritySSL> <BEA-000000> <Subject: CN=localhost, ...>
...
<Notice> <Server> <BEA-002613> <Channel "DefaultSecure" is now listening on 127.0.0.1:7022 for protocols iiops, t3s, CLUSTER-BROADCAST-SECURE, ldaps, https.>
c. Browse the SSL debug messages and try to determine the location of the server’s trust keystore file.
d. Test the MedRec application again:
http://localhost:7021/medrec/index.action
e. When prompted about a bad certificate by the browser, click the Or you can add an exception link. Then click the Add Exception button:
f. Click the Get Certificate button, and then click Confirm Security Exception.
g. Log in as the [email protected]/weblogic patient.
h. Return to the server log and trace the MedRec SSL communication by using debug messages. For example:
<Debug> <SecuritySSL> <BEA-000000> <26521019 SSL3/TLS MAC>
<Debug> <SecuritySSL> <BEA-000000> <26521019 received HANDSHAKE>
<Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE:
ClientHello>
...
<Debug> <SecuritySSL> <BEA-000000> <26898068 SSL3/TLS MAC>
<Debug> <SecuritySSL> <BEA-000000> <26898068 received APPLICATION_DATA: databufferLen 0, contentLength 638>
...
<Debug> <SecuritySSL> <BEA-000000> <write APPLICATION_DATA, offset = 0, length = 297>
6. Observe a rejected certificate scenario.
Oracle University and Sentra inversiones y servicios LTDA use only
a. Launch the new MedRecSvr2 server by using the MedRecDomain/
startServer2.sh script.
b. Test the MedRec application again. After logging in, click the Profile button.
c. Enter weblogic as the password if necessary, and click the Save button.
The application attempts to send a JMS message over SSL to MedRecSvr2.
d. Confirm that the application fails with the message “Internal Server Error.”
e. Inspect the latest log messages for MedRecSvr1. First, locate the Java exception related to this error. It should be similar to:
com.sun.faces.application.ActionListenerImpl processAction SEVERE: javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3s://localhost:7032: Destination unreachable; nested exception is:
javax.net.ssl.SSLKeyException:
[Security:090477]Certificate chain received from localhost - 127.0.0.1 was not trusted causing SSL handshake failure.; No available router to destination]
f. Similar debug and warning messages should exist. For example:
<Debug> <SecuritySSL> <BEA-000000> <Validation error = 16>
<Debug> <SecuritySSL> <BEA-000000> <Certificate chain is untrusted>
<Debug> <SecuritySSL> <BEA-000000> <SSLTrustValidator returns:
16>
<Debug> <SecuritySSL> <BEA-000000> <Trust status (16):
CERT_CHAIN_UNTRUSTED>
All of these messages suggest that none of the certificates in the server’s trust keystore were able to validate the certificate received from MedRecSvr2.
7. Update a trust keystore.
a. Make a backup copy of the file
<MIDDLEWARE_HOME>/jrockit_160.../jre/lib/security/cacerts. The specific name of the JRockit folder varies depending on your WLS installation.
b. From your Lab Framework prompt, navigate to <LAB_WORK>/domains/
MedRecDomain.
c. Execute the following to export the MedRecSvr2 certificate to a file:
keytool -exportcert -keystore mycompany_medrec.jks
-storepass storepass –alias server2 –keypass server2pass –file server2.cer
Tip: By default, keytool exports certificates to binary format, but it can also export certificates to the Base64-encoded PEM format.
d. Now import the file as a trust certificate into cacerts.
keytool -importcert –v –trustcacerts -keystore
${MIDDLEWARE_HOME}/jrockit_160…/jre/lib/security/cacerts -storepass changeit –file server2.cer –alias server2 –keypass server2pass
Oracle University and Sentra inversiones y servicios LTDA use only
e. When prompted, enter yes.
f. Once again Restart SSL for MedRecSvr1.
g. Search the latest SSL debug messages. Try to locate a message stating that the new MedRecSvr2 trust certificate was found. For example:
<Debug> <SecuritySSL> <BEA-000000> <SSLContextManager: loaded 72 trusted CAs from
/u01/app/oracle/product/11.1.0/middleware/jrockit_160_14_R27.6.5 -32/jre/lib/security/cacerts>
...
<Debug> <SecuritySSL> <BEA-000000> <Subject: CN=localhost, OU=Medical Services, O=My Company, L=Palo Alto, ST=California, C=US; Issuer: CN=localhost, OU=Medical Services, O=My Company, L=Palo Alto, ST=California, C=US>
8. Test outgoing SSL.
a. Repeat the same test on the MedRec application. Verify that the Save button no longer triggers an error.
b. Return to the console.
c. From the Domain Structure panel, select Services > Messaging > JMS Servers.
d. Click ProfileJMSServer.
e. Click the Monitoring tab. Use the Messages Current column to confirm that a JMS message was received on MedRecSvr2.
f. When finished, perform the following:
1) Shut down MedRecSvr2.
2) Delete the file server2.cer.
3) Disable SSL debug log messages.
Oracle University and Sentra inversiones y servicios LTDA use only
Solution Instructions
There is no complete solution for this practice. If you only partially completed the practice instructions, however, then you need to undo what you have done by following these steps:
1. Launch the Lab Framework command shell by executing the
<STUDENT>/bin/prompt.sh file.
2. Change the current directory to <CURRENT_LAB>.
3. Execute the following:
ant setup_solution The Lab Framework:
− Makes a backup copy of your current work
− Disables SSL on all servers
− Disables any SSL debug flags