Table of Contents Previous Next PDF


Managing Public Key Security

Managing Public Key Security
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:
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.
Requirements for Using Public Key Security
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.
Who Needs Digital Certificates and Private/Private Key Pairs?
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” on page 4‑7.
Requesting a Digital Certificate
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:
 
key.der
The CSR file which you submit to the certificate authority. It contains the same data as the .dem file but the file is encoded in ASCII so that you can copy it into e-mail or paste it into a Web form.
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.
Publishing Certificates in the LDAP Directory Service
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.
Figure 4‑1 LDAP Directory Structure for Digital Certificates
 
Once you receive your digital certificates from the certificate authority, store them in the LDAP directory service as follows:
Digital certificates for the IIOP Listener/Handler and any principals are stored in the LDAP directory service with an attribute of userCertificate on an object class with that attribute defined. Typically, these digital certificates are stored as an instance of the strongAuthenticationUser object class as defined by X.500.
Digital certificates for certificate authorities are stored in LDAP directory service with an attribute of caCertificate on an object class with that attribute defined. Typically, these digital certificates are stored as an instance of the certificateAuthority class 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” on page 4‑4.
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.
Editing the LDAP Search Filter File
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 certificationAuthority and 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:
“BEA_person_lookup”
“.*” “ “ “(&(objectClass=strongAuthenticationUser) (mail=%v))”
“e-mail address”
“(&(objectClass=strongAuthenticationUser) (mail=%v))”
“start of e-mail address”
“BEA_issuer_lookup”
“.*” “ ” “(&(objectClass=certificationAuthority)
(cn=%v)” “exact match cn”
(sn=%v))” “exact match sn”
BEA_person_lookup specifies to search the LDAP directory service for principals by their e-mail addresses.
BEA_issuer_lookup specifies to search the LDAP directory service for principals by their common names (cn).
See the documentation for your LDAP-enabled directory service for additional information about LDAP search file filters.
Storing the Private Keys in a Common Location
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:
1.
The @ character in the name is replaced by an underscore (_) character.
2.
All characters after the dot (.) character are deleted.
3.
A .PEM file extension is appended to the file.
For example, if the name of the principal is milozzi@bigcompany.com 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:
Window 2000
%HOMEDRIVE%\%HOMEPATH%
UNIX
$HOME
The Oracle Tuxedo software also looks in the following directory for private key files:
$TUXDIR/udataobj/security/keys
The $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.
Listing 4‑1 Example of Private Key File
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIICoDAaBgkqhkiG9w0BBQMwDQQItSFrtYcfKygCAQUEggKAEgrMxo8gYB/MOSXG
...
-----END ENCRYPTED PRIVATE KEY-----
 
Defining the Trusted Certificate Authorities
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 $TUXDIR/udataobj/security/certs. The trust_ca.cer can be edited with any text editor.
The 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.
Listing 4‑2 Example of Trusted Certificate Authority File
-----BEGIN CERTIFICATE----
­MIIEuzCCBCSgAwIBAgIQKtZuM5AOzS9dZaIATJxIuDANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----
­MIIEuzCCBCSgAwIBAgIQKtZuM5AOzS9dZaIATJxIuDANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
...
-----END CERTIFICATE-----
 
Creating a Peer Rules 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:
$TUXDIR/udataobj/security/certs
Listing 4‑3 provides an example of a Peer Rules file.
Listing 4‑3 Example of 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=Ace Industry
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 (;) character.
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:
, + = "" <CR> < > # ;
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.
 

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.