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 Database automatically installs trusted certificates from VeriSign, RSA, Entrust, and GTE CyberTrust when you create a new wallet.

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. (A certificate chain is an ordered list of certificates containing an end-user or subscriber certificate and its certificate authority certificate.) 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.

When a CA signs a certificate binding a public key pair to a user identity, the certificate is valid for a specified 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 in this order:

1. Local file system

2. Oracle Internet Directory

3. CRL Distribution Point (CRL DP), a location specified in the CRL Distribution Point (CRL DP) X.509, version 3, certificate extension when the certificate is issued. A CRL DP is an optional extension specified by the X.509 version 3 certificate standard, which indicates the location of the Partitioned CRL where revocation information for a certificate is stored. Typically, the value in this extension is in the form of a URL. CRL DPs allow revocation information within a single certificate authority domain to be posted in multiple CRLs. CRL DPs subdivide revocation information into more manageable pieces to avoid proliferating voluminous CRLs, thereby providing performance benefits. For example, a CRL DP is specified in the certificate and can point to a file on a Web server from which that certificate's revocation information can be downloaded.

A wallet is a container that stores authentication and signing credentials, including private keys, certificates, and trusted certificates SSL needs.

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

  See Also:

  • Oracle Database Enterprise User Security Administrator's Guide for information about Oracle Wallet Manager

  • Oracle Database Enterprise User Security Administrator's Guide for information about creating a new Oracle wallet

  • Oracle Database Enterprise User Security Administrator's Guide for information about managing trusted certificates in Oracle wallets

The hardware security modules for SSL include devices to handle various functions and hardware devices to store cryptographic information.

Oracle Database 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.

Before proceeding to the next step, confirm that a wallet has been created and that it has a certificate.

1. Start Oracle Wallet Manager.

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

     owm
     

   • (Windows) Select Start, Programs, Oracle-HOME_NAME, Integrated Management Tools, Wallet Manager

   Oracle Wallet Manager is deprecated with Oracle Database 21c. Instead of using Oracle Wallet Manager, Oracle recommends that you use the command line tools orapki and mkstore.

2. From the Wallet menu, select Open.

   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.

Next, you are ready to specify a location on the server for the wallet.

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 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. (Oracle Wallet Manager is deprecated with Oracle Database 21c. Instead of using Oracle Wallet Manager, Oracle recommends that you use the command line tools orapki and mkstore.)

   • Use Oracle Net Manager to set the wallet location in the sqlnet.ora file. Be aware that the settings in the sqlnet.ora file apply to all pluggable databases (PDBs).

   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)))

Optionally, you can set the Secure Sockets Layer cipher suites.

• 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.
• SSL Cipher Suite Authentication, Encryption, Integrity, and TLS Versions
  Oracle Database supports a set of cipher suites that are set by default when you install Oracle Database.
• Specifying Secure Sockets Cipher Suites for the Database Server
  First, you must specify the Secure Sockets cipher suites for the database server.

The SSL_VERSION parameter defines the version of SSL that must run on the systems with which the server communicates.

1. In the Require SSL Version list, the default is Any.

   Accept this default or select the SSL version you want to use.

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

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

   SSL_VERSION=UNDETERMINED

The SSL_CLIENT_AUTHENTICATION parameter controls whether the client is authenticated using SSL.

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

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

You can configure a listening endpoint to use TCP/IP with SSL on the server.

• Configure the listener in the listener.ora file. Oracle recommends using port number 2484 for typical Oracle Net clients.

You must confirm that a wallet has been created on the client and that the client has a valid certificate.

• Use Oracle Wallet Manager to check that the wallet has been created by selecting the Wallet menu, then Open.
  Oracle recommends that you use Oracle Wallet Manager to remove the trusted certificate in your Oracle wallet that is associated with each certificate authority that you do not use. (Oracle Wallet Manager is deprecated with Oracle Database 21c. Instead of using Oracle Wallet Manager, Oracle recommends that you use the command line tools orapki and mkstore.)

Next, you are ready to configure server DN matching and use TCP/IP with Secure Sockets Layer (SSL) on the client.

• About Configuring the Server DN Matching and Using TCP/IP with SSL on the Client
  In addition to validating the server certificate's certificate chain, you can perform an extra check through server DN matching.
• Configuring the Server DN Matching and Using TCP/IP with SSL on the Client
  You must edit the tnsnames.ora and listener.ora files to configure the server DN matching and user TCP/IP with SSL on the client.

You can use Oracle Net Manager to specify the required client SSL configuration.

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)

Optionally, you can set the SSL cipher suites. Oracle Database provides default cipher suite settings.

• 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.
• Setting the Client Secure Sockets Layer Cipher Suites
  You can use Oracle Net Manager to set the client SSL cipher suites.

The SSL_VERSION parameter defines the version of SSL that must run on the systems with which the client communicates.

1. In the Require SSL Version list, select the SSL version that you want to configure.

   The default setting is Any.

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

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

   SSL_VERSION=UNDETERMINED

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

• About the SQLNET.AUTHENTICATION_SERVICES Parameter
  The SQLNET.AUTHENTICATION_SERVICES parameter enables SSL authentication in conjunction with another authentication method supported by Oracle Database.
• Setting the SQLNET.AUTHENTICATION_SERVICES Parameter
  You can set the SQLNET.AUTHENTICATION_SERVICES parameter in the sqlnet.ora file.

If you have multiple certificates, then you can set the SQLNET.SSL_EXTENDED_KEY_USAGE parameter in the sqlnet.ora file to specify the correct certificate.

• About the SQLNET.SSL_EXTENDED_KEY_USAGE Parameter
  The SQLNET.SSL_EXTENDED_KEY_USAGE parameter in the sqlnet.ora file specifies which certificate to use in authenticating to the database server
• Setting the SQLNET.SSL_EXTENDED_KEY_USAGE Parameter
  You can set the SQLNET.SSL_EXTENDED_KEY_USAGE to set the client authentication.

The SSL_CERT_REVOCATION parameter must be set to REQUIRED or REQUESTED in the sqlnet.ora file to enable certificate revocation status checking.

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.

You can enable certificate the revocation status checking for a client or a 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.

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 Database CRL functionality will not work if the Oracle Internet Directory non-SSL port is disabled.

8. Select File, Save Network Configuration. The sqlnet.ora file is updated.

You can disable 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

Oracle Database provides a command-line utility, orapki, that you can use to manage certificates.

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.

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

You can display all the orapki commands that are available for managing CRLs.

When the system validates a certificate, it must locate the CRL issued by the CA who created the certificate.

Publishing CRLs in the directory enables CRL validation throughout your enterprise, eliminating the need for individual applications to configure their own CRLs.

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

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.

Oracle Internet Directory CRLS are available in a summarized format; you also can request a listing of revoked certificates for a 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
  

  In this specification, 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.

  To view a list of all revoked certificates contained in a specified CRL, which is stored in Oracle Internet Directory, you can 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

The user who deletes CRLs from the directory by using orapki must be a member of the directory group CRLAdmins.

• 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]

  In this specification, 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.

  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

Hardware security modules made by nCipher Corporation are certified to operate with Oracle Database.

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

To use an nCipher hardware security module, you must have a special set of components.

These components are as follows:

• 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

The nCipher hardware security module uses the nCipher PKCS #11 library.

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.

Oracle Wallet Manager is deprecated with Oracle Database 21c. Instead of using Oracle Wallet Manager, Oracle recommends that you use the command line tools orapki and mkstore.

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

Hardware security modules made by SafeNET Incorporated are certified to operate with Oracle Database.

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

To use a SafeNET Luna SA hardware security module, you must have a special set of components.

These components are as follows:

• 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

The SafeNET hardware security module uses the SafeNET PKCS #11 library.

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.

Oracle Wallet Manager is deprecated with Oracle Database 21c. Instead of using Oracle Wallet Manager, Oracle recommends that you use the command line tools orapki and mkstore.

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

To detect whether the module is being used, you can turn on Oracle Net tracing.

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

Errors that are associated with using PKCS #11 hardware security modules can appear.