This section explains how to handle additional SSL configuration scenarios beyond the basic topologies described earlier:
■ Hardware Security Modules and Accelerators
■ CRL Integration with SSL
■ Oracle Fusion Middleware FIPS 140-2 Settings
For details and examples of the commands used in this section see Section 6.9.
6.7.1 Hardware Security Modules and Accelerators
A Hardware Security Module (HSM) is a physical plug-in card or an external security device that can be attached to a computer to provide secure storage and use of sensitive content.
Oracle Fusion Middleware supports PKCS#11-compliant HSM devices that provide a secure storage for private keys.
Take these steps to implement SSL for a component using a PKCS#11 wallet:
1. Install the HSM libraries on the machine where the component is running. This is a one-time task and is device-dependent.
2. Next, create a wallet using Oracle Wallet Manager (OWM) or the orapki command-line tool. Note the following:
a. Choose PKCS11 as the wallet type.
Note: This discussion applies only to Oracle HTTP Server, Oracle Web Cache, and Oracle Internet Directory, which are the system components supporting HSM.
Advanced SSL Scenarios
b. Specify the device-specific PKCS#11 library used to communicate with the device. This library is part of the HSM software.
On Linux, the library is located at:
For LunaSA (Safenet): /usr/lunasa/lib/libCryptoki2.so For nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so On Windows, the library is located at:
For LunaSA (Safenet): C:\Program Files\LunaSA\cryptoki.dll
3. Now follow the standard procedure for obtaining third-party certificates, that is, creating a certificate request, getting the request approved by a Certificate Authority (CA), and installing the certificate signed by that CA.
The wallet you set up is used like any other wallet.
4. Verify the wallet with the orapki utility. Use the following command syntax:
orapki wallet p11_verify [-wallet [wallet]] [-pwd password]
5. Configure SSL on your component listener using the configureSSL WLST command, providing a properties file as input. Your properties file should specify the full path of the PKCS#11 wallet directory on the machine where the component is running. (Note: Do not save the PKCS#11 wallet in the instance home directory.
Only wallets created and managed through Fusion Middleware Control or WLST should reside in the instance home.)
A sample properties file could look like this:
SSLEnabled=true
AuthenticationType=Server PKCS11Wallet=/tmp/lunasa/wallet
6.7.2 CRL Integration with SSL
Components that use SSL can optionally turn on certificate validation using a
certificate revocation list (CRL). This allows them to validate the peer certificate in the See Also: Appendix H, "Oracle Wallet Manager and orapki" for
details about orapki
Note: You must use the WLST command configureSSL to configure the PKCS11 wallet. You cannot do this task using Fusion Middleware Control or any other tool.
Note:
■ This discussion applies only to Oracle HTTP Server and Oracle Web Cache in the context of an Oracle WebLogic Server
environment. For SSL configuration in standalone components, see Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server and Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
■ CRL validation is managed through WLST; you cannot perform this task through Fusion Middleware Control.
Advanced SSL Scenarios
6-36 Oracle Fusion Middleware Administrator's Guide
SSL handshake and ensure that it is not on the list of revoked certificates issued by the Certificate Authority (CA).
This section describes how to configure a component to use CRL-based validation, and how to create and set up CRLs on the file system.
6.7.2.1 Configuring CRL Validation for a Component
Configure SSL on your component listener using the configureSSL WLST command, providing a properties file as input.
The properties file must be set up as follows:
1. The CertValidation attribute must be set to url.
2. The CertValidationPath attribute must be of the form file://file_path or dir://directory_path.
■ Use the first format if you are using a single CRL file for certificate validation.
This CRL file should contain a concatenation of all CRLs.
■ Use the second format if you are specifying a directory path that contains multiple CRL files in hashed form.
See Section 6.7.2.2, "Manage CRLs on the File System" on how to create CRLs in hashed form.
In this example, the properties file specifies a single CRL file:
SSLEnabled=true
AuthenticationType=Server CertValidation=crl KeyStore=ohs1
CertValidationPath=file:///tmp/file.crl
In this example, the properties file specifies a directory path to multiple CRL files:
SSLEnabled=true
AuthenticationType=Server KeyStore=ohs1
CertValidation=crl
CertValidationPath=dir:///tmp
6.7.2.2 Manage CRLs on the File System
You use the orapki command-line tool to manage CRLs on the file system. For details on this topic, see Section H.2.5, "Managing Certificate Revocation Lists (CRLs) with orapki Utility."
CRL Renaming to Hashed Form
If specifying a CRL storage location, the CRL must be renamed. This enables CRLs to be loaded in an efficient manner at runtime. This operation creates a symbolic link to the actual CRL file. On Windows, the CRL is copied to a file with a new name.
To rename a CRL:
orapki crl hash
[-crl [url|filename]] [-wallet wallet] [-symlink directory]
Note: LDAP-based CRLs or CRL distribution points are not supported.
Advanced SSL Scenarios
[-copy directory] [-summary] [-pwd password]
For example:
orapki crl hash -crl nzcrl.txt -symlink wltdir -pwd password
If the CRL file name is specified at runtime, multiple CRLs can be concatenated in that file. The CRL created in this example is in Base64 format, and you can use a text editor to concatenate the CRLs.
CRL Creation
To create a CRL:
orapki crl create
[-crl [url|filename]] [-wallet [cawallet]] [-nextupdate [days]] [-pwd password]
For example:
orapki crl create
-crl nzcrl.crl -wallet rootwlt -nextupdate 3650 -pwd password Certificate Revocation
Revoking a certificate adds the certificate's serial number to the CRL.
To revoke a certificate:
orapki crl revoke
[-crl [url|filename]] [-wallet [cawallet]] [-cert [revokecert]] [-pwd password]
For example:
orapki crl revoke
-crl nzcrl.txt -wallet rootwlt -cert cert.txt -pwd password
6.7.2.3 Test a Component Configured for CRL Validation
To test that a component is correctly configured for CRL validation, take these steps:
1. Set up a wallet with a certificate to be used in your component.
2. Generate a CRL with this certificate in the revoked certificates list. Follow the steps outlined in Section 6.7.2.2, "Manage CRLs on the File System."
3. Configure your component to use this CRL. Follow the steps outlined in Section 6.7.2.1, "Configuring CRL Validation for a Component."
4. The SSL handshake should fail when this revoked certificate is used.
6.7.3 Oracle Fusion Middleware FIPS 140-2 Settings
This section describes how to configure Oracle Fusion Middleware components to comply with the FIPS 140-2 advanced security standard. Topics include:
■ FIPS-Configurable Products
Note: CRL creation and Certificate Revocation are for test purposes and only used in conjunction with self-signed certificates. For production use, obtain production certificates from well-known CAs and obtain the CRLs from those authorities.
Advanced SSL Scenarios
6-38 Oracle Fusion Middleware Administrator's Guide
■ Setting the SSLFIPS_140 Parameter
■ Selecting Cipher Suites
■ Other Configuration Parameters
6.7.3.1 FIPS-Configurable Products
Any product using the Oracle SSL SDK can be configured to run in the FIPS mode.
Specifically, you can configure the following Oracle Fusion Middleware components:
■ Oracle HTTP Server
■ Oracle Web Cache
■ Oracle Internet Directory
6.7.3.2 Setting the SSLFIPS_140 Parameter
You can configure these components to run in the FIPS mode by setting the SSLFIPS_140 parameter to TRUE in the fips.ora file:
SSLFIPS_140=TRUE
This file does not exist out-of-the-box and has to be created. Locate fips.ora either in the $ORACLE_HOME/ldap/admin directory, or in the directory pointed to by the FIPS_HOME environment variable.
The SSLFIPS_140 parameter is set to FALSE by default. You must set it to TRUE for FIPS mode operation.
6.7.3.3 Selecting Cipher Suites
A cipher suite is a set of authentication, encryption, and data integrity algorithms used for exchanging messages between network nodes. During an SSL handshake, for example, the two nodes negotiate to see which cipher suite they will use when transmitting messages back and forth.
Only the following cipher suites are approved for use in FIPS mode:
SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
Any other ciphers should not be used while running in FIPS mode.
You can configure one or more of these ciphers using comma-separated values. These should be specified in the SSL properties file for the key 'Ciphers' in the WLST configureSSL command, or through Fusion Middleware Control.
See Section 6.9.28, "Properties Files for SSL" for details about specifying the SSL properties file with the configureSSL command.
6.7.3.4 Other Configuration Parameters
The minimum key size for enabling FIPS mode is 1024 bits. You need to ensure that the keys used in FIPS mode are at least 1024 bits. This is because the certificate in the
See Also: For more information about this standard, refer to the Cryptographic Modules Validation Program Web site at:
http://csrc.nist.gov/groups/STM/index.html
WLST Reference for SSL
wallet used by components like Oracle HTTP Server, Oracle Web Cache, and Oracle Internet Directory must have a minimum public key size of 1024 bits.
You can only use wallets created using Oracle tools like SSLConfig, Oracle Wallet Manager, or orapki. Third-party PKCS#12 wallet files cannot be used in FIPS mode.