What works in conjunction with a secure socket layer to ensure that data is transported safely?
This chapter describes how to configure and use the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols which are supported by Oracle Advanced Security. It contains the following topics: Show
13.1 Secure Sockets Layer and Transport Layer SecuritySecure Sockets Layer (SSL) is an industry standard protocol originally designed by Netscape Communications Corporation for securing network connections. SSL uses RSA public key cryptography in conjunction with symmetric key cryptography to provide authentication, encryption, and data integrity. This section contains:
13.1.1 The Difference Between Secure Sockets Layer and Transport Layer SecurityAlthough SSL was primarily developed by Netscape Communications Corporation, the Internet Engineering Task Force (IETF) took over development of it, and renamed it Transport Layer Security (TLS). Essentially, TLS is an incremental improvement to SSL version 3.0. If you want to use TLS Version 1.1 or 1.2, then you can download one of the following patches from My Oracle Support:
See Also:
Note: To simplify discussion, this chapter uses the term SSL where either SSL or TLS may be appropriate because SSL is the most widely recognized term. However, where distinctions occur between how you use or configure these protocols, this chapter specifies what is appropriate for either SSL or TLS. 13.1.2 How Oracle Database Uses Secure Sockets Layer for AuthenticationOracle Advanced Security supports authentication by using digital certificates over SSL in addition to the native encryption and data integrity capabilities of these protocols. By using Oracle Advanced Security SSL functionality to secure communications between clients and servers, you can
You can use SSL features by themselves or in combination with other authentication methods supported by Oracle Advanced Security. For example, you can use the encryption provided by SSL in combination with the authentication provided by Kerberos. SSL supports any of the following authentication modes:
13.1.3 How Secure Sockets Layer Works in an Oracle Environment: The SSL HandshakeWhen a network connection over SSL is initiated, the client and server perform an SSL handshake that includes the following steps:
The authentication process consists of the following steps:
13.2 Public Key Infrastructure in an Oracle EnvironmentThis section contains:
13.2.1 About Public Key Infrastructure in an Oracle EnvironmentA public key infrastructure (PKI) is a substrate of network components that provide a security underpinning, based on trust assertions, for an entire organization. A PKI exists so that disparate network entities can access its security services, which use public-key cryptography on an as-needed basis. Oracle provides a complete PKI that is based on RSA Security, Inc., Public-Key Cryptography Standards, and which interoperates with Oracle servers and clients. 13.2.2 About Public Key CryptographyTraditional private-key or symmetric-key cryptography requires a single, secret key that is shared by two or more parties to a secure communication. This key is used to both encrypt and decrypt secure messages sent between the parties, requiring prior, secure distribution of the key to each party. The problem with this method is that it is difficult to securely transmit and store the key. Public-key cryptography provides a solution to this problem, by employing public and private key pairs and a secure method for key distribution. The freely available public key is used to encrypt messages that can only be decrypted by the holder of the associated private key. The private key is securely stored, together with other security credentials, in an encrypted container called a wallet. Public-key algorithms can guarantee the secrecy of a message, but they do not necessarily guarantee secure communications because they do not verify the identities of the communicating parties. To establish secure communications, it is important to verify that the public key used to encrypt a message does in fact belong to the target recipient. Otherwise, a third party can potentially eavesdrop on the communication and intercept public key requests, substituting its own public key for a legitimate key (the man-in-the-middle attack). In order to avoid such an attack, it is necessary to verify the owner of the public key, a process called authentication. Authentication can be accomplished through a certificate authority (CA), which is a third party that is trusted by both of the communicating parties. The CA issues public key certificates that contain an entity's name, public key, and certain other security credentials. Such credentials typically include the CA name, the CA signature, and the certificate effective dates (From Date, To Date). The CA uses its private key to encrypt a message, while the public key is used to decrypt it, thus verifying that the message was encrypted by the CA. The CA public key is well known and does not have to be authenticated each time it is accessed. Such CA public keys are stored in wallets. 13.2.3 Public Key Infrastructure Components in an Oracle EnvironmentPublic key infrastructure (PKI) components in an Oracle environment include the following:
13.2.3.1 Certificate AuthorityA 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 CertificatesA 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 ListsTypically, 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:
Note: To use CRLs with other Oracle products, refer to the specific product documentation. This implementation of certificate validation with CRLs is only available in the Oracle Database 11g Release 2 (11.2) SSL adapter. 13.2.3.4 WalletsA 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:
13.2.3.5 Hardware Security ModulesOracle Advanced Security uses these devices for the following functions:
Cryptographic information can be stored on two types of hardware devices:
An Oracle environment supports hardware devices using APIs that conform to the RSA Security, Inc., Public-Key Cryptography Standards (PKCS) #11 specification. Note: Currently, SafeNET and nCipher devices are certified with Oracle Advanced Security 13.3 Secure Sockets Layer Combined with Other Authentication MethodsYou can configure Oracle Advanced Security to use SSL concurrently with database user names and passwords, RADIUS, and Kerberos, which are discussed in the following sections:
13.3.1 Architecture: Oracle Advanced Security and Secure Sockets LayerFigure 1-4, which displays the Oracle Advanced Security implementation architecture, shows that Oracle Advanced Security operates at the session layer on top of SSL and uses TCP/IP at the transport layer. This separation of functionality lets you employ SSL concurrently with other supported protocols. 13.3.2 How Secure Sockets Layer Works with Other Authentication MethodsFigure 13-1 illustrates a configuration in which SSL is used in combination with another authentication method supported by Oracle Advanced Security. In this example, SSL is used to establish the initial handshake (server authentication), and an alternative authentication method is used to authenticate the client
13.4 Secure Sockets Layer and FirewallsOracle Advanced Security supports two types of firewalls:
When you enable SSL, stateful inspection firewalls behave like application proxy firewalls because they do not decrypt encrypted packets. Firewalls do not inspect encrypted traffic. When a firewall encounters data addressed to an SSL port on an intranet server, it checks the target IP address against its access rules and lets the SSL packet pass through to permitted SSL ports, rejecting all others. With the Oracle Net Firewall Proxy kit, a product offered by some firewall vendors, firewall applications can provide specific support for database network traffic. If the proxy kit is implemented in the firewall, then the following processing takes place:
13.5 Secure Sockets Layer Usage IssuesConsider the following issues when using SSL:
See Also:
13.6 Enabling Secure Sockets LayerThis section contains:
13.6.1 Step 1: Install Oracle Advanced Security and Related ProductsInstall Oracle Advanced Security on both the client and server. When you do this, the Oracle Universal Installer automatically installs SSL libraries and Oracle Wallet Manager on your computer. See Also: Oracle Database platform-specific installation documentation 13.6.2 Step 2: Configure Secure Sockets Layer on the ServerDuring installation, Oracle sets defaults on both the Oracle database server and on the Oracle client for all SSL parameters except the location of the Oracle wallet. To configure SSL on the server, perform these steps:
13.6.2.1 Step 2A: Confirm Wallet Creation on the ServerBefore 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
Note: The listener uses the wallet defined in the listener.ora file. It can use any database wallet. When SSL is configured for a server using Net Manager, the wallet location is entered into the listener.ora and the sqlnet.ora files. The listener.ora file is not relevant to the Oracle client. To change the listener wallet location so that the listener has its own wallet, you can edit listener.ora to enter the new 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 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:
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. Table 13-1 SSL Cipher Suites
Footnote 1 AES ciphers work with Transport Layer Security (TLS 1.0) only Specifying Secure Sockets Cipher Suites for the Database Server
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:
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. Note: There is a known bug in which an OCI client requires a wallet even when using a cipher suite with DH_ANON, which does not authenticate the client. To set SSL_CLIENT_AUTHENTICATION to FALSE on the server:
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.3 Step 3: Configure Secure Sockets Layer on the ClientTo configure SSL on the client:
13.6.3.2 Step 3B: Configure the Server DNs and Use TCP/IP with SSL on the ClientThis section contains:
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:
Configuring the Server DNS and Using TCP/IP with SSL on the Client
Example 13-1 Sample tnsnames.ora File with Server Certificate DN and TCP/IP with SSL Specified 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"))Example 13-2 Sample listener.ora File with TCP/IP with SSL Specified as the Protocol 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)
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 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:
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. Note: If the SSL_CLIENT_AUTHENTICATION parameter is set to true in the sqlnet.ora file, then disable all cipher suites that use Diffie-Hellman anonymous authentication. Otherwise, the connection fails. Setting the Client Secure Sockets Layer Cipher Suites
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:
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:
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:
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.6.4 Step 4: Log on to the Database InstanceIf you are using SSL authentication for the client (SSL_CLIENT_AUTHENTICATION=true in the sqlnet.ora file), then launch SQL*Plus and enter the following: CONNECT/@net_service_nameIf you are not using SSL authentication (SSL_CLIENT_AUTHENTICATION=false in the sqlnet.ora file), then launch SQL*Plus and enter the following: CONNECT username@net_service_name Enter password: password13.7 Troubleshooting Secure Sockets LayerThe following section lists the most common errors you may receive while using the Oracle Advanced Security SSL adapter. It may be necessary to enable Oracle Net tracing to determine the cause of an error. For information about setting tracing parameters to enable Oracle Net tracing, refer to Oracle Database Net Services Administrator's Guide. ORA-28759: Failure to Open File Cause: The system could not open the specified file. Typically, this error occurs because the wallet cannot be found. Action: Check the following:
ORA-28786: Decryption of Encrypted Private Key Failure Cause: An incorrect password was used to decrypt an encrypted private key. Frequently, this happens because an auto login wallet is not being used. Action: Use Oracle Wallet Manager to turn the auto login feature on for the wallet. Then save the wallet again. Refer to, "Using Auto Login". If the auto login feature is not being used, then enter the correct password. ORA-28858: SSL Protocol Error Cause: This is a generic error that can occur during SSL handshake negotiation between two processes. Action: Enable Oracle Net tracing and attempt the connection again to produce trace output. Then contact Oracle customer support with the trace output. ORA-28859 SSL Negotiation Failure Cause: An error occurred during the negotiation between two processes as part of the SSL protocol. This error can occur when two sides of the connection do not support a common cipher suite. Action: Check the following:
ORA-28862: SSL Connection Failed Cause: This error occurred because the peer closed the connection. Action: Check the following:
ORA-28865: SSL Connection Closed Cause: The SSL connection closed because of an error in the underlying transport layer, or because the peer process quit unexpectedly. Action: Check the following:
ORA-28868: Peer Certificate Chain Check Failed Cause: When the peer presented the certificate chain, it was checked and that check failed. This failure can be caused by a number of problems, including:
Action: Refer to, "Opening an Existing Wallet" to use Oracle Wallet Manager to open your wallet and check the following:
ORA-28885: No certificate with the required key usage found. Cause: Your certificate was not created with the appropriate X.509 version 3 key usage extension. ORA-29024: Certificate Validation Failure Cause: The certificate sent by the other side could not be validated. This may occur if the certificate has expired, has been revoked, or is invalid for any other reason. Action: Check the following:
ORA-29223: Cannot Create Certificate Chain Cause: A certificate chain cannot be created with the existing trust points for the certificate being installed. Typically, this error is returned when the peer does not give the complete chain and you do not have the appropriate trust points to complete it. Action: Use Oracle Wallet Manager to install the trust points that are required to complete the chain. Refer to,"Importing a Trusted Certificate" 13.8 Certificate Validation with Certificate Revocation ListsThis section contains:
13.8.1 About Certificate Validation with Certificate Revocation ListsThe process of determining whether a given certificate can be used in a given context is referred to as certificate validation. Certificate validation includes determining that
The SSL network layer automatically performs the first three validation checks, but you must configure certificate revocation list (CRL) checking to ensure that certificates have not been revoked. CRLs are signed data structures that contain a list of revoked certificates. They are usually issued and signed by the same entity who issued the original certificate. (See certificate revocation lists.) 13.8.2 What CRLs Should You Use?You should have CRLs for all of the trust points that you honor. The trust points are the trusted certificates from a third party identity that is qualified with a level of trust. Typically, the certificate authorities you trust are called trust points. 13.8.3 How CRL Checking WorksCertificate revocation status is checked against CRLs, which are located in file system directories, Oracle Internet Directory, or downloaded from the location specified in the CRL Distribution Point (CRL DP) extension on the certificate. Typically, CRL definitions are valid for a few days. If you store your CRLs on the local file system or in the directory, then you must update them regularly. If you use CRL DPs then CRLs are downloaded each time a certificate is used, so there is no need to regularly refresh the CRLs. The server searches for CRLs in the following locations in the order listed. When the system finds a CRL that matches the certificate CA's DN, it stops searching.
13.8.4 Configuring Certificate Validation with Certificate Revocation ListsThis section contains:
13.8.4.1 About Configuring Certificate Validation with Certificate Revocation ListsThe 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. Note: If you want to store CRLs on your local file system or in Oracle Internet Directory, then you must use the command line utility, orapki, to rename CRLs in your file system or upload them to the directory. Refer to, "Certificate Revocation List Management" for information about using orapki. 13.8.4.2 Enabling Certificate Revocation Status Checking for the Client or Server
13.8.4.3 Disabling Certificate Revocation Status Checking
13.8.5 Certificate Revocation List ManagementThis section contains:
13.8.5.1 About Certificate Revocation ManagementBefore 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. Note: CRLs must be updated at regular intervals (before they expire) for successful validation. You can automate this task by using orapki commands in a script. 13.8.5.2 Displaying orapki Help for Commands That Manage CRLsYou can display all the orapki commands that are available for managing CRLs by entering the following at the command line: orapki crl helpThis command displays all available CRL management commands and their options.
Note: Using the -summary, -complete, or -wallet command options is always optional. A command will still run if these command options are not specified. 13.8.5.3 Renaming CRLs with a Hash Value for Certificate ValidationWhen 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 DirectoryPublishing 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=orcladminNote:
13.8.5.5 Listing CRLs Stored in Oracle Internet DirectoryYou 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_portwhere 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 DirectoryYou 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] -summarywhere 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] -completeFor example, the following orapki command: orapki crl display -crl $T_WORK/pki/wlt_crl/nzcrl.txt -wallet $T_WORK/pki/wlt_crl -completeproduces 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 validUsing 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=OracleContext13.8.5.7 Deleting CRLs from Oracle Internet DirectoryThe 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 -summaryproduces 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=OracleContext13.8.6 Troubleshooting Certificate ValidationTo determine whether certificates are being validated against CRLs, you can enable Oracle Net tracing. When a revoked certificate is validated by using CRLs, then you will see the following entries in the Oracle Net tracing file without error messages logged between entry and exit: nzcrlVCS_VerifyCRLSignature: entry nzcrlVCS_VerifyCRLSignature: exit nzcrlVCD_VerifyCRLDate: entry nzcrlVCD_VerifyCRLDate: exit nzcrlCCS_CheckCertStatus: entry nzcrlCCS_CheckCertStatus: Certificate is listed in CRL nzcrlCCS_CheckCertStatus: exitNote: Note that when certificate validation fails, the peer in the SSL handshake sees an ORA-29024: Certificate Validation Failure. If this message displays, refer to "ORA-29024: Certificate Validation Failure" for information about how to resolve the error. 13.8.6.1 Oracle Net Tracing File Error Messages Associated with Certificate ValidationThe 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. CRL signature verification failed with RSA status Cause: The CRL signature cannot be verified. Action: Ensure that the downloaded CRL is issued by the peer's CA and that the CRL was not corrupted when it was downloaded. Note that the orapki utility verifies the CRL before renaming it with a hash value or before uploading it to the directory. CRL date verification failed with RSA status Cause: The current time is later than the time listed in the next update field. You should not see this error if CRL DP is used. The systems searches for the CRL in the following order:
The first CRL found in this search may not be the latest. Action: Update the CRL with the most recent copy. CRL could not be found Cause: The CRL could not be found at the configured locations. This will return error ORA-29024 if the configuration specifies that certificate validation is require. Action: Ensure that the CRL locations specified in the configuration are correct by performing the following steps:
Oracle Internet Directory host name or port number not set Cause: Oracle Internet Directory connection information is not set. Note that this is not a fatal error. The search continues with CRL DP. Action: If you want to store the CRLs in Oracle Internet Directory, then use Oracle Net Configuration Assistant to create and configure an ldap.ora file for your Oracle home. Fetch CRL from CRL DP: No CRLs found Cause: The CRL could not be fetched by using the CRL Distribution Point (CRL DP). This happens if the certificate does not have a location specified in its CRL DP extension, or if the URL specified in the CRL DP extension is incorrect. Action: Ensure that your certificate authority publishes the CRL to the URL that is specified in the certificate's CRL DP extension. Manually download the CRL. Then depending on whether you want to store it on your local file system or in Oracle Internet Directory, perform the following steps: If you want to store the CRL on your local file system:
If you want to store the CRL in Oracle Internet Directory:
13.9 Configuring Your System to Use Hardware Security ModulesThis section contains:
13.9.1 About Configuring Your System to Use Hardware Security ModulesOracle Advanced Security supports hardware security modules that use APIs which conform to the RSA Security, Inc., PKCS #11 specification. Typically, these hardware devices are used to securely store and manage private keys in tokens or smart cards, or to accelerate cryptographic processing. 13.9.2 Guidelines for Using Hardware Security Modules with Oracle Advanced SecurityThe following general guidelines apply if you are using a hardware security module with Oracle Advanced Security:
You can use the wallet containing PKCS #11 information just as you would use any Oracle wallet, except the private keys are stored on the hardware device and the cryptographic operations are performed on the device as well. 13.9.3 Configuring Your System to Use nCipher Hardware Security ModulesThis section contains:
13.9.3.1 About Configuring Your System to Use nCipher Hardware Security ModulesHardware 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:
13.9.3.2 Oracle Components Required To Use an nCipher Hardware Security ModuleTo use an nCipher hardware security module, you need the following components:
13.9.3.3 About Installing an nCipher Hardware Security ModuleTo 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:
The nCipher PKCS #11 library is located at the following location for typical installations:
13.9.4 Configuring Your System to Use SafeNET Hardware Security ModulesThis section contains:
13.9.4.1 About Configuring Your System to Use SafeNet Hardware Security ModulesHardware 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:
13.9.4.2 Oracle Components for the SafeNET Luna SA Hardware Security ModuleTo use a SafeNET Luna SA hardware security module, you must have the following components
Note: You must contact your SafeNET 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 a SafeNET hardware security module with Oracle Advanced Security. 13.9.4.3 About Installing a SafeNET Hardware Security ModuleTo 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:
The SafeNET Luna SA PKCS #11 library is located at the following location for typical installations:
13.9.5 Troubleshooting Using Hardware Security ModulesThis section contains:
13.9.5.1 Errors in the Oracle Net Trace FilesTo 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: exit13.9.5.2 Error Messages Associated with Using Hardware Security ModulesThe following errors are associated with using PKCS #11 hardware security modules: ORA-43000: PKCS11: library not found Cause: The system cannot locate the PKCS #11 library at the location specified when the wallet was created. This happens only when the library is moved after the wallet is created. Action: Copy the PKCS #11 library back to its original location where it was when the wallet was created. ORA-43001: PKCS11: token not found Cause: The smart card that was used to create the wallet is not present in the hardware security module slot. Action: Ensure that the smart card that was used when the wallet was created is present in the hardware security module slot. ORA-43002: PKCS11: passphrase is wrong Cause: This can occur when an incorrect password is specified at wallet creation, or the PKCS #11 device password is changed after the wallet is created and not updated in the wallet by using Oracle Wallet Manager. Action: Depending on the cause, take one of the following actions: If you see this error during wallet creation, then check to ensure that you have the correct password and reenter it. If the password changed after wallet creation, then use Oracle Wallet Manager to open the wallet and enter a new password. Note: The nCipher log file is in the directory where the module is installed at the following location: /log/logfile See Also: nCipher and SafeNET documentation for more information about troubleshooting nCipher and SafeNET devices 13.10 Configuring SSL in an Oracle Real Application Clusters EnvironmentYou can configure Secure Sockets Layer for use with an Oracle Real Application Clusters (Oracle RAC) environment. This section contains:
13.10.1 Step 1: Configure the TCPS Protocol EndpointsIn an Oracle RAC environment, clients access one of three scan listeners and are then routed to database listeners. To support Secure Sockets Layer, all the listeners must have TCPS protocol endpoints. The following procedure adds the TCPS endpoints to the database node listeners and scan listeners.
13.10.2 Step 2: Update the Local Listener Parameter on Each Oracle RAC NodePMON must send the endpoint values that are stored in the local listener to the scan listeners so that they can create the approprirate service handlers. In this next procedure, you will add the TCPS endpoints for the database node listeners that you had created in Step 1: Configure the TCPS Protocol Endpoints to the local listener startup parameter on each Oracle RAC node. The local listener IP address is unique to each node. When you issue the ALTER SYSTEM statement, you must state the local instance SID value (for example, sid = 'instance').
13.10.3 Step 3: Create SSL Certificates and Wallets for the Cluster and for the ClientsThe choice and usage of a Certificate Authority (CA) for certificate signing depends on your site's policies. To make a successful SSL connection, the server and connecting clients must have unique SSL certifcates that are signed by the same trusted Certificate Authority. You should create the certificate requests for the cluster and for a test client that will connect to the database over SSL. Have these requests signed by the CA, and then build wallets using the signed user certificates and trusted root certificate. Note that the cluster and client wallets have unique identities but share the same trusted certificate. This is the proper wallet setup for an SSL connection. This section contains:
13.10.3.1 Creating the SSL Certificate for Each Cluster and for the Test Client
13.10.3.2 Signing Each User CertificateUsing 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.
13.10.4 Step 4: Copy the Wallet to Each Cluster Node and Create an Obfuscated Wallet
13.10.5 Step 5: Define Wallet Locations in the listener.ora and sqlnet.ora FilesBoth PMON and the listener processes of each node must be able to access the wallets. Each node's sqlnet.ora and listener.ora files must have the wallet locations defined.
13.10.6 Step 6: Restart the Database Instances and ListenersWith the wallets in place and .ora files edited, you must restart the PMON and listener processes so that they can recognize the new wallet settings. With the restart the instances will also use the local_listener values that you added in "Step 2: Update the Local Listener Parameter on Each Oracle RAC Node". Ensure that the scan listeners have the proper TCPS handlers, and if necessary, correct any discrepancies. Restart commands are as follows: srvctl stop listener srvctl start listener srvctl stop scan_listener srvctl start scan_listener srvctl stop database -d netrac srvctl start database -d netrac13.10.7 Step 7: Test the Configuration from a Cluster NodeWith the cluster environment configured for SSL the simplest way to quickly test it is to make an SSL connection on one of the cluster nodes.
13.10.8 Step 8: Test the Configuration from a Remote Client
What works in conjunction with a Secure Sockets Layer to ensure that data is transported safely?TLS is an authentication and security protocol widely implemented in browsers and Web servers. SSL works by using a public key to encrypt data transferred over the SSL connection.
How do you secure a socket layer?Steps involved in the secure sockets layer process. Initial connection. ... . Certificate authentication. ... . Once the browser, or client, has authenticated the web server and its certificate, it encrypts the user's message using Brand A's public key. ... . Brand A's server decrypts the message using its own private key.. Which method is used to identify the Secure Socket Layer window?SSL Record provides two services to SSL connection. In the SSL Record Protocol application data is divided into fragments. The fragment is compressed and then encrypted MAC (Message Authentication Code) generated by algorithms like SHA (Secure Hash Protocol) and MD5 (Message Digest) is appended.
What is Secure Socket Layer and how it works?SSL, or Secure Sockets Layer, is an encryption-based Internet security protocol. It was first developed by Netscape in 1995 for the purpose of ensuring privacy, authentication, and data integrity in Internet communications. SSL is the predecessor to the modern TLS encryption used today.
|