This topic includes the following sections:
Perform the tasks in this topic only if you are using the SSL protocol, or certificate authentication in your CORBA application.
|Notes:||The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.|
|Note:||Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.|
To use the SSL protocol and public key security to protect communication between principals and the Oracle Tuxedo domain, you need to install a special license. For information about installing the license, see Installing the Oracle Tuxedo System.
You also need to choose a Lightweight Directory Access Protocol server and a certificate authority (either commercial or private) setup for your organization before implementing Public Key Security.
To use the SSL protocol in the CORBA security environment, you need a private key and a digitally-signed certificate containing the matching public key. How many digital certificates and private keys you need depends on how you plan to use the SSL protocol.
Any digital certificate that is obtained and used must be issued from a trusted certificate authority defined in the trusted CA file. For more information, see Defining the Trusted Certificate Authorities.
To acquire a digital certificate, you need to submit your request for a digital certificate in a particular format called a certificate signature request (CSR). How you create a CSR depends on the certificate authority you use. Certificate authorities typically provide a means to generate a public key, private key, and a CSR which contains your public key. To create a CSR follow the steps outlined by your chosen certificate authority.
When you complete the steps to create a CSR, you receive the following files from the certificate authority:
To purchase a digital certificate from a certificate authority, you submit the CSR to the certificate authority according to the enrollment procedure of the certificate authority. Some commercial certificate authorities allow you to purchase digital certificates through the Web.
The use of a global directory service is the most popular way to store digital certificates. A directory service simplifies the management of information that needs to be globally available to an ever-growing number of users. An LDAP server provides access to a variety of directory services.
The CORBA security environment in the Oracle Tuxedo product, when configured to use the SSL protocol, can retrieve digital certificates for principals and certificate authorities from an LDAP directory service, such as Netscape Directory Service or Microsoft Active Directory. Before you can use the SSL protocol or certificate authentication, you need to install an LDAP directory service and configure it for your organization. Oracle Systems does not provide nor recommend any specific LDAP directory service. However, the LDAP directory service you choose should support the X.500 scheme definition and the LDAP version 2 or 3 protocol.
LDAP directory services define a hierarchy of object classes. While there are a number of different object classes, there is a small set associated with digital certificates. Figure 4-1 illustrates the object classes typically associated with digital certificates.
Once you receive your digital certificates from the certificate authority, store them in the LDAP directory service as follows:
userCertificateon an object class with that attribute defined. Typically, these digital certificates are stored as an instance of the
strongAuthenticationUserobject class as defined by X.500.
caCertificateon an object class with that attribute defined. Typically, these digital certificates are stored as an instance of the
certificateAuthorityclass as defined by X.500.
If your LDAP scheme requires the use of different classes, you will need to modify the LDAP search file as described in Editing the LDAP Search Filter File.
The Oracle Tuxedo product requires that the digital certificates be stored in the directory service in Privacy Enhanced Mail (PEM) format.
Refer to Installing the Oracle Tuxedo System for information about integrating an LDAP directory service into the CORBA security environment.
When configuring a CORBA application to use the SSL protocol or certificate authentication, you may need to customize the LDAP search filter file to limit the scope of the search of the directory service or specify the object classes that will be used to hold the digital certificates. Customizing the LDAP search filter file can result in significant performance gains. The Oracle Tuxedo product ships with the following LDAP search filters:
If the directory service scheme for your organization is defined to store digital certificates in object classes other than
strongAuthenticationUser, the LDAP search filter file must be modified to specify those object classes.
You can specify a location of the LDAP search filter file during the installation of the Oracle Tuxedo product. For more information, see Installing the Oracle Tuxedo System.
The LDAP search filter file should be owned by the administrator account. Oracle recommends that the file be protected so that only the owner has read and write privileges for the file and all other users have only read privileges for the file.
To limit the search of the directory service for digital certificates for principals and certificate authorities, you need to modify the filter stanzas identified by the following tags in the LDAP search filter file:
These tags identify the stanzas in the LDAP search filter file that contains the filter expression that will be used when looking up information in the directory service. These Oracle-specific tags allow the stanzas of an LDAP search filter file to be stored in a common LDAP search filter file with stanzas used by other LDAP-enabled applications that might be found in your organization.
The following is an example of the stanzas of an LDAP search filter file used by the Oracle Tuxedo product for the SSL protocol and certificate authentication:
“.*” “ “ “(|(objectClass=strongAuthenticationUser) (mail=%v))”
“start of e-mail address”
“.*” “ ” “(&(objectClass=certificationAuthority)
(cn=%v)” “exact match cn”
(sn=%v))” “exact match sn”
See the documentation for your LDAP-enabled directory service for additional information about LDAP search file filters.
When a principal generates a CSR, they typically get a file with a private key. Principals need this private key file to verify their identity in the authentication process. Assign the private key file protections so that only the owner of the private key file has read privileges and all other users have no privileges to access the file. Private key files must be stored as PEM-encoded PKCS #8 protected format.
The Oracle Tuxedo system uses the e-mail address of the principal to construct a name for the private key file as follows:
For example, if the name of the principal is
firstname.lastname@example.org the resulting private key file is
milozzi_bigcompany.pem. This naming convention allows an enterprise to have multiple principals that share a common username but are in different e-mail domains.
The Oracle Tuxedo software looks in the following directories for private key files:
The Oracle Tuxedo software also looks in the following directory for private key files:
$TUXDIR/udataobj/security/keys directory should be protected so that only the owner has read privileges for the directory and all other users do not have privileges to access the directory.
Listing 4-1 provides an example of a private key file.
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
When establishing an SSL connection, the CORBA processes (client applications and the IIOP Listener/Handler) check the identity of the certificate authority and certificates from the peer’s digital certificate chain against a list of trusted certificate authorities to ensure the certificate authority is trusted by the organization. This check is similar to the check done in Web browsers. If the comparison fails, the initiator of the SSL connection refuses to authenticate the target and drops the SSL connection. It is typically the job of the system administrator to define a list of trusted certificate authorities.
Retrieve from the LDAP directory service the digital certificates for the certificate authorities that are to be trusted. Cut and paste the PEM formatted digital certificates into a file named
trust_ca.cer which is stored in
trust_ca.cer can be edited with any text editor.
trust_ca.cer file should be owned by the administrator account. Oracle recommends that the file be protected so that only the owner has read and write privileges for the file and all other users have only read privileges for the file.
Listing 4-2 provides an example of a Trusted Certificate Authority file.
When communicating across network links, it is important to validate the peer to which you are connected is the intended or authorized peer. Without this check, it is possible to make a secure connection, exchange secure messages, and receive a valid chain of digital certificates but still be vulnerable to a Man-in-the-Middle attack. You perform peer validation by verifying a set of specified information contained in the peer digital certificate against a list of information that specifies the rules for validating peer trust. The system administrator maintains the Peer Rules file.
The Peer Rules are maintained in an ASCII file named
peer_val.rul. Store the
peer_val.rul file in the following location in the Oracle Tuxedo directory structure:
Listing 4-3 provides an example of a Peer Rules file.
# This file contains the list of rules for validating if
# a peer is authorized as the target of a secure connection
O=”Acme Systems, Inc.”; OU=Central Engineering;L=Herkimer;S=NY
O=”Ball, Corp.”, C=US
o=Ace Industry, ou=QA, cn=www.ace.com
Each rule in the Peer Rules file is comprised of a set of elements that are identified by a key. The Oracle Tuxedo product recognizes the key names listed in Table 4-1.
Each key is followed by an optional white space, the character
=, an optional white space, and finally the value to be compared. The key is not case sensitive. A rule is not a match unless the subject’s distinguished name contains each of the specified elements in the rule and the values of those elements match the values specified in the rule, including case and punctuation.
Each line in the Peer Rules file contains a single rule that is used to determine if a secure connection is to be established. Rules cannot span lines; the entire rule must appear on a single line. Each element in the rule can be separated by either a comma (
,) or semicolon (
Lines beginning with the pound character (
#) are comments. Comments cannot appear on the same line as the name of an organization.
A value must be enclosed in single quotation marks if one of the following cases is true:
By default, the Oracle Tuxedo product verifies peer information against the Peer Rules file. If you do not want to perform this check, create an empty Peer Rules file.