13 Configuring Secure Sockets Layer Authentication

13.2.3.1 Certificate Authority

A certificate authority (CA) is a trusted third party that certifies the identity of entities, such as users, databases, administrators, clients, and servers. When an entity requests certification, the CA verifies its identity and grants a certificate, which is signed with the CA's private key.

Different CAs may have different identification requirements when issuing certificates. Some CAs may verify a requester's identity with a driver's license, some may verify identity with the requester's fingerprints, while others may require that requesters have their certificate request form notarized.

The CA publishes its own certificate, which includes its public key. Each network entity has a list of trusted CA certificates. Before communicating, network entities exchange certificates and check that each other's certificate is signed by one of the CAs on their respective trusted CA certificate lists.

Network entities can obtain their certificates from the same or different CAs. By default, Oracle Advanced Security automatically installs trusted certificates from VeriSign, RSA, Entrust, and GTE CyberTrust when you create a new wallet.

Oracle Application Server Certificate Authority, part of Oracle Identity Management Infrastructure, is a new Oracle PKI component available in Oracle Application Server 10g (9.0.4).

13.2.3.2 Certificates

A certificate is created when an entity's public key is signed by a trusted certificate authority (CA). A certificate ensures that an entity's identification information is correct and that the public key actually belongs to that entity.

A certificate contains the entity's name, public key, and an expiration date, as well as a serial number and certificate chain information. It can also contain information about the privileges associated with the certificate.

When a network entity receives a certificate, it verifies that it is a trusted certificate, that is, one that has been issued and signed by a trusted certificate authority. A certificate remains valid until it expires or until it is revoked.

13.2.3.3 Certificate Revocation Lists

Typically, when a CA signs a certificate binding a public key pair to a user identity, the certificate is valid for a specified period of time. However, certain events, such as user name changes or compromised private keys, can render a certificate invalid before the validity period expires. When this happens, the CA revokes the certificate and adds its serial number to a Certificate Revocation List (CRL). The CA periodically publishes CRLs to alert the user population when it is no longer acceptable to use a particular public key to verify its associated user identity.

When servers or clients receive user certificates in an Oracle environment, they can validate the certificate by checking its expiration date, signature, and revocation status. Certificate revocation status is checked by validating it against published CRLs. If certificate revocation status checking is turned on, then the server searches for the appropriate CRL depending on how this feature has been configured. The server searches for CRLs in the following locations:

1. Oracle Internet Directory

2. CRL Distribution Point, a location specified in the CRL Distribution Point (CRL DP) X.509, version 3, certificate extension when the certificate is issued.

   See Also:

   "Certificate Validation with Certificate Revocation Lists" for information about configuring and managing this PKI component

13.2.3.4 Wallets

A wallet is a container that is used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by SSL. In an Oracle environment, every entity that communicates over SSL must have a wallet containing an X.509 version 3 certificate, private key, and list of trusted certificates, with the exception of Diffie-Hellman.

Security administrators use Oracle Wallet Manager to manage security credentials on the server. Wallet owners use it to manage security credentials on clients. Specifically, you use Oracle Wallet Manager to do the following:

• Generate a public-private key pair and create a certificate request

• Store a user certificate that matches with the private key

• Configure trusted certificates

  Note:

  Installation of Oracle Advanced Security 11g Release 2 (11.2) also installs Oracle Wallet Manager release 10.1.

  See Also:

  • Chapter 14, "Using Oracle Wallet Manager"

  • "Creating a New Wallet"

  • "Managing Trusted Certificates"

13.2.3.5 Hardware Security Modules

Oracle Advanced Security uses these devices for the following functions:

• Store cryptographic information, such as private keys

• Perform cryptographic operations to off load RSA operations from the server, freeing the CPU to respond to other transactions

Cryptographic information can be stored on two types of hardware devices:

• (Server-side) Hardware boxes where keys are stored in the box, but managed by using tokens.

• (Client-side) Smart card readers, which support storing private keys on tokens.

An Oracle environment supports hardware devices using APIs that conform to the RSA Security, Inc., Public-Key Cryptography Standards (PKCS) #11 specification.

13.6.2.1 Step 2A: Confirm Wallet Creation on the Server

Before proceeding to the next step, you must confirm that a wallet has been created. To confirm that your wallet is ready, open it by using Oracle Wallet Manager. The wallet should contain a certificate with a status of Ready and auto login turned on. If auto login is not on, then select it from the Wallet menu and save the wallet again. This turns auto login on.

13.6.2.2 Step 2B: Specify the Database Wallet Location on the Server

1. Start Oracle Net Manager.

   • (UNIX) From $ORACLE_HOME/bin, enter the following command at the command line:

     netmgr
     

   • (Windows) Select Start, Programs, Oracle - HOME_NAME, Configuration and Migration Tools, then Net Manager.

2. Expand Oracle Net Configuration, and from Local, select Profile.

3. From the Naming list, select Network Security.

   The Network Security tabbed window appears.

4. Click the SSL tab and select Configure SSL for: Server.

5. In the Wallet Directory box, enter the directory in which the Oracle wallet is located or click Browse to find it by searching the file system.

   Note that if you are configuring the database-to-directory SSL connection for Enterprise User Security, then Database Configuration Assistant automatically creates a database wallet while registering the database with the directory. You must use that wallet to store the database PKI credentials for SSL-authenticated Enterprise User Security.

   Important:

   • Use Oracle Wallet Manager to create the wallet. Refer to "Creating a New Wallet".

   • Use Oracle Net Manager to set the wallet location in the sqlnet.ora file.

   Ensure that you enter the same wallet location when you create it and when you set the location in the sqlnet.ora file.

6. From the File menu, select Save Network Configuration.

   The sqlnet.ora and listener.ora files are updated with the following entries:

   wallet_location = 
    (SOURCE=
     (METHOD=File)
     (METHOD_DATA=
      (DIRECTORY=wallet_location)))
   

13.6.2.3 Step 2C: Set the Secure Sockets Layer Cipher Suites on the Server (Optional)

This section contains:

• About the Secure Sockets Layer Cipher Suites

• Supported Secure Sockets Layer Cipher Suites

• Specifying Secure Sockets Cipher Suites for the Database Server

About the Secure Sockets Layer Cipher Suites

A cipher suite is a set of authentication, encryption, and data integrity algorithms used for exchanging messages between network entities. During an SSL handshake, two entities negotiate to see which cipher suite they will use when transmitting messages back and forth.

When you install Oracle Advanced Security, the SSL cipher suites listed in Table 13-1 are set for you by default and negotiated in the order they are listed. You can override the default order by setting the SSL_CIPHER_SUITES parameter. For example, if you use Oracle Net Manager to add the cipher suite SSL_RSA_WITH_3DES_EDE_CBC_SHA, all other cipher suites in the default setting are ignored.

You can prioritize the cipher suites. When the client negotiates with servers regarding which cipher suite to use, it follows the prioritization you set. When you prioritize the cipher suites, consider the following:

• Compatibility. Server and client must be configured to use compatible cipher suites for a successful connection.

• Cipher priority and strength. Prioritize cipher suites starting with the strongest and moving to the weakest to ensure the highest level of security possible.

• The level of security you want to use. For example, triple-DES encryption is stronger than DES

• The impact on performance. For example, triple-DES encryption is slower than DES.

  Notes:

  Regarding Diffie-Hellman anonymous authentication:

  1. If you set the server to employ this cipher suite, then you must also set the same cipher suite on the client. Otherwise, the connection fails.

  2. If you use a cipher suite employing Diffie-Hellman anonymous, then you must set the SSL_CLIENT_AUTHENTICATION parameter to FALSE. For more information, refer to "Step 2E: Set SSL Client Authentication on the Server (Optional)".

Supported Secure Sockets Layer Cipher Suites

Table 13-1 lists the SSL cipher suites supported in the current release of Oracle Advanced Security. These cipher suites are set by default when you install Oracle Advanced Security. The following table also lists the authentication, encryption, and data integrity types each cipher suite uses.

^Footnote 1 AES ciphers work with Transport Layer Security (TLS 1.0) only

Specifying Secure Sockets Cipher Suites for the Database Server

1. Start Oracle Net Manager.

   • (UNIX) From $ORACLE_HOME/bin, enter the following command at the command line:

     netmgr
     

   • (Windows) Select Start, Programs, Oracle - HOME_NAME, Configuration and Migration Tools, then Net Manager.

2. Expand Oracle Net Configuration, and from Local, select Profile.

3. From the Naming list, select Network Security.

   The Network Security tabbed window appears.

4. Select the SSL tab and then select Configure SSL for: Server.

5. In the Cipher Suite Configuration area, click Add.

   A dialog box displays available cipher suites. To see the US domestic cipher suites, click the Show US Domestic Cipher Suits check box.

6. Select a suite and click OK.

   The Cipher Suite Configuration list is updated:

   
   Description of the illustration ''ssl0004.gif''
   
   

7. Use the up and down arrows to prioritize the cipher suites.

8. From the File menu, select Save Network Configuration.

   The sqlnet.ora file is updated with the following entry:

   SSL_CIPHER_SUITES= (SSL_cipher_suite1 [,SSL_cipher_suite2])
   

13.6.2.4 Step 2D: Set the Required SSL Version on the Server (Optional)

You can set the SSL_VERSION parameter in the sqlnet.ora or the listener.ora file. This parameter defines the version of SSL that must run on the systems with which the server communicates. You can require these systems to use any valid version. The default setting for this parameter in sqlnet.ora is undetermined, which is set by selecting Any from the list in the SSL tab of the Oracle Advanced Security window.

To set the SSL version for the server:

1. In the Require SSL Version list, the default is Any. Accept this default or select the SSL version you want to use.

2. Select File, Save Network Configuration.

   If you chose Any, then the sqlnet.ora file is updated with the following entry:

   SSL_VERSION=UNDETERMINED
   

   Note:

   SSL 2.0 is not supported on the server side.

13.6.2.5 Step 2E: Set SSL Client Authentication on the Server (Optional)

The SSL_CLIENT_AUTHENTICATION parameter in the sqlnet.ora file controls whether the client is authenticated using SSL. The default value is TRUE.

You must set this parameter to FALSE if you are using a cipher suite that contains Diffie-Hellman anonymous authentication (DH_anon). Also, you can set this parameter to FALSE for the client to authenticate itself to the server by using any of the non-SSL authentication methods supported by Oracle Advanced Security, such as Kerberos or RADIUS.

To set SSL_CLIENT_AUTHENTICATION to FALSE on the server:

1. In the SSL page Oracle Net Manager, deselect Require Client Authentication.

   
   Description of the illustration ''ssl0005.gif''
   
   

2. From the File menu, select Save Network Configuration.

   The sqlnet.ora file is updated with the following entry:

   SSL_CLIENT_AUTHENTICATION=FALSE
   

13.6.2.6 Step 2F: Set SSL as an Authentication Service on the Server (Optional)

The SQLNET.AUTHENTICATION_SERVICES parameter in the sqlnet.ora file sets the SSL authentication service.

Set this parameter if you want to use SSL authentication in conjunction with another authentication method supported by Oracle Advanced Security. For example, use this parameter if you want the server to authenticate itself to the client by using SSL and the client to authenticate itself to the server by using Kerberos.

To set the SQLNET.AUTHENTICATION_SERVICES parameter on the server, add TCP/IP with SSL (TCPS) to this parameter in the sqlnet.ora file by using a text editor. For example, if you want to use SSL authentication in conjunction with RADIUS authentication, set this parameter as follows:

 SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)

If you do not want to use SSL authentication in conjunction with another authentication method, then do not set this parameter.

13.6.2.7 Step 2G: Create a Listening Endpoint that Uses TCP/IP with SSL on the Server

Configure the listener with a TCP/IP with SSL listening endpoint in the listener.ora file. Oracle recommends using port number 2484 for typical Oracle Net clients.

13.6.3.1 Step 3A: Confirm Client Wallet Creation

Before proceeding to the next step, you must confirm that a wallet has been created on the client and that the client has a valid certificate.

13.6.3.2 Step 3B: Configure the Server DNs and Use TCP/IP with SSL on the Client

This section contains:

• About Configuring the Server DNS and Using TCP/IP with SSL on the Client

• Configuring the Server DNS and Using TCP/IP with SSL on the Client

About Configuring the Server DNS and Using TCP/IP with SSL on the Client

Next, you are ready to configure the Oracle Net Service name to include the server DNs and to use TCP/IP with SSL on the client. You must specify the server's distinguished name (DN) and TCPS as the protocol in the client network configuration files to enable server DN matching and TCP/IP with SSL connections. Server DN matching prevents the database server from faking its identity to the client during connections by matching the server's global database name against the DN from the server certificate.

You must manually edit the client network configuration files, tnsnames.ora and listener.ora, to specify the server's DN and the TCP/IP with SSL protocol. The tnsnames.ora file can be located on the client or in the LDAP directory. If it is located on the client, then it typically resides in the same directory as the listener.ora file. Depending on the operating system, these files reside in the following directory locations:

• (UNIX) $ORACLE_HOME/network/admin/

• (Windows) ORACLE_BASE\ORACLE_HOME\network\admin\

Configuring the Server DNS and Using TCP/IP with SSL on the Client

1. In the client tnsnames.ora file, add the SSL_SERVER_CERT_DN parameter and specify the database server's DN as follows:

   (SECURITY=
   (SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=acme"))
   

   The client uses this information to obtain the list of DNs it expects for each of the servers, enforcing the server's DN to match its service name. Example 13-1 shows an entry for the Finance database in the tnsnames.ora file.

   Alternatively, the administrator can ensure that the common name (CN) portion of the server's DN matches the service name.

2. In the client tnsnames.ora file, enter tcps as the PROTOCOL in the ADDRESS parameter. This specifies that the client will use TCP/IP with SSL to connect to the database that is identified in the SERVICE_NAME parameter. Example 13-1 also shows an entry that specifies TCP/IP with SSL as the connecting protocol in the tnsnames.ora file.

3. In the listener.ora file, enter tcps as the PROTOCOL in the ADDRESS parameter. Example 13-2 shows an entry that specifies TCP/IP with SSL as the protocol.

finance=
(DESCRIPTION=

(ADDRESS_LIST=

(ADDRESS= (PROTOCOL = tcps) (HOST = finance_server) (PORT = 1575)))

(CONNECT_DATA=

(SERVICE_NAME= Finance.us.example.com))

(SECURITY=

(SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=acme"))

LISTENER=

(DESCRIPTION_LIST=

(DESCRIPTION=

(ADDRESS= (PROTOCOL = tcps) (HOST = finance_server) (PORT = 1575))))

13.6.3.3 Step 3C: Specify Required Client SSL Configuration (Wallet Location)

1. Start Oracle Net Manager.

   • (UNIX) From $ORACLE_HOME/bin, enter the following command at the command line:

     netmgr
     

   • (Windows) Select Start, Programs, Oracle - HOME_NAME, Configuration and Migration Tools, then Net Manager.

2. Expand Oracle Net Configuration, and from Local, select Profile.

3. From the Naming list, select Network Security.

   The Network Security tabbed window appears.

4. Select the SSL tab.

5. Select Configure SSL for: Client.

   
   Description of the illustration ''ssl0001.gif''
   
   

6. In the Wallet Directory box, enter the directory in which the Oracle wallet is located, or click Browse to find it by searching the file system.

7. From the Match server X.509 name list, select one of the following options:

   • Yes: Requires that the server's distinguished name (DN) match its service name. SSL ensures that the certificate is from the server and connections succeed only if there is a match.

     This check can be made only when RSA ciphers are selected, which is the default setting.

   • No (default): SSL checks for a match between the DN and the service name, but does not enforce it. Connections succeed regardless of the outcome but an error is logged if the match fails.

   • Let Client Decide: Enables the default.

     The following alert is displayed when you select No:

     Security Alert
     Not enforcing the server X.509 name match allows a server to potentially fake its identity. Oracle recommends selecting YES for this option so that connections are refused when there is a mismatch.
     

8. From the File menu, select Save Network Configuration.

   The sqlnet.ora file on the client is updated with the following entries:

   SSL_CLIENT_AUTHENTICATION =TRUE
   wallet_location = 
    (SOURCE=
     (METHOD=File)
     (METHOD_DATA=
      (DIRECTORY=wallet_location)))
   
   SSL_SERVER_DN_MATCH=(ON/OFF)
   

13.6.3.4 Step 3D: Set the Client Secure Sockets Layer Cipher Suites (Optional)

This section contains:

• About Setting the Client Secure Sockets Layer Cipher Suites

• Setting the Client Secure Sockets Layer Cipher Suites

About Setting the Client Secure Sockets Layer Cipher Suites

A cipher suite is a set of authentication, encryption, and data integrity algorithms used for exchanging messages between network entities. During an SSL handshake, two entities negotiate to see which cipher suite they will use when transmitting messages back and forth.

When you install Oracle Advanced Security, the SSL cipher suites listed in Table 13-1 are set for you by default. This table lists them in the order they are tried when two entities are negotiating a connection. You can override the default by setting the SSL_CIPHER_SUITES parameter. For example, if you use Oracle Net Manager to add the cipher suite SSL_RSA_WITH_3DES_EDE_CBC_SHA, all other cipher suites in the default setting are ignored.

You can prioritize the cipher suites. When the client negotiates with servers regarding which cipher suite to use, it follows the prioritization you set. When you prioritize the cipher suites, consider the following:

• The level of security you want to use. For example, triple-DES encryption is stronger than DES.

• The impact on performance. For example, triple-DES encryption is slower than DES. Refer to "Configuring Your System to Use Hardware Security Modules" for information about using SSL hardware accelerators with Oracle Advanced Security.

• Administrative requirements. The cipher suites selected for a client must be compatible with those required by the server. For example, in the case of an Oracle Call Interface (OCI) user, the server requires the client to authenticate itself. You cannot, in this case, use a cipher suite employing Diffie-Hellman anonymous authentication, which disallows the exchange of certificates.

You typically prioritize cipher suites starting with the strongest and moving to the weakest.

Table 13-1 lists the SSL cipher suites that are supported in the current release of Oracle Advanced Security. These cipher suites are set by default when you install Oracle Advanced Security. The table also lists the authentication, encryption, and data integrity types each cipher suite uses.

Setting the Client Secure Sockets Layer Cipher Suites

1. Start Oracle Net Manager.

   • (UNIX) From $ORACLE_HOME/bin, enter the following command at the command line:

     netmgr
     

   • (Windows) Select Start, Programs, Oracle - HOME_NAME, Configuration and Migration Tools, then Net Manager.

2. Expand Oracle Net Configuration, and from Local, select Profile.

3. From the Naming list, select Network Security.

   The Network Security tabbed window appears.

4. Select the SSL tab.

5. In the Cipher Suite Configuration region, click Add.

   A dialog box displays available cipher suites.

6. Select a suite and click OK.

   The Cipher Suite Configuration list is updated as follows:

   
   Description of the illustration ''ssl0003.gif''
   
   

7. Use the up and down arrows to prioritize the cipher suites.

8. Select File, Save Network Configuration.

   The sqlnet.ora file is updated with the following entry:

   SSL_CIPHER_SUITES= (SSL_cipher_suite1 [,SSL_cipher_suite2])
   

13.6.3.5 Step 3E: Set the Required SSL Version on the Client (Optional)

You can set the SSL_VERSION parameter in the sqlnet.ora file. This parameter defines the version of SSL that must run on the systems with which the client communicates. You can require these systems to use any valid version. The default setting for this parameter in sqlnet.ora is undetermined, which is set by selecting Any from the list in the SSL tab of the Oracle Advanced Security window. When Any is selected, TLS 1.0 is tried first, then SSL 3.0, and SSL 2.0 are tried in that order. Ensure that the client SSL version is compatible with the version the server uses.

To set the required SSL version for the client:

1. In the Require SSL Version list, the default setting is Any. Accept this default or select the SSL version you want to configure.

2. Select File, Save Network Configuration.

   The sqlnet.ora file is updated. If you selected Any, then it is updated with the following entry:

   SSL_VERSION=UNDETERMINED
   

13.6.3.6 Step 3F: Set SSL as an Authentication Service on the Client (Optional)

The SQLNET.AUTHENTICATION_SERVICES parameter in the sqlnet.ora file sets the SSL authentication service. Typically, the sqlnet.ora file is located in the same directory as the other network configuration files. Depending on the platform, the sqlnet.ora file is in the following directory location:

• (UNIX) $ORACLE_HOME/network/admin

• (Windows) ORACLE_BASE\ORACLE_HOME\network\admin\

Set the SQLNET.AUTHENTICATION_SERVICES parameter if you want to use SSL authentication in conjunction with another authentication method supported by Oracle Database. For example, use this parameter if you want the server to authenticate itself to the client by using SSL and the client to authenticate itself to the server by using RADIUS.

To set the client SQLNET.AUTHENTICATION_SERVICES parameter, add TCP/IP with SSL (TCPS) to this parameter in the sqlnet.ora file by using a text editor. For example, if you want to use SSL authentication in conjunction with RADIUS authentication, then set this parameter as follows:

 SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)

If you do not want to use SSL authentication in conjunction with another authentication method, then do not set this parameter.

13.6.3.7 Step 3G: Specify the Certificate to Use for Authentication on the Client (Optional)

The SQLNET.SSL_EXTENDED_KEY_USAGE parameter in the sqlnet.ora file specifies which certificate to use in authenticating to the database server. Typically, the sqlnet.ora file is located in the same directory as the other network configuration files. Depending on the platform, the sqlnet.ora file is in one of the following directory locations:

• (UNIX) $ORACLE_HOME/network/admin

• (Windows) ORACLE_BASE\ORACLE_HOME\network\admin\

Set the SQLNET.SSL_EXTENDED_KEY_USAGE parameter if you have multiple certificates in the security module, but there is only one certificate with extended key usage field of client authentication, and this certificate is exactly the one you want to use to authenticate to the database. For example, use this parameter if you have multiple certificates in a smart card, only one of which has an extended key usage field of client authentication, and you want to use this certificate C to authenticate to the database. By setting this parameter on a Windows client to client authentication, the MSCAPI certificate selection box will not appear, and the certificate C is automatically used for the SSL authentication of the client to the server.

To set the client SQLNET.SSL_EXTENDED_KEY_USAGE parameter, edit the sqlnet.ora file to have the following line:

SQLNET.SSL_EXTENDED_KEY_USAGE = "client authentication"

If you do not want to use the certificate filtering, then remove the SQLNET.SSL_EXTENDED_KEY_USAGE parameter setting from the sqlnet.ora file.

13.8.4.1 About Configuring Certificate Validation with Certificate Revocation Lists

The SSL_CERT_REVOCATION parameter must be set to REQUIRED or REQUESTED in the sqlnet.ora file to enable certificate revocation status checking. By default this parameter is set to NONE indicating that certificate revocation status checking is turned off.

13.8.4.2 Enabling Certificate Revocation Status Checking for the Client or Server

1. Start Oracle Net Manager.

   • (UNIX) From $ORACLE_HOME/bin, enter the following command at the command line:

     netmgr
     

   • (Windows) Select Start, Programs, Oracle - HOME_NAME, Configuration and Migration Tools, then Net Manager.

2. Expand Oracle Net Configuration, and from Local, select Profile.

3. From the Naming list, select Network Security.

   The Network Security tabbed window appears.

4. Select the SSL tab.

5. Select one of the following options from the Revocation Check list:

   
   Description of the illustration ''ssl0006.gif''
   
   

   • REQUIRED

     Requires certificate revocation status checking. The SSL connection is rejected if a certificate is revoked or no CRL is found. SSL connections are accepted only if it can be verified that the certificate has not been revoked.

   • REQUESTED

     Performs certificate revocation status checking if a CRL is available. The SSL connection is rejected if a certificate is revoked. SSL connections are accepted if no CRL is found or if the certificate has not been revoked.

     For performance reasons, only user certificates are checked for revocation.

6. (Optional) If CRLs are stored on your local file system, then set one or both of the following fields that specify where they are stored. These fields are available only when Revocation Check is set to REQUIRED or REQUESTED.

   • Certificate Revocation Lists Path:

     Enter the path to the directory where CRLs are stored or click Browse to find it by searching the file system. Specifying this path sets the SSL_CRL_PATH parameter in the sqlnet.ora file. If a path is not specified for this parameter, then the default is the wallet directory. Both DER-encoded (binary format) and PEM-encoded (BASE64) CRLs are supported.

   • Certificate Revocation Lists File:

     Enter the path to a comprehensive CRL file (where PEM-encoded (BASE64) CRLs are concatenated in order of preference in one file) or click Browse to find it by searching the file system. Specifying this file sets the SSL_CRL_FILE parameter in the sqlnet.ora file. If this parameter is set, then the file must be present in the specified location, or else the application will error out during startup.

     If you want to store CRLs in a local file system directory by setting the Certificate Revocation Lists Path, then you must use the orapki utility to rename them so the system can locate them. See "Renaming CRLs with a Hash Value for Certificate Validation" for more information.

7. (Optional) If CRLs are fetched from Oracle Internet Directory, then directory server and port information must be specified in an ldap.ora file.

   When configuring your ldap.ora file, you should specify only a non-SSL port for the directory. CRL download is done as part of the SSL protocol, and making an SSL connection within an SSL connection is not supported.

   Oracle Advanced Security CRL functionality will not work if the Oracle Internet Directory non-SSL port is disabled.

8. From the File menu, select Save Network Configuration.

   The sqlnet.ora file is updated.

13.8.4.3 Disabling Certificate Revocation Status Checking

1. Start Oracle Net Manager.

   • (UNIX) From $ORACLE_HOME/bin, enter the following command at the command line:

     netmgr
     

   • (Windows) Select Start, Programs, Oracle - HOME_NAME, Configuration and Migration Tools, then Net Manager.

2. Expand Oracle Net Configuration, and from Local, select Profile.

3. From the Naming list, select Network Security.

   The Network Security tabbed window appears.

4. Select the SSL tab.

5. Select NONE from the Revocation Check list.

6. From the File menu, select Save Network Configuration.

   The sqlnet.ora file is updated with the following entry:

   SSL_CERT_REVOCATION=NONE
   

13.8.5.1 About Certificate Revocation Management

Before you can enable certificate revocation status checking, you must ensure that the CRLs you receive from the CAs you use are in a form (renamed with a hash value) or in a location (uploaded to the directory) where your computer can use them. Oracle Advanced Security provides a command-line utility, orapki, that you can use to perform the tasks described in this section.

You can also use LDAP command-line tools to manage CRLs in Oracle Internet Directory.

13.8.5.2 Displaying orapki Help for Commands That Manage CRLs

You can display all the orapki commands that are available for managing CRLs by entering the following at the command line:

orapki crl help

This command displays all available CRL management commands and their options.

13.8.5.3 Renaming CRLs with a Hash Value for Certificate Validation

When the system validates a certificate, it must locate the CRL issued by the CA who created the certificate. The system locates the appropriate CRL by matching the issuer name in the certificate with the issuer name in the CRL.

When you specify a CRL storage location for the Certificate Revocation Lists Path field in Oracle Net Manager, which sets the SSL_CRL_PATH parameter in the sqlnet.ora file, use the orapki utility to rename CRLs with a hash value that represents the issuer's name. Creating the hash value enables the server to load the CRLs.

On UNIX operating systems, orapki creates a symbolic link to the CRL. On Windows operating systems, it creates a copy of the CRL file. In either case, the symbolic link or the copy created by orapki are named with a hash value of the issuer's name. Then when the system validates a certificate, the same hash function is used to calculate the link (or copy) name so the appropriate CRL can be loaded.

Depending on the operating system, enter one of the following commands to rename CRLs stored in the file system.

To rename CRLs stored in UNIX file systems:

orapki crl hash -crl crl_filename [-wallet wallet_location] -symlink crl_directory [-summary]

To rename CRLs stored in Windows file systems:

orapki crl hash -crl crl_filename [-wallet wallet_location] -copy crl_directory [-summary]

In this specification, crl_filename is the name of the CRL file, wallet_location is the location of a wallet that contains the certificate of the CA that issued the CRL, and crl_directory is the directory where the CRL is located.

Using -wallet and -summary are optional. Specifying -wallet causes the tool to verify the validity of the CRL against the CA's certificate prior to renaming the CRL. Specifying the -summary option causes the tool to display the CRL issuer's name.

13.8.5.4 Uploading CRLs to Oracle Internet Directory

Publishing CRLs in the directory enables CRL validation throughout your enterprise, eliminating the need for individual applications to configure their own CRLs. All applications can use the CRLs stored in the directory where they can be centrally managed, greatly reducing the administrative overhead of CRL management and use.

The user who uploads CRLs to the directory by using orapki must be a member of the directory group CRLAdmins (cn=CRLAdmins,cn=groups,%s_OracleContextDN%). This is a privileged operation because these CRLs are accessible to the entire enterprise. Contact your directory administrator to get added to this administrative directory group.

To upload CRLs to the directory, enter the following at the command line:

orapki crl upload -crl crl_location -ldap hostname:ssl_port -user username [-wallet wallet_location] [-summary]

In this specification, crl_location is the file name or URL where the CRL is located, hostname and ssl_port (SSL port with no authentication) are for the system on which your directory is installed, username is the directory user who has permission to add CRLs to the CRL subtree, and wallet_location is the location of a wallet that contains the certificate of the CA that issued the CRL.

Using -wallet and -summary are optional. Specifying -wallet causes the tool to verify the validity of the CRL against the CA's certificate prior to uploading it to the directory. Specifying the -summary option causes the tool to print the CRL issuer's name and the LDAP entry where the CRL is stored in the directory.

The following example illustrates uploading a CRL with the orapki utility:

orapki crl upload -crl /home/user1/wallet/crldir/crl.txt -ldap host1.example.com:3533 -user cn=orcladmin

13.8.5.5 Listing CRLs Stored in Oracle Internet Directory

You can display a list of all CRLs stored in the directory with orapki, which is useful for browsing to locate a particular CRL to view or download to your local computer. This command displays the CA who issued the CRL (Issuer) and its location (DN) in the CRL subtree of your directory.

To list CRLs in Oracle Internet Directory, enter the following at the command line:

orapki crl list -ldap hostname:ssl_port

where the hostname and ssl_port are for the system on which your directory is installed. Note that this is the directory SSL port with no authentication as described in the preceding section.

13.8.5.6 Viewing CRLs in Oracle Internet Directory

You can view specific CRLs that are stored in Oracle Internet Directory in a summarized format or you can request a complete listing of revoked certificates for the specified CRL. A summary listing provides the CRL issuer's name and its validity period. A complete listing provides a list of all revoked certificates contained in the CRL.

To view a summary listing of a CRL in Oracle Internet Directory, enter the following at the command line:

orapki crl display -crl crl_location [-wallet wallet_location] -summary

where crl_location is the location of the CRL in the directory. It is convenient to paste the CRL location from the list that displays when you use the orapki crl list command. Refer to, "Listing CRLs Stored in Oracle Internet Directory".

To view a list of all revoked certificates contained in a specified CRL, which is stored in Oracle Internet Directory, enter the following at the command line:

orapki crl display -crl crl_location [-wallet wallet_location] -complete

For example, the following orapki command:

orapki crl display -crl $T_WORK/pki/wlt_crl/nzcrl.txt -wallet $T_WORK/pki/wlt_crl -complete

produces the following output, which lists the CRL issuer's DN, its publication date, date of its next update, and the revoked certificates it contains:

issuer = CN=root,C=us, thisUpdate = Sun Nov 16 10:56:58 PST 2003, nextUpdate = Mon Sep 30 11:56:58 PDT 2013, revokedCertificates = {(serialNo = 153328337133459399575438325845117876415, revocationDate - Sun Nov 16 10:56:58 PST 2003)}
CRL is valid

Using the -wallet option causes the orapki crl display command to validate the CRL against the CA's certificate.

Depending on the size of your CRL, choosing the -complete option may take a long time to display.

You can also use Oracle Directory Manager, a graphical user interface tool that is provided with Oracle Internet Directory, to view CRLs in the directory. CRLs are stored in the following directory location:

cn=CRLValidation,cn=Validation,cn=PKI,cn=Products,cn=OracleContext

13.8.5.7 Deleting CRLs from Oracle Internet Directory

The user who deletes CRLs from the directory by using orapki must be a member of the directory group CRLAdmins. Refer to "Uploading CRLs to Oracle Internet Directory" for information about this directory administrative group.

To delete CRLs from the directory, enter the following at the command line:

orapki crl delete -issuer issuer_name -ldap host:ssl_port -user username [-summary]

where issuer_name is the name of the CA who issued the CRL, the hostname and ssl_port are for the system on which your directory is installed, and username is the directory user who has permission to delete CRLs from the CRL subtree. Ensure that this must be a directory SSL port with no authentication. Refer to, "Uploading CRLs to Oracle Internet Directory" for more information about this port.

Using the -summary option causes the tool to print the CRL LDAP entry that was deleted.

For example, the following orapki command:

orapki crl delete -issuer "CN=root,C=us" -ldap machine1:3500 -user cn=orcladmin -summary

produces the following output, which lists the location of the deleted CRL in the directory:

Deleted CRL at cn=root cd45860c.rN,cn=CRLValidation,cn=Validation,cn=PKI,cn=Products,cn=OracleContext

13.8.6.1 Oracle Net Tracing File Error Messages Associated with Certificate Validation

The following trace messages, relevant to certificate validation, may be logged between the entry and exit entries in the Oracle Net tracing file. Oracle SSL looks for CRLs in multiple locations, so there may be multiple errors in the trace.

Check the following list of possible error messages for information about how to resolve them.

13.9.3.1 About Configuring Your System to Use nCipher Hardware Security Modules

Hardware security modules made by nCipher Corporation are certified to operate with Oracle Advanced Security. These modules provide a secure way to store keys and off-load cryptographic processing. Primarily, these devices provide the following benefits:

• Off-load cryptographic processing that frees your server to respond to other requests

• Secure private key storage on the device

• Allow key administration through the use of smart cards

  Note:

  You must contact your nCipher representative to obtain certified hardware and software to use with Oracle Advanced Security.

13.9.3.2 Oracle Components Required To Use an nCipher Hardware Security Module

To use an nCipher hardware security module, you need the following components:

• nCipher Hardware Security Module

• Supporting nCipher PKCS #11 library

  The following platform-specific PKCS#11 library is required:

  • libcknfast.so library for UNIX 32-Bit

  • libcknfast-64.so library for UNIX 64-Bit

  • cknfast.dll library for Windows

    Note:

    You must contact your nCipher representative to have the hardware security module or the secure accelerator installed, and to acquire the necessary library.

    These tasks must be performed before you can use an nCipher hardware security module with Oracle Advanced Security.

13.9.3.3 About Installing an nCipher Hardware Security Module

To use the secure accelerator, you must provide the absolute path to the directory that contains the nCipher PKCS #11 library (including the library name) when you create the wallet by using Oracle Wallet Manager. This enables the library to be loaded at runtime. Typically, the nCipher card is installed at the following locations:

• /opt/nfast for UNIX

• C:\nfast for Windows

The nCipher PKCS #11 library is located at the following location for typical installations:

• /opt/nfast/toolkits/pkcs11/libcknfast.so for UNIX 32-Bit

• /opt/nfast/toolkits/pkcs11/libcknfast-64.so for UNIX 64-Bit

• C:\nfast\toolkits\pkcs11\cknfast.dll for Windows

  Note:

  Use the 32-bit library version when using the 32-bit release of Oracle Database and use the 64-bit library version when using the 64-bit release of Oracle Database. For example, use the 64-bit nCipher PKCS #11 library for the Oracle Database for Solaris Operating System (SPARC 64-bit).

13.9.4.1 About Configuring Your System to Use SafeNet Hardware Security Modules

Hardware security modules made by SafeNET Incorporated are certified to operate with Oracle Advanced Security. These modules provide a secure way to store keys and off-load cryptographic processing. Primarily, these devices provide the following benefits:

• Off-load of cryptographic processing to free your server to respond to more requests

• Secure private key storage on the device

  Note:

  You must contact your SafeNET representative to obtain certified hardware and software to use with Oracle Advanced Security.

13.9.4.2 Oracle Components for the SafeNET Luna SA Hardware Security Module

To use a SafeNET Luna SA hardware security module, you must have the following components

• SafeNET Luna SA Hardware Security Module

• Supporting SafeNET Luna SA PKCS #11 library

  The following platform-specific PKCS#11 library is required:

  • libCryptoki2.so library for UNIX

  • cryptoki.dll library for Windows

13.9.4.3 About Installing a SafeNET Hardware Security Module

To use the secure accelerator, you must provide the absolute path to the directory that contains the SafeNET PKCS #11 library (including the library name) when you create the wallet using Oracle Wallet Manager. This enables the library to be loaded at runtime. Typically, the SafeNET Luna SA client is installed at the following location:

• /usr/lunasa for UNIX

• C:\Program Files\LunaSA for Windows

The SafeNET Luna SA PKCS #11 library is located at the following location for typical installations:

• /usr/lunasa/lib/libCryptoki2.so for UNIX

• C:\Program Files\LunaSA\cryptoki2.dll for Windows

13.9.5.1 Errors in the Oracle Net Trace Files

To detect whether the module is being used, you can turn on Oracle Net tracing. If the wallet contains PKCS #11 information and the private key on the module is being used, then you will see the following entries in the Oracle Net tracing file without error messages logged between entry and exit:

nzpkcs11_Init: entry
nzpkcs11CP_ChangeProviders: entry
nzpkcs11CP_ChangeProviders: exit
nzpkcs11GPK_GetPrivateKey: entry
nzpkcs11GPK_GetPrivateKey: exit
nzpkcs11_Init: exit
...
nzpkcs11_Decrypt: entry
nzpkcs11_Decrypt: exit

nzpkcs11_Sign: entry
nzpkcs11_Sign: exit

13.9.5.2 Error Messages Associated with Using Hardware Security Modules

The following errors are associated with using PKCS #11 hardware security modules:

13.10.3.1 Creating the SSL Certificate for Each Cluster and for the Test Client

1. Create a directory to be used as the CA home. Restrict access of the CA home to the user or group of users that can authorize and sign digital certificates.

   For example:

   cd $ORACLE_BASE
   mkdir CA; chmod 700 CA; cd CA;
   pwd
   /home/app/oracle/CA
   
   export CA_HOME=/home/app/oracle/CA
   

2. In the CA home, use orapki to create the Certificate Authority wallet.

   orapki wallet create -wallet $CA_HOME
   
   Enter password: CA_password
   Enter password again: CA_password
   

   The orapki utility creates a default wallet that is populated with several well known trusted certificates. You do not need these certificates for this procedure, so you can remove them as follows:

   orapki wallet remove -trusted_cert_all -wallet $CA_HOME -pwd [CA_password]
   

3. Create a self signed (root) certificate for the CA wallet.

   For example:

   orapki wallet add -wallet $CA_HOME -self_signed -dn "CN=Oracle test CA,O=Oracle,C=US" -keysize 1024 -validity 3650 -pwd [CA_password]
   

   In this specification:

   • dn refers to the distinguished name, which can be any valid x509 formated name (for example, -dn CN=Widget Corp.,C=US).

   • keysize sets the bit size of the key. The following values are valid: 512, 1024, or 2048.

   • validity, which is mandatory, specifies the number of days, starting from the current date, that this certificate will be valid.

4. Extract the root CA certificate from the wallet.

   This root certificate will be used as the trusted CA certificate in user or application wallets and can be distributed or published for users that are building PKCS12 wallets.

   For example:

   orapki wallet export -wallet $CA_HOME -dn "CN=Oracle test CA,O=Oracle,C=US" -cert testCAroot.cer -pwd [CA_password]
   

   At this stage, the $CA_HOME now contains an ewallet.p12 (the PKCS12 wallet) and a testCAroot.cer base64 certificate.

   ls -al
   
   total 16
   drwx------  2 psmith psmith 4096 Aug 23 15:15 .
   drwxrwxr-x 11 psmith psmith 4096 Aug 23 13:54 ..
   -rw-------  1 psmith psmith 2560 Aug 23 15:13 ewallet.p12
   -rw-------  1 psmith psmith  706 Aug 23 15:15 testCAroot.cer
   

5. Ensure that the wallet was successfully created.

   For example:

   orapki wallet display -wallet $CA_HOME -summary
   Enter wallet password: CA_password
    
   Requested Certificates:
   User Certificates:
   Subject:        CN=Oracle test CA,O=Oracle,C=US
   Trusted Certificates:
   Subject:        CN=Oracle test CA,O=Oracle,C=US
   

6. Back up the wallet and password.

13.10.3.2 Signing Each User Certificate

Using the CA wallet, the orapki utility can be used to sign digital certificate requests and provide authorized digital user certificates for different entities and processes in test environments. Repeat this process for each entity in the test environment that participates in PKI functionality. A valid wallet consists of a root CA certificate and the signed user certificate.

1. Create a user wallet in a directory or location outside of the CA home.

   For example:

   cd ~
   mkdir user_wallet; cd user_wallet
   pwd
   
   /home/user_wallet
   
   export MY_WALLET=/home/user_wallet
   orapki wallet create -wallet $MY_WALLET
   
   Enter password: user_password
   Enter password again: user_password
   

   The orapki utility creates a wallet with several well known trusted certificates already installed. You do not need these certificates for this procedure, so you can remove them as follows:

   orapki wallet remove -trusted_cert_all -wallet $MY_WALLET -pwd [user_password]
   

2. Create a user identity (user DN) and then a certificate request.

   For example:

   orapki wallet add -wallet $USER_WALLET -dn "CN=testuser" -keysize 1024 -pwd [user_password]
   orapki wallet export -wallet $USER_WALLET -dn "CN=testuser" -request $USER_WALLET/testuser.req -pwd [user_password]
   ls
   ewallet.p12 testuser.req
   

   At this stage, the testuser request can now be signed by the CA. Access to the CA home wallet and CA wallet password are needed for this step. After testuser.req is signed, then the output file testuser.cer is created.

3. Create the signed certificate.

   For example:

   orapki cert create -wallet $CA_HOME -request $MY_WALLET/testuser.req -cert $USER_WALLET/testuser.cer -validity 3650 -pwd [CA_password]
   
   ls
   ewallet.p12  testuser.cer  testuser.req
   

4. Import the root certificate (testCAroot.cer) and the signed user certificate (testuser.cer) into the user wallet.

   The following example retrieves the root certificate from the $CA_HOME. Alternative, you can copy the certificate to the user's wallet directory and then import it locally.

   orapki wallet add -wallet $USER_WALLET -trusted_cert -cert $CA_HOME/testCAroot.cer -pwd [user_password]
    
   orapki wallet add -wallet $USER_WALLET -user_cert -cert $USER_WALLET/testuser.cer -pwd [user_password]
   

5. Check the completed wallet.

   For example:

   orapki wallet display -wallet $MY_WALLET -summary -pwd [user_password]
    
   Requested Certificates:
   User Certificates:
   Subject:        CN=testuser
   Trusted Certificates:
   Subject:        CN=Oracle test CA,O=Oracle,C=US