| Oracle® Retail Merchandising Security Guide Release 14.1.1 E61235-01 |
|
 Previous |
 Next |
This chapter covers the common errors, issues, and troubleshooting them.
The following topics are covered in this chapter:
Java Version 7 SSL Handshake Issue while Using Self Signed Certificates
HTTPS Service Encountering Redirect Loop After Applying Policy A
Java Version 7 may have issues using self signed certificates. The self-signed root certificate may not be recognized by Java Version 1.7 and a certificate validation exception might be thrown during the SSL handshake. You need to create the private key with Subject Key Identifier to fix this problem. You need to include an option - addext_ski when the orapki utility is used to create the private key in the root wallet.
If customers are using certificates other than provided by standard certificate authorities like custom CA implementation, then the JRE used for launching the applications from local machines like laptops or desktops might display a different error messages.
The most probable cause of this issue could be unavailability of root certificates of the CA within the local JRE being used.
Perform the following steps to import the root certificates:
Backup cacert at <JRE_HOME>/lib/security/cacert.
Import the certificate using keytool utility as shown in the following example:
C:\Program Files\Java\jre7\lib\security>..\..\bin\keytool.exe -import -trustcacerts -file D:\ADMINISTRATION\SSL\apphost2\Selfsigned\apphost2.root.cer -alias apphost2 -keystore "C:\Program Files\Java\jre7\lib\security\cacerts" Enter keystore password: [default is changeit] Owner: CN=apphost2, OU=<department>, O=<company>,L=<city>,ST=<state or province>, C=<country>", Issuer: CN=apphost2, OU=<department>, O=<company>,L=<city>,ST=<state or province>, C=<country>" Serial number: 515d4bfb Valid from: Thu Apr 04 15:16:35 IST 2013 until: Fri Apr 04 15:16:35 IST 2014 Certificate fingerprints: MD5: AB:FA:18:2B:BC:FF:1B:67:E7:69:07:2B:DB:E4:C6:D9 SHA1: 2E:98:D4:4B:E0:E7:B6:73:55:4E:5A:BE:C1:9F:EA:9B:71:18:60:BB SHA256: F3:54:FB:67:80:10:BA:9C:3F:AB:48:0B:27:83:58:BB:3D:22:C5:27:7D: F4:D1:85:C4:4E:87:57:72:2B:6F:27 Signature algorithm name: SHA1withRSA Version: 3 Trust this certificate? [no]: (yes) Certificate was added to keystore C:\Program Files\Java\jre7\lib\security>
You need to add the signed Weblogic server certificate in the browser to avoid certificate verification error, if the Root Certificate is not in that list of trusted CAs.
Perform the following steps to import the Root Certificate through Internet Explorer:
Copy the Root Certificate file to the workstation.
Rename the file to fa_root_cert.cer (this is a quick and easy way to associate the file with the Windows certificate import utility).
Select the file.
Click Install Certificate and click Next.
Select Place all certificates in the following store and click Browse.
Select trusted Root Certification Authorities and click OK.
Click Next.
Click Finish and then Yes at the Security Warning prompt.
Click OK to close the remaining open dialog boxes.
Perform the following steps to import the Root Certificate through Mozilla Firefox:
Start Mozilla Firefox.
Select Tools > Options from the main menu.
Click Advanced >Encryption tab >View Certificates.
In Certificate Manager, click the Authorities tab and then the Import button.
In the Downloading Certificate dialog, choose Trust this CA to identify websites and click OK.
Click OK in Certificate Manager.
Open a browser and test the URL using the SSL port.
To obtain secure cookies, do the following:
Enable SSL in the environment.
Update the weblogic.xml.
<session-descriptor> <cookie-http-only>false</cookie-http-only> <cookie-secure>true</cookie-secure> <url-rewriting-enabled>false</url-rewriting-enabled> <cookie-path>/<context_root></cookie-path> </session-descriptor>
Redeploy the <app>.ear file.
Restart the services.
Following are the changes to be made to Web Application Descriptor:
Open the deployment descriptor of the Service Workspace, which has the jersey servlet configured.
Change transport-guarantee to CONFIDENTIAL.
Deploy the Application to secure the ReST Services as a one way SSL as follows:
<security-constraint>
<web-resource-collection>
<web-resource-name>Workflow Actions</web-resource-name>
<url-pattern>/services/private/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
..
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
|
Note: An SSL connection needs to be used to ensure information being sent is not compromised, especially authentication credentials. If SSL is not used, the user credentials gets passed with BASE-64 encoding which does not encrypt the credentials and would be a hole in security. |
For launching errors of RPM in the Java console, see the following example:
Caused by: java.net.ConnectException: t3s://apphost2:17012: Destination unreachable; nested exception is: javax.net.ssl.SSLKeyException: [Security:090542]Certificate chain received from apphost2 - 10.141.13.195 was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.; No available router to destination at weblogic.rjvm.RJVMFinder.findOrCreateInternal(RJVMFinder.java:216) at weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:170) at weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:153) at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:352) ... 27 more
The reason could be SSL Handshake failing between Desktop client and the RPM server. Try importing the root certificates in local client JRE (see the steps as provided in Importing the Root Certificate in Local Client JRE section). In case this fails, try disabling hostname verification to NONE for SSL Configuration of the managed server where RPM is deployed. See Disabling Hostname Verification section. This will require restart of the RPM managed server.
The hostname verification ensures that the hostname in the URL to which the client connects matches the hostname in the digital certificate that the server sends back as part of the SSL connection. However, in case SSL handshake is failing due to inability to verify hostname this workaround can be used.
|
Note: Disabling hostname verification is not recommended on production environments. This is only recommended for testing purposes. Hostname verification helps to prevent man-in-the-middle attacks. |
Perform the following steps to disable the hostname verification for testing purposes:
Go to Environment > Domain > Servers > AdminServer.
Click the SSL tab.
Click Advanced.
On Hostname Verification, select NONE.
Save and activate changes.
On the Node Manager startup script, look for JAVA. Add the following line:
Dweblogic.nodemanager.sslHostNameVerificationEnabled=false
After this change, the script should look as follows:
JAVA_OPTIONS="-Dweblogic.nodemanager.sslHostNameVerificationEnabled=false ${JAVA_OPTIONS}"
cd "${NODEMGR_HOME}"
set -x
if [ "$LISTEN_PORT" != "" ]
then
if [ "$LISTEN_ADDRESS" != "" ]
Restart Node manager.
In situations where the certificate expires or belongs to a different hosts, the certificates become unusable. You can use the keytool utility to determine the details of the certificate. The certificates should be renewed or new certificates should be obtained from the appropriate certificate authorities, if the certificates expire.
Example:
apphost1:[10.3.6_apps] /u00/webadmin/ssl> keytool -printcert -file cert.cer
Certificate[1]:
Owner: CN=apphost1, OU=<department>, O=<company>,L=<city>,ST=<state or province>, C=<country>"
Issuer: CN=Oracle SSL CA, OU=Class 3 MPKI Secure Server CA, OU=VeriSign Trust Network, O=Oracle Corporation, C=US
Serial number: 0078dab9f1a5b56e2cd6g92a3987296
Valid from: Thu Oct 11 20:00:00 EDT 2012 until: Sat Oct 12 19:59:59 EDT 2013
Certificate fingerprints:
MD5: 2B:71:89:11:01:40:43:FC:6F:D7:FB:24:EB:11:A5:1C
SHA1:
DA:EF:EC:1F:85:A9:DA:0E:E1:1B:50:A6:8B:A8:8A:BA:62:69:35:C1
SHA256: C6:6F:6B:A7:C5:2C:9C:3C:40:E3:40:9A:67:18:B9:DC:8A:97:52:DB:FD:AB:4B:E5:B2:56:47:EC:A7:16:DF:B6
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
Keystores are repository of the certificates. If you face issues related to SSL Certificates, you need to check the certificates which are available in the keystore. You need to import the certificates if they are not missing. The keytool command provides the list of the certificates available.
Example:
$ keytool -v -list -keystore /u00/webadmin/product/jdk/jre/lib/security/cacerts $ keytool -v -list -keystore /u00/webadmin/product/10.3.X_APPS/WLS/wlserver_10.3/server/lib/apphost1.keystore
Oracle Retail applications can be deployed across different hosts and behind network firewalls. Ensure firewalls are configured to allow TCPS connections to enable secure communications among integrated application.
Secured applications using signed certificates need to use same secured protocols for communication. Ensure that all the communicating applications use the same protocol.
For more information on steps to specify secured protocol, see Enforcing Stronger Encryption in WebLogic section.
Communicating applications using signed certificates may need to verify the incoming connections. Root certificates should be available in the keystores of the applications to verify the requests from different host. It is important to import all the root certificates in the keystores of all communicating applications. For information on steps to import the root certificate in local client JRE, see Importing the Root Certificate in Local Client JRE section.
When you try to restart the WLS_FORMS managed server in Oracle Forms installation after configuring for secure setup (enabling SSL), the managed server startup logs shows the error as shown in Example 5-1. To resolve, ensure that Additional configuration for WLS_FORMS (For forms server) in Pre-installation - Steps for Secured Setup of Oracle Retail Infrastructure in WebLogic have been completed. The startup shows the errors in the logs as shown in the example, when you try to restart the WLS_FORMS managed server in Oracle Forms installation after configuring for security.
Example 5-1 WLS_Forms startup error
Feb 6, 2013 6:05:40 AM EST> <Notice> <Cluster> <BEA-000133> <Waiting to synchronize with other running members of cluster_forms.>
<Feb 6, 2013 6:06:10 AM EST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to ADMIN>
<Feb 6, 2013 6:06:10 AM EST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RESUMING>
<Feb 6, 2013 6:06:10 AM EST> <Error> <Cluster> <BEA-003111> <No channel exists for replication calls for cluster cluster_forms>
<Feb 6, 2013 6:06:10 AM EST> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: java.lang.AssertionError: No replication server channel for WLS_FORMS
java.lang.AssertionError: No replication server channel for WLS_FORMS
at weblogic.cluster.replication.ReplicationManagerServerRef.initialize(ReplicationManagerServerRef.java:128)
at weblogic.cluster.replication.ReplicationManagerServerRef.<clinit>(ReplicationManagerServerRef.java:84)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:186)
at weblogic.rmi.internal.BasicRuntimeDescriptor.getServerReferenceClass(BasicRuntimeDescriptor.java:469)
Truncated. see log file for complete stacktrace
>
<Feb 6, 2013 6:06:10 AM EST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED>
<Feb 6, 2013 6:06:10 AM EST> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down>
<Feb 6, 2013 6:06:10 AM EST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN>
<Feb 6, 2013 6:06:11 AM> <FINEST> <NodeManager> <Waiting for the process to die: 28209>
<Feb 6, 2013 6:06:11 AM> <INFO> <NodeManager> <Server failed during startup so will not be restarted>
<Feb 6, 2013 6:06:11 AM> <FINEST> <NodeManager> <runMonitor returned, setting finished=true and notifying waiters>
Ensure you have completed the steps mentioned in Additional Configuration for WLS_FORMS (For forms server) section of Chapter 1.
The proxy server access enters into a redirect loop, if the services are secured with policy A (username token over SSL), and the deployment is in a cluster. The access to such services does not work.
Perform the following workaround through SB Console, for services that are secured with HTTPS:
Click Resource Browser.
Click Proxy Services under Resource Browser.
Click Create under Change Center to start a session.
For each of the SSL secured proxy services, perform the following steps:
Click the proxy service you want to change.
Click Edit next to HTTP Transport Configuration.
Uncheck HTTPS Required check box.
Click Last.
Click Save.
Click Activate and then Submit.
