|
|
This topic includes the following sections:
Note: The problems in this topic pertain to using the SSL protocol and certificate-based authentication with WLE CORBA applications.
In general, Object Request Brokers (ORBs) write important failures to the ULOG
file. When using the CORBA C++ ORB, you can also enable ORB internal tracing which may provide information in addition to the information that appears in the ULOG
file.
When looking the ULOG
file, note that remote ORB processes by default do not write data to the ULOG
file in APPDIR
.
Using ULOGS and ORB Tracing
You can set the ULOGPFX
environment variable to control the location of the ULOG
file for remote ORBs (for example, you can set the location of the ULOG
file to APPDIR
so that all information is put in the same ULOG
file). Set the ULOGPFX
environment variable as follows:
UNIX
setenv ULOGPFX $APPDIR/ULOG
Windows NT
set ULOGPFX=%APPDIR%\ULOG
To enable ORB tracing, perform the following steps:
set OBB_TRACE_INPUT=%APPDIR%\trace.dat
If you want ORB tracing sent to separate files, add the following line to the trace.dat file:
output=obbtrace%p.log
This command sends the trace output to files that are named after each running process. You may want to do this if you are using ORB tracing on UNIX to an NFS mounted drive. In this case, trace performance is slow due to the user log opening, writing, and closing the file for each trace statement.
The CORBA Java ORB logs error messages to the ULOG file in all error situations as well as puts minor codes to all system exceptions thrown by the ORB. Therefore, tracing is not necessary.
Note: This section applies to the CORBA C++ ORB only.
The ORB_init routine does not perform internal ORB tracing so you will not see any trace output for invalid argument processing. Therefore, you need to double check the arguments that were passed to the ORB_init routine.
If a CORBA::BAD_PARAM exception occurs when executing the ORB_init routine, verify that all required arguments have values. Also, check that arguments which expect a value from a specific set of valid values have the correct value. Note that values for the arguments of the ORB_init routine are case sensitive.
If a CORBA::NO_PERSMISSION exception occurs and an SSL argument was specified to the ORB_init routine, make sure the WLE Security Pack is installed. Also, verify that the specified level of encryption does not exceed the encryption level supported by the WLE Security Pack.
If a CORBA::IMP_LIMIT exception occurs when executing the ORB_init routine, verify that the ORBport and ORBSecurePort system properties have the same value.
If a CORBA::Initialize exception occurs when executing the ORB_init routine, verify that the values for OrbId or configset are valid.
Note: The OrbId and configset values apply to the CORBA C++ ORB only.
If Secure Socket Layer (SSL) arguments are passed to the ORB_init routine, the ORB attempts to load and initialize the SSL protocol. If no SSL arguments are passed, the ORB does not attempt to initialize the SSL protocol.
The ORB is not aware of the new URL address formats for the Bootstrap object so if you specify a corbaloc or corbalocs URL address format, the ORB does not try to load the SSL protocol during the ORB_init routine.
If SSL arguments were specified to the ORB_init routine, check the following:
If the problem persists, turn on ORB tracing. ORB tracing will log SSL failures that occur when the liborbssl
dynamic library is loaded and initialized.
If the client application fails when using the corbalocs
URL address format with Username/Password authentication, check the following:
Username/Password Authentication Problems
If the client application fails when using the corbalocs
URL address format with certificate-based authentication, check the following:
Certificate-Based Authentication Problems
If an error does not occur, the problem is in the authentication process and the ULOG file will contain one of the following error statements indicating the problem:
Additional certificate problems can also occur. See "Tobj::Bootstrap:: resolve_initial_references Problems" for more information about the types of certificate errors that can occur.
Note:
At this point of the initialization process, the failure is not due to a problem in the IIOP Listener/Handler.
If a failure occurs when performing a Tobj::Bootstrap::resolve_initial_references
with the corbaloc
or corbalocs
URL address format, a CORBA::InvalidDomain
exception is raised. This exception may mask CORBA::NO_PERMISSION
or CORBA::COMM_FAILURE
exceptions that are raised internally. Look at the ULOG
file and turn on ORB tracing to get more details on the error. The following errors may occur:
Tobj::Bootstrap::
resolve_initial_references Problems
Additional certificate problems can occur. See "Troubleshooting Tips for Digital Certificates" for more information about the types of certificate errors that can occur.
Note:
The Java implementation of the Tobj_Bootstrap::resolve_initial_references()
method does not throw an InvalidDomain
exception. When the corbaloc
or corbalocs
URL address formats are used, the Tobj_Bootstrap::resolve_initial_references()
method internally catches the InvalidDomain
exception and throws the exception as a COMM_FAILURE
. The method functions this way in order to provide backward compatibility.
This section describes problems that can occur during the startup of the IIOP Listener/Handler.
If a failure occurs when starting the IIOP Listener/Handler, check the ULOG
file for a description of the error. The IIOP Listener/Hander verifies that the values for the SSL arguments specified in the CLOPT
parameters are valid. If any of the values are invalid, the appropriate error is recorded in the ULOG
file. This check is similar to the argument checking done by the ORB.
The IIOP Listener/Handler will not start its processes unless the -m
option is specified. The ISH is the process that actually loads and initializes the SSL libraries. If there is a problem loading and initializing the SSL libraries in the ISH process, the error will not be recorded in the ULOG
file until the ISH process starts to handle incoming requests from client application.
If you suspect a problem with the startup of the IIOP Listener/Handler processes, check the ULOG
file.
The following are miscellaneous tips to resolve the common configuration problems which may occur when using the WLE Security Pack:
IIOP Listener/Handler Startup Problems
Configuration Problems
Another way to determine if the IIOP Listener/Handler is performing renegotiations is to enable ORB tracing on the client side and check whether the cipher suite negotiation callback is being called the configured renegotiation interval. Note that the client application must be sending requests for in order for renegotiations to occur.
If you have a joint client/server application and the client portion of the joint client/server application specifies security requirements using either the corbalocs
URL address format or by requiring credentials, you must use the -ORBsecurePort
system property with the ORB_init
routine to specify that a secure port be used.
If you do not specify the -ORBsecurePort
system property, the server registration will fail with a CORBA::NO_PERMISSION
exception. To verify this is the problem, enable ORB tracing and look for the following trace output:
TCPTransport::Listen: FAILURE: Attempt to listen on clear port while Credentials require SSL be used
If you want to use the SSL protocol with callback objects, the joint client/server application must use the SecurityLevel2::PrincipalAuthenticator::authenticate()
method with certificate-based authentication. Otherwise, the joint client/server application does not have a certificate with which to identify itself to the IIOP Listener/Handler which in this case is the initiator of the SSL connection.
In general, problems with digital certificates occur when:
Problems with Using Callbacks Objects with the SSL Protocol
Troubleshooting Tips for Digital Certificates
You can verify this error by setting the -ORBpeerValidate system property to none and executing the ORB_init routine again.
If a digital certificate is rejected for no explainable reason, perform the following steps:
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|