12 Managing Security

This chapter describes how you can secure access to the Oracle Traffic Director administration server and enable SSL/TLS for Oracle Traffic Director virtual servers. It also describes how to configure client authentication and how you can use Oracle Traffic Director to secure access to origin servers.

This chapter contains the following sections:

SSL/TLS Concepts

This section provides basic information about security-related concepts. It contains the following topics:

About SSL

Secure Socket Layer (SSL) is a protocol for securing Internet communications and transactions. It enables secure, confidential communication between a server and clients through the use of digital certificates. Oracle Traffic Director supports SSL v3 and Transport Layer Security (TLS) v1.

In a 2-way HTTP over SSL (HTTPS) connection, each party—say a browser or a web server—first verifies the identity of the other. This phase is called the SSL/TLS handshake. After the identities are verified, the connection is established and data is exchanged in an encrypted format. The following are the steps in the SSL/TLS handshake between an SSL-enabled browser and an SSL-enabled server:

The browser attempts to connect to the server by sending a URL that begins with https:// instead of http://.
The server sends its digital certificate (see About Certificates) and public key to the client.
The client checks whether the server's certificate is current (that is, it has not expired) and is issued by a certificate authority (CA) that the client trusts.
If the certificate is valid, the client generates a one-time, unique session key and encrypts it with the server's public key, and then sends the encrypted session key to the server.
The server decrypts the message from the client by using its private key and retrieves the session key.

At this point, the client has verified the identity of the server; and only the client and the server have a copy of the client-generated, unique session key. Till the session is terminated, the client and the server use the session key to encrypt all communication between them.

About Ciphers

A cipher is an algorithm, a mathematical function, used for encrypting and decrypting data. Some ciphers are stronger and more secure than others. Usually, the more bits a cipher uses, the harder it is to decrypt the data encrypted using that cipher.

SSL v3 and TLS v1 support various ciphers. Clients and servers support different cipher suites (sets of ciphers), depending on factors such as the supported protocol, organizational policies on encryption strength, and government restrictions on export of encrypted software.

In any 2-way encryption process, the client and the server must use the same cipher suite. During the SSL/TLS handshake process, the server and client negotiate the cipher suite—typically, the strongest one—that they use to communicate.

Cipher Suites Supported by Oracle Traffic Director

During the SSL/TLS handshake, Oracle Traffic Director and clients negotiate the cipher suites to be used. The cipher suites supported in Oracle Traffic Director are listed. You can view this list by running the otd_getVirtualServerSslProperties WLST command.

The name of each cipher suite indicates the key-exchange algorithm, the hashing algorithm, and the encryption algorithm, as depicted in the table.

Protocols supported
- TLS: TLS 1.0, 1.1, 1.2
- SSL: SSL 3
Key exchange algorithms supported
- RSA
- RSA_EXPORT
- RSA_EXPORT1024
- RSA_FIPS
- ECDHE_RSA
- ECDH_RSA
- ECDH_ECDSA
- ECDHE_ECDSA
Encryption algorithms supported
- AES_256_CBC: 256-bit key
- 3DES_EDE_CBC: 168-bit key
- AES_128_CBC: 128-bit key
- RC4_128: 128-bit key
- DES_CBC: 56-bit key
- RC4_56: 56-bit key
- RC4_40 and RC2_CBC_40: 128-bit key but only 40 bits have cryptographic significance
- NULL: No encryption
Message Authentication Code (MAC) algorithms supported
- SHA: 160-bit hash
- NULL: No hashing

Table 12-1 Cipher Suites Supported in Oracle Traffic Director

Cipher Suite
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

About Keys

Encryption using ciphers, by itself, does not ensure data security. A key must be used with the encrypting cipher to produce the actual encrypted result, or to decrypt previously encrypted information. The encryption process uses two keys—a public key and a private key. The keys are mathematically related; so information that is encrypted using a public key can be decrypted only using the associated private key, and vice versa. The public key is published by the owner as part of a certificate (see About Certificates); only the associated private key is safeguarded.

About Certificates

A certificate is a collection of data that uniquely identifies a person, company, or other entity on the Internet. It enables secure, confidential communication between two entities. Personal certificates are used by individuals; server certificates are used to establish secure sessions between the server and clients over SSL.

Certificates can be self-signed (by the server), signed by a trusted third party called Certification Authority (CA) or one that you created. The holder of a certificate can present the certificate as proof of identity to establish encrypted, confidential communication. The CA could be a third-party vendor or an internal department responsible for issuing certificates for an organization's servers.

Certificates are based on public-key cryptography, which uses a pair of keys (very long numbers) to encrypt information so that it can be read only by its intended recipient. The recipient then decrypts the information using one of the keys.

A certificate binds the owner's public key to the owner's identity. In addition to the public key, a certificate typically includes information such as the following:

The name of the holder and other identification, such as the URL of the server using the certificate
The name of the CA that issued the certificate
The digital signature of the issuing CA
The validity period of the certificate

RSA and ECC Certificates

Oracle Traffic Director supports generation of the traditional RSA-type keys and the more advanced Elliptic Curve Cryptography (ECC) keys. ECC offers equivalent security with smaller key sizes, which results in faster computations, lower power consumption, and memory and bandwidth savings.

Key size for RSA and ECC

RSA keys: you can specify 512, 1024, 2048, 4096 bits. Long keys provide better encryption, but Oracle Traffic Director would need more time to generate them.
ECC keys: you should specify the curve for generating the key pair. Oracle Traffic Director supports the following curves: 163 (sect163r2), 192 (secp192r1), 224(secp224r1), 233(sect233k1), 256(secp256r1), 283(sect283k1), 384(secp384r1), 409(sect409k1), 521(secp521r1), 571(sect571k1).

Managing Certificates

This section contains the following topics:

Obtaining a Certificate

To enable SSL/TLS for an Oracle Traffic Director instance, you must associate an RSA or ECC certificate, or both with an Oracle Traffic Director listener or a virtual server. The certificate can be a self-signed certificate, demo CA signed certificate or a certificate issued by a third-party Certificate Authority (CA) like Verisign.

Demo CA signed Certificate

To obtain a demo CA signed certificate, you must a generate keypair from Oracle Traffic Director. See section,Generating a Keypair for information on generating a keypair. The keypair generated is signed by a demonstration CA by default. Use this keypair if you do not need your certificate to be signed by a CA. In addition, you can use this keypair if you want to test the SSL/TLS implementation while the CA is in the process of signing your certificate request.

Third party CA signed certificate

To obtain a certificate signed by a CA, generate a keypair from Oracle Traffic Director. See sectionGenerating a Keypair. Then, generate a Certificate Signing Request (CSR) for the generated keypair, submit it to the CA, and follow the process to obtain the signed certificate. The Certificate Signing Request (CSR) is a digital file, a block of encrypted text in Base-64 encoded PEM format containing information such as your server name, organization name, and country. It also contains the public key that is included in the certificate. See section, Generating a CSR Using Fusion Middleware Control for generating the CSR from a keypair.

After obtaining the CA-signed certificate in response to your CSR, import the certificate in to the appropriate configuration, as described in section Importing a CA Signed Certificate.

Self-signed Certificate

You cannot create a self-signed certificate from Oracle Traffic Director. Use tools like orapki, keytool, and openssl. The certificate can then be imported into Oracle Traffic Director as described here. The following commands create a self-signed certificate and import the same into Oracle Traffic Director.

Using openssl and java keytool

openssl pkcs12 -export -name myservercert -in cert.pem -inkey key.pem -out keystore.p12
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -alias myservercert

# Importing the certificate using wlst command
svc = getOpssService("KeyStoreService")
svc.importKeyStore(appStripe='OTD', name='origin-server-3', password='abc12345', keypasswords='abc12345', type='OracleWallet', permission=true, filepath='<oracle home>/oracle_common/bin/myservercert')

Generating a Keypair

You need to generate a keypair for creating a certificate.

You can generate a keypair by using either Fusion Middleware Control or the WLST.

Before You Begin

Before you begin generating a keypair, decide the following:

The nickname of the keypair (required only for generating a keypair).
The key type—RSA or ECC.
For more information, see RSA and ECC Certificates.

Generating a Keypair Using Fusion Middleware Control

To create a self-signed certificate by using Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to create an self-signed certificate.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Security > Manage Certificates

A new page displays on screen.
Click the Generate Keypair button in the common task bar.

The New Generate Keypair wizard opens.

Description of the illustration GUID-5D358C21-7F37-4741-A7BE-4B0B0BC664BE-default.gif
Click OK. The new certificate is displayed in the certificate list.
View the certificate details by clicking on the certificate alias The key pair is wrapped in a demonstration CA signed certificate and stored in the truststore. If your applications not using the truststore, then you must import the demonstration CA certificate to a custom keystore.

Generate keypair using WLST

To generate a keypair, run the generateKeyPair command, as shown in the following example:

svc = getOpssService("KeyStoreService")
svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='',dn='CN=test., OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024')

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information, see generateKeyPair in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

Generating a Certificate Signing Request (CSR)

To obtain a certificate signed by a Certificate Authority (CA), you should submit a Certificate Signing Request (CSR) to the CA, pay the prescribed fee if required, and wait for the CA to approve the request and grant the certificate.

The CSR is a digital file—a block of encrypted text in Base-64 encoded PEM format—containing information such as your server name, organization name, and country. It also contains the public key that will be included in the certificate.

You can generate a Certificate Signing Request (CSR) by using either Fusion Middleware Control or the WLST of OTD.

Generating a CSR Using Fusion Middleware Control

Generating a CSR by using Fusion Middleware Control

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to create a CSR.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Security > Manage Certificates

A new page displays on screen.
A list of the available certificates are displayed. Select the certificate for which you want to generate CSR.
Click the Generate CSR button in the common pane.

It opens a new window where you can export Generate CSR.
Follow the on-screen prompts to Export CSR, Click on Export CSR to have a copy of it, and click Close

Generating a CSR Using WLST

To generate a CSR, run the exportKeyStoreCertificateRequest command, as shown in the following example:

# generate the CSR and put it in to a text file
svc.exportKeyStoreCertificateRequest(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='', filepath='/scratch/certreq.crt')

This command generates a CSR and displays the encrypted text of the CSR as shown in Generating a Keypair using Fusion Middleware Control.

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information, see exportKeyStoreCertificateRequest command in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

After obtaining the CA-signed certificate in response to your CSR, you should import the certificate in the appropriate configuration, as described in Importing a Certificate.

Importing a Certificate

You can import a generated keypair or CA-signed certificate by using Fusion Middleware Control or the WLST.

This section contains the following topics:

Importing a Certificate Using Fusion Middleware Control
Importing a Certificate Using WLST

Importing a CA Signed Certificate

Before you begin

The CA signed certificate that must be imported should be a base-64 encoded PEM formatted file containing all the certificates that form the certificate chain starting from server certificate, intermediate certificate and the root certificates. OTD also supports importing a certificate chain that is in base-64 encoded PEM formatted PKCS7 file (.p7b file).

Sample PEM formatted certificate chain file

-----BEGIN CERTIFICATE-----
(Server SSL certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root certificate)
-----END CERTIFICATE-----

Sample pkcs7 certificate chain file (.p7b file)

-----BEGIN PKCS7-----
[... certificate content here ...]
-----END PKCS7-----

Importing a CA Signed Certificate Using Fusion Middleware Control

Login to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to import a certificate.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Security > Manage Certificates
A new page displays on screen.
Click the Import button.

The Import Certificate wizard opens.

Figure 12-1 Import Certificate

Description of "Figure 12-1 Import Certificate"
Choose Certificate Chain from the Certificate Type drop-down.
Choose an existing (created while generating the keypair) from the Alias from the drop-down. Specify the name of the Alias if you are importing a Trusted Certificate.
Specify the certificate source. If you are using the Paste option, then copy and paste the certificate directly into the text field. If you are using the Select a file option, then click Browse to choose the file from the operating system.
Click OK. The imported certificate or trusted certificate is displayed in the list of certificates.

Importing a CA Signed Certificate Using WLST

To Import a Certificate Chain, run the importKeyStoreCertificate command, as shown in the following example. For more information, refer Importing a Certificate in Securing Applications with Oracle Platform Security Services.

svc = getOpssService("KeyStoreService")
svc.importKeyStoreCertificate(appStripe='OTD', name='<configuration name>', password='<key store password>', alias='test_cert', keypassword='<key password>', type='CertificateChain', filepath='/export/home/testCertChain.crt')

Importing an Existing Certificate

Existing certificates could be self signed certificates or certificates with keypair generated outside the current Oracle Traffic Director installation.

A self signed certificate is generated using tools like orapki, keytool and openssl. There is no option in Fusion Middleware Control to import these certificates, as the private key exists outside the current Oracle Traffic Director installation. This can be done using WLST by using the importKeyStore command. Note that except for the self signed certificates, the KeyStore must contain the entire certificate chain including the root certificate in the same alias as well as the private key. Oracle Traffic Director supports importing KeyStores of type JKS or Oracle Wallet.

Importing an Existing Certificate Using WLST

Import JKS keystore:
svc.importKeyStore(appStripe='OTD', name='origin-server-2', password='<keystore password>', aliases='myservercert', keypasswords='key passwords', type='JKS', permission=true, filepath='<file path to jks keystore>')

Import Oracle Wallet:
svc.importKeyStore(appStripe='OTD', name='origin-server-3', password='<keystore password>', keypasswords='key passwords', type='OracleWallet', permission=true, filepath='<directory containing wallet>')

Importing a Trusted Certificate

When SSL/TLS is enabled for an Oracle Traffic Director virtual server and you access the https:// URL of the virtual server, an error message is displayed indicating that the signing CA is unknown and not trusted if the signing CA is not part of trusted certificates in Oracle Traffic Director. To proceed with the connection, the client can choose to trust the certificate or import the certificate of the signing CA as a trusted certificate. The Trusted certificate that must be imported should be a base-64 encoded PEM formatted file.

-----BEGIN CERTIFICATE-----
(Trusted certificate)
-----END CERTIFICATE-----

Importing a Trusted Certificate Using Fusion Middleware Control

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to import a certificate.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Security > Manage Certificates
A new page displays on screen.
Click the Import button.

The Import Certificate wizard opens.

Figure 12-2 Import Certificate

Description of "Figure 12-2 Import Certificate"
Choose Trusted Certificate from the Certificate Type drop-down.
Specify an Alias name for the imported certificate from the drop-down.
Specify the certificate source. If using the Paste option, then copy and paste the certificate directly into the text field. If using the Select a file option, then click Browse to choose the file from the operating system.
Click OK. The imported certificate or trusted certificate is displayed in the list of certificates.

Importing a Trusted Certificate Using WLST

To Import a trusted certificate, run the importKeyStoreCertificate command, as shown in the following example. For more information, refer Securing Applications with Oracle Platform Security Services.

svc = getOpssService("KeyStoreService")
svc.importKeyStoreCertificate(appStripe='OTD', name='<configuration name>', password='<key store password>', alias='test_cert', keypassword='<key password>', type='TrustedCertificate', filepath='/export/home/trustedCertificate.crt')

Creating a Certificate with Subject Alternate Names

Oracle Traffic Director uses KSS (keystore service) for managing the keys and certificates and to export the certificate(s) into oracle wallet. Since KSS does not support creating a certificate with subject alternative names, users have to create such a certificate outside of KSS and then import the same into KSS. One way to achieve this is to see if your Certificate Authority (CA) offers the option of adding alternate name extensions to the certificate at the time of signing your request. If the CA requires that the subject alternate names be added while generating the certificate signing request, then orapki (which is bundled with Oracle Traffic Director) or the freely available openssl tool can be used to generate such a request.

Creating SAN Using Openssl

Create a CSR

The following example shows how to create a CSR (Certificate Signing Request) for the certificate with subject alternate name using openssl tool.

Create a new openssl configuration file:
```
touch openssl-server.cnf
```

Open the file 'openssl-server.cnf' and add the following content. Make sure you mention the subject alternate names for the certificate in the '[ alternate_names ]' section.

HOME            = .
RANDFILE        = $ENV::HOME/.rnd
 
####################################################################
[ req ]
default_bits        = 2048
default_keyfile     = serverkey.pem
distinguished_name  = server_distinguished_name
req_extensions      = server_req_extensions
string_mask         = utf8only
 
####################################################################
[ server_distinguished_name ]
countryName                 = Country Name (2 letter code)
countryName_default         = US
 
stateOrProvinceName         = State or Province Name (full name)
stateOrProvinceName_default = MD
 
localityName                = Locality Name (eg, city)
localityName_default        = Baltimore
 
organizationName            = Organization Name (eg, company)
organizationName_default    = Test CA, Limited
 
commonName                  = Common Name (e.g. server FQDN or YOUR name)
commonName_default          = example.com
 
emailAddress                = Email Address
emailAddress_default        = test@example.com
 
####################################################################
[ server_req_extensions ]
 
subjectKeyIdentifier        = hash
basicConstraints            = CA:FALSE
keyUsage                    = keyEncipherment
extendedKeyUsage            = serverAuth,clientAuth
 
subjectAltName              = @alternate_names
 
####################################################################
[ alternate_names ] # Replace these with the desired subject alternate names for this certificate
 
DNS.1       = example.net
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

Create the server certificate request.

openssl req -config openssl-server.cnf -newkey rsa:2048 -sha256 -nodes -out servercert.csr -outform PEM

The CSR can be inspected using the following command.

openssl req -text -noout -verify -in servercert.csr

Get the CSR signed by a CA

Submit the generated CSR above to the CA and follow the required process to get it signed by the CA.

Import the CA signed Certificate into Oracle Traffic Director Configuration

There is no option in Fusion middleware console to import the CA signed certificates whose private key is generated outside the KSS. However, this can be done using the WLST importKeyStore command which can import a JKS (Java Key Store) or Oracle Wallet. Note that the keystore must contain the entire certificate chain including the root certificate in the same alias as well as the private key.

The following commands show how the CA signed certificate, the private key as well as the CA certificate can be added to a JKS which can then be imported into the OTD configuration via WLST.

# Convert the certificates and key into a pkcs12 file
# servercert.pem - Base-64 encoded PEM formatted file containing containing CA signed certificate obtained from the CA.
# serverkey.pem - Private key generated while creating the certificate signing request
# cacert.pem -  Base-64 encoded PEM formatted file containing all the certificates that are needed to form the certificate chain starting from intermediate certificates (if any) and the root certificate
openssl pkcs12 -export -name myservercert -in servercert.pem -inkey serverkey.pem -certfile cacert.pem -out keystore.p12
 
# Convert pksc12 file into jks key store
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -alias myservercert

The JKS created above can now be imported into the Oracle Traffic Director configuration using WLST.

svc = getOpssService("KeyStoreService")
svc.importKeyStore(appStripe='OTD', name='foo', password='abc123', aliases='myservercert', keypasswords='abc123', type='JKS', permission=true, filepath='mykeystore.jks')

Creating SAN Using Orapki

Create a CSR

Create an empty wallet.

<oracle home>/oracle_common/bin/orapki wallet create -wallet ./foo -pwd abc12345

Add a certificate signing request to the wallet. Ensure that you mention subject alternate name using addext_san parameter as shown below.

<oracle home>/oracle_common/bin/orapki wallet add -wallet ./foo -dn 'CN=example.com, O=Test CA Limited, L=Baltimore, ST=MD, C=US, OU='blah' -keysize 2048 -addext_ski -addext_ku  keyEncipherment -addext_basic_cons CA -addext_san DNS:example.net,DNS:www.example.com,DNS:mail.example.com,DNS:ftp.example.com -pwd abc12345

Export the certificate signing request.

<oracle home>/oracle_common/bin/orapki wallet export -wallet ./foo -dn 'CN=example.com, O=Test CA Limited, L=Baltimore, ST=MD, C=US' -request ./foo/creq.txt -pwd abc12345

Get the CSR Signed by a CA

Submit the exported CSR above to the CA and follow the required process to get it signed by the CA.

Import the CA signed Certificate into Oracle Traffic Director Configuration

Add the CA signed certificate to the wallet.

<oracle home>/oracle_common/bin/orapki wallet add -wallet ./foo -user_cert -cert ./foo/cert.txt -pwd abc12345

Add the root certificate and any intermediate certificates to the wallet as trusted certificates.

<oracle home>/oracle_common/bin/orapki wallet add -wallet ./foo -trusted_cert -cert ./foo/root.txt -pwd abc12345

Check the contents of the wallet using the following command.

<oracle home>/oracle_common/bin/orapki wallet display -wallet ./foo -pwd abc12345 -complete

There is no option in Fusion Middleware console to import the CA signed certificates whose private key is generated outside the KSS. However, this can be done using the importKeyStore command which can import a JKS (Java Key Store) or Oracle Wallet. Note that the keystore must contain the entire certificate chain including the root certificate as well as the private key.

svc = getOpssService('KeyStoreService')
# filepath must be absolute path of the directory containing oracle wallet
svc.importKeyStore(appStripe='OTD', name='foo', password='abc12345', keypasswords='', type='OracleWallet', permission=true, filepath='/scratch/foo')

Viewing a List of Certificates

You can view a list of the certificates installed in a configuration by using either Fusion Middleware Control or the WLST

Viewing a List of Certificates Using Fusion Middleware Control

To view a list of the certificates installed in a configuration by using the administration console, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to view certificates.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Security > Manage Certificates

A new page displays on screen.
Below the common task bar, certificates are listed.

Viewing a List of Certificates Using WLST

To view a list of the certificates installed in a configuration, run the otd_listCertificates command, as shown in the following examples.

The following command displays a list of the server certificates in the configuration.
```
props = {}
props['configuration'] = 'foo'
otd_listCertificates(props)
```

To view the properties of a certificate, run the getKeyStoreCertificatescommand, as shown in the following example.

svc = getOpssService("KeyStoreService")
svc.getKeyStoreCertificates(appStripe='OTD', name='myconfig', password='', alias='mycert')

Deleting a Certificate

You can delete certificates in a configuration by using either Fusion Middleware Control or the WLST.

Note:

The certificates olddemoca and democa belong to the trust keystore in the system stripe and are shared across all Oracle Traffic Director configurations and deleting them will remove them from all of the configurations.

Deleting a certificate using Fusion Middleware Control

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to delete certificates.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Security > Manage Certificates

A new page displays on screen.
Below the common task bar it displays a list of certificates.
Click the Delete button for the certificate that you want to delete.
- If one or more listeners are associated with the certificate that you are deleting, a message is displayed indicating that the certificate cannot be deleted.
- If the certificate that you are deleting is not associated with any listener, a prompt to confirm deletion of the certificate is displayed.
  
  Click OK to proceed.
A message is displayed in the Console Messages pane, confirming that the certificate has been deleted.

Deleting a Certificate Using WLST

To delete a certificate, run the deleteKeyStoreEntry command.

Example:

svc = getOpssService("KeyStoreService")
svc.deleteKeyStoreEntry(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='')

If the certificate that you are deleting is associated with one or more listeners, the following message is displayed.

OTD-64309 Certificate 'rsa-1' is being referred by listeners: listener1,listenerN

You can delete the certificate forcibly by including the --force option.

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information, see deleteKeyStoreEntry in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

Configuring SSL/TLS on Oracle Traffic Director

Topics

Configuring SSL/TLS Between Oracle Traffic Director and Clients

This section describes how you can use SSL/TLS to secure communication between clients and Oracle Traffic Director instances.

To enable SSL/TLS for an OTD instance, you must associate an RSA or ECC certificate, or both, with one or more listeners of the instance.

When an HTTPS request is received, the certificate that Oracle Traffic Director sends to the client during the SSL/TLS handshake could be one of the following:

A certificate associated with a virtual server bound to a configured HTTP listener.
A certificate associated with the HTTP/TCP listener

Configuring SSL on a HTTP/TCP Listener

You can configure a listener to receive HTTPS or TCP requests by using either Fusion Middleware Control or the WLST.

Configuring SSL/TLS for a Listener Using Fusion Middleware Control

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to configure SSL/TLS-enabled listeners.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > Listeners.
Select the listener for which you want to enable and configure SSL/TLS among HTTP listeners/TCP Listeners.

The Listener Settings page is displayed.
Select Settings > SSL/TLS Settings.

The SSL/TLS settings page i s displayed.
In the SSL Settings section, select the SSL Enabled check box.
In the RSA Certificate and ECC Certificate fields, select the certificates that you want to use to authenticate the server.

If you associate a listener with an RSA certificate and with an ECC certificate, the certificate that the server eventually presents to the client is determined during the SSL/TLS handshake, based on the cipher suite that the client and the server negotiate to use.

You can also specify the following advanced SSL/TLS settings in the Advanced Settings section of the Listener Settings page:

Configuring Client Authentication: Client authentication is the verification of a client by the HTTP/TCP Listener based on the certificate that the client provides. Client authentication is not enabled by default. To configure client authentication, do the following:
1. Select Settings > Advanced Settings > SSL/TLS Settings.
  The SSL/TLS settings page is displayed.
2. Select the required SSL/TLS Client Authentication mode.
  - Required: The server requests the client for a certificate; if the client does not provide a certificate, the connection is closed.
  - Optional: The server requests the client for a certificate, but does not require it. The connection is established even if the client does not provide a certificate.
  - Disabled (default): Client authentication is disabled.
3. Specify the Authentication Timeout and Maximum Authentication Data Parameters.
Configuring Ciphers: To enable and disable SSL and TLS ciphers, do the following:
1. Select Settings > Advanced Settings > SSL/TLS Settings.
  The SSL/TLS settings page is displayed
2. In the SSL Settings section, you can select the Ciphers from the available ciphers for the listener.
  
  Note:
  You can select ciphers only if SSL/TLS is enabled for the Listener.
The on-screen help and prompts are provided for all parameters. When you change the value in a field or tab out of a text field that you changed, the Apply button near the upper right corner of the page is enabled. At any time, you can discard the changes by clicking the Revert button.
After making the required changes, click Apply.

A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.
Restart the instances of the configuration by clicking Start/Restart Instances in the Common Tasks pane.

Configuring SSL/TLS for a Listener Using WLST

To view the SSL/TLS properties of an HTTP or TCP listener, run the otd_getHttpListenerSslProperties or otd_getTcpListernerSslProperties command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
otd_getHttpListenerSslProperties(props)

enabled=false
client-auth=false
client-auth-timeout=60
max-client-auth-data=1048576
ssl3=true
tls10=true
tls11=true
tls12=true
override-cipher-order=false
...

To configure SSL/TLS for an HTTP or TCP listener, run the otd_setHttpListenerSslProperties or otd_setTcpListenerSslProperties command, as shown in the following example:
```
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
props['tls10'] = 'false'
otd_setHttpListenerSslProperties(props)
```
Configuring Client Authentication: Client authentication is the verification of a client by the HTTP/TCP Listener based on the certificate that the client provides. Client authentication is not enabled by default. To configure client authentication for a listener, run the otd_setHttpListenerSslProperties/ otd_setTcpListenerSslProperties command.
```
props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'bar'
props['client-auth'] = 'false'
otd_setHttpListenerSslProperties(props)
```
Configuring Ciphers: To view the ciphers that are currently enabled for a listener, run the otd_getHttpListenerSslProperties/otd_getTcpListenerSslProperties command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'bar'
otd_getTcpListenerSslProperties(props)
```
A comma-separated list of ciphers that are currently enabled is returned in the cipher property.
To enable or disable specific ciphers for a listener, run the otd_setHttpListenerSslProperties/otd_setTcpListenerSslProperties command and specify the ciphers to be enabled in the ciphers property.
The list of supported ciphers will be listed as apart of a property "supported-ciphers", when you run the otd_getHttpListenerSslProperties/otd_getTcpListenerSslProperties command.

Configuring SSL On a Virtual Server

Configuring SSL On a Virtual Server Using Fusion Middleware Control

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to configure SSL/TLS-enabled listeners.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > Virtual Servers.

The Virtual Servers page is displayed. It shows a list of the virtual servers defined for the configuration

You can view the properties of a virtual server by clicking on its name.
Select the listener for which you want to enable and configure SSL/TLS.

The Listener Settings page is displayed.
Select Settings > SSL/TLS Settings.

The SSL/TLS settings page is displayed.
In the SSL Settings section, select the SSL Enabled check box.
In the RSA Certificate and ECC Certificate fields, select the certificates that you want to use to authenticate the server.

If you associate a listener with an RSA certificate and with an ECC certificate, the certificate that the server eventually presents to the client is determined during the SSL/TLS handshake, based on the cipher suite that the client and the server negotiate to use.

You can also specify the following advanced SSL/TLS settings in the Advanced Settings section of the Listener Settings page:

Configuring Client Authentication: Client authentication is the verification of a client by the OTD virtual server based on the certificate that the client provides. Client authentication is not enabled by default. To configure client authentication, do the following:
1. Select Settings > Advanced Settings > SSL/TLS Settings.
  The SSL/TLS settings page is displayed.
2. Select the required SSL/TLS Client Authentication mode.
  - Required: The server requests the client for a certificate; if the client does not provide a certificate, the connection is closed.
  - Optional: The server requests the client for a certificate, but does not require it. The connection is established even if the client does not provide a certificate.
  - Disabled (default): Client authentication is disabled.
3. Specify the Authentication Timeout and Maximum Authentication Data Parameters.
Configuring Ciphers: To enable and disable SSL and TLS ciphers, do the following:
1. Select Settings > Advanced Settings > SSL/TLS Settings.
  The SSL/TLS settings page is displayed
2. In the SSL Settings section, you can select the Ciphers from the available ciphers for the listener.
  
  Note:
  You can select ciphers only if SSL/TLS is enabled for the Listener.
The on-screen help and prompts are provided for all parameters. When you change the value in a field or tab out of a text field that you changed, the Apply button near the upper right corner of the page is enabled. At any time, you can discard the changes by clicking the Revert button.
After making the required changes, click Apply.

A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.
Restart the instances of the configuration by clicking Start/Restart Instances in the Common Tasks pane.

Configuring SSL On a Virtual Server Using WLST

To view the certificates that are currently associated with a virtual server, run the otd_getVirtualServerSslProperties command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_getVirtualServerSslProperties(props)
```
max-client-auth-data=1048576

ssl3=false

client-auth=false

tls12=true

tls11=true

override-cipher-order=false

tls10=true

enabled=false

server-cert-alias=None

client-auth-timeout=60
...
To associate a certificate with a virtual server, run the otd_setVirtualServerSslProperties command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['server-cert-alias'] = 'cert-1'
otd_setVirtualServerSslProperties(props)
```
Ensure that a certificate of the same type—ECC or RSA—that you want to associate with the virtual server, is also associated with the listeners to which the virtual server is bound.
Client authentication is the verification of a client by the OTD virtual server based on the certificate that the client provides. Client authentication is not enabled by default. To enable client authentication for an virtual server, run the otd_setVirtualServerSslProperties
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['client-auth'] = 'false'
otd_setVirtualServerSslProperties(props)
```
To view the ciphers that are currently enabled for a Virtual Server, run the otd_getVirtualServerSslProperties command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_getVirtualServerSslProperties(props)
```
A comma-separated list of ciphers that are currently enabled is returned in the cipher property.
To enable or disable specific ciphers for a virtual server, run the otd_setVirtualServerSslProperties command and specify the ciphers to be enabled in the ciphers property.
The list of supported ciphers will be listed as apart of a property "supported-ciphers", when you run the otd_getVirtualServerListenerSslProperties command.

Configuring SSL/TLS Between Oracle Traffic Director and Origin Servers

This section describes how to use SSL/TLS to secure connections between Oracle Traffic Director instances and origin servers that are Oracle WebLogic Server and Oracle HTTP Server instances. It contains the following topics:

About One-Way and Two-Way SSL/TLS

The connections between Oracle Traffic Director and origin servers in the back end can be secured using one-way or two-way SSL/TLS.

One-way SSL/TLS: The SSL/TLS-enabled origin server presents its certificate to the Oracle Traffic Director instance. The Oracle Traffic Director instance is not configured to present any certificate to the origin server during the SSL/TLS handshake.
Two-way SSL/TLS: The SSL/TLS-enabled origin server presents its certificate to the Oracle Traffic Director instance. The Oracle Traffic Director instance too presents its own certificate to the origin server. The origin server verifies the identity of the Oracle Traffic Director instance before establishing the SSL/TLS connection. Additionally, either end of the SSL/TLS connection—Oracle Traffic Director and/or origin servers—can be configured to verify the host name while exchanging certificates.

Configuring One-Way SSL/TLS

Import a trusted certificate. For information about importing a certificate as trusted certificate into Oracle Traffic Director, see Importing a Trusted Certificate.
Configure Oracle Traffic Director to verify the host name in the origin server's certificate by using the command otd_setOriginServerPoolSslProperties, if required.
Syntax:
```
otd_setOriginServerPoolSslProperties(props)
```
Example:
```
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'bar'
props['validate-server-cert-hostname'] = 'true'
otd_setOriginServerPoolSslProperties(props)
```
Note:
Since Oracle Traffic Director is configured to validate the host name in the origin server's certificate during the SSL/TLS handshake, the following must be done to avoid failure. When the origin server presents its certificate, Oracle Traffic Director cannot validate the host name in the certificate, and so the SSL/TLS handshake fails.
- Ensure that the server name (CN) in the origin server's certificate matches the origin server's hostname as specified in the origin-server pool of the OTD configuration. For more information about configuring origin-server pools, see Managing Origin-Server Pools
- Ensure that dynamic discovery is disabled (default setting). For more information about dynamic discovery, see Configuring an Oracle WebLogic Server Cluster as an Origin-Server Pool

Configuring Two-Way SSL/TLS

To configure two-way SSL/TLS between Oracle Traffic Director and origin servers, do the following:

Perform the procedure for configuring one-way SSL/TLS, as described in Configuring One-Way SSL/TLS Between Oracle Traffic Director and Origin Servers.
Obtain a CA-issued server certificate for Oracle Traffic Director, as described in Obtaining a Certificate.
Install the CA-issued server certificate in the Oracle Traffic Director configuration, as described in Importing a Certificate.

Configure the required Oracle Traffic Director route with the certificate that Oracle Traffic Director should present to the origin server, by using the otd_enableRouteAuth WLST.

Syntax:

otd_setOriginServerPoolSslProperties(props)

Example:

props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'bar'
props['client-cert-alias'] = 'baz'
otd_setOriginServerPoolSslProperties(props)

Export the root certificate of the CA that signed the certificate for the OTD, from the keystore.
Syntax
```
svc = getOpssService("KeyStoreService")
svc.exportKeyStoreCertificate(appStripe='<stripe>', name='<keystore>', password='<password>', alias='<alias>', type='<entrytype>', filepath='<absolute_file_path>')
```
svc is the service command object obtained through a call to getOpssService(), appstripe is the name of the stripe containing the keystore, name is the name of the keystore, password is the keystore password

alias is the alias of the entry to be exported

type is the type of keystore entry to be exported. Valid values are Certificate, Trusted Certificate, and Certificate Chain

filepath is the absolute path of the file where certificate, trusted certificate or certificate chain is exported
Example:
```
svc = getOpssService("KeyStoreService")
svc.exportKeyStoreCertificate(appStripe='OTD', name='myconfig', password='', alias='rootca', keypassword='', type='TrustedCertificate', filepath='/scratch/rootcert.txt')
```
For more information about the exportKeyStoreCertificate command, run the following command:
```
svc = getOpssService("KeyStoreService")
svc.help('exportKeyStoreCertificate')
```
Import the root certificate that you exported in the previous step into the trust keystore of the origin servers.
Configure the origin servers to require Oracle Traffic Director to present its client certificate during the SSL/TLS handshake.
- For Oracle WebLogic Server origin servers:
  
  Perform the procedure described in Configure two-way SSL in the Oracle WebLogic Server Fusion Middleware Control Online Help.
  
  Note:
  
  By default, host name verification is enabled in Oracle WebLogic Server. For information about disabling host name verification, see Disable host name verification in the Oracle WebLogic Server Fusion Middleware Control Online Help.
- For Oracle HTTP Server origin servers:
  
  Add the following directive in the httpd.conf file: SSLVerifyClient require

Configuring Ciphers On an Origin Server Pool

Configuring Ciphers On an Origin Server Pool Using Fusion Middleware Control

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to configure ciphers.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Administration > Origin Server Pool.

The Origin Server Pools page is displayed. It shows a list of the Origin Server Pools defined for the configuration.
Select the Origin Server Pool for which you want to configure ciphers.
The Origin Server Pool Settings page is displayed.
Select Settings > Advanced Settings > SSL/TLS Settings.
The SSL/TLS settings page is displayed.
You can select ciphers only if SSL/TLS is enabled for the Origin Server Pool.
In the SSL Settings section, you can manage the Certificates.
When you change the value in a field or tab out of a text field that you changed, the OK button near the upper right corner of the page is enabled.

At any time, you can discard the changes by clicking the Cancel button.
After making the required changes, click OK.

A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.

Configuring Ciphers On an Origin Server Pool Using WLST

To view the ciphers that are currently enabled for a Origin Server Pool, run the otd_getOriginServerPoolSslProperties command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'bar'
otd_getOriginServerPoolSslProperties(props)
```
A comma-separated list of ciphers that are currently enabled is returned in the cipher property.
To enable or disable specific ciphers for a virtual server, run the otd_setOriginServerPoolSslProperties command and specify the ciphers to be enabled in the ciphers property.
The list of supported ciphers are listed as apart of a property, supported-ciphers, when you run the otd_getOriginServerPoolSslProperties command.

Configure SSL Termination At a Hardware Load Balancer front-ending Oracle Traffic Director

This section will go through the list of configuration steps necessary to handle this use case where customers want to terminate SSL at an external hardware load balancer front ending Oracle Traffic Director.

In a typical production deployment topology (as shown below), customers terminate SSL within the (external) hardware load balancer and have only HTTP communication within the internal load balancer (reverse proxy) and application tiers.

Description of GUID-E84FF9BD-78B8-49BC-ADF8-2C4C8F97D52E-default.jpg follows

Description of the illustration GUID-E84FF9BD-78B8-49BC-ADF8-2C4C8F97D52E-default.jpg

In this scenario, customers need to perform a few additional steps within the internal load balancer / reverse proxy solution as well as the application tiers so that any request redirect can happen correctly. This section will focus on the steps necessary within the internal load balancer (OTD) / reverse proxy solution.

Configure OTD to pass SSL information.
1. Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
2. Click the WebLogic Domain button at the upper left corner of the page.
3. Select Administration > OTD Configurations.
  A list of the available configurations is displayed.
4. Select the configuration for which you want to configure ciphers.
5. Click the Traffic Director Configuration In the Common Tasks pane.
6. Select Administration > Virtual Servers.
  The Virtual Servers page is displayed, with a list of the Virtual Servers defined for the configuration.
7. Select the Virtual Server for which you want to configure ciphers.
  The Virtual Server Settings page is displayed.
8. Click on Routes tab and select the route that needs to be changed.
9. Select Advanced Settings, and do the following:
  - Update Route.
  - Disable OTD from rewriting any 'Location' or 'Content-Location' headers by changing 'Rewrite-headers' to be empty. This is important when SSL termination is on at an external load balancer.
  - Uncheck all SSL related headers sent to the origin server.
10. After making the required changes, click OK.
  
  A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.
  
  At the end of the above step, OTD now does NOT rewrite any headers (typically this happens when the application tier redirects the request to another location) and can pass the external hardware load balancer provided SSL information, via the incoming request headers within the incoming requests to origin servers.
Configure F5-BigIP to send SSL information via headers to OTD.

If you choose to terminate SSL within the hardware load balancer such as F5-BigIp, then you will need to configure this hardware load balancer to explicitly send a specific header - WL-Proxy-SSL - to OTD and WLS.

This procedure explains how to configure F5-BigIp to send this header (Source: F5 Big IP product documentation).
1. On the Main tab, expand Local Traffic, and then click Profiles. The HTTP Profiles screen opens.
2. In the upper right portion of the screen, click the Create button. The New HTTP Profile screen opens.
3. In the Name box, type a name for this profile. In our example, we type bea-ssl.
4. From the Parent Profile list, select http-acceleration if you are using the WebAccelerator. If you are not using the WebAccelerator, select http-wan-optimized-compression-caching.
5. In the Request Header Insert row, check the Custom box. In the box, type: WL-Proxy-SSL:true.
6. In the Redirect Rewrite row, check the Custom box. From the Redirect Rewrite list, select Match.
7. Modify any of the other settings as applicable for your network. In our example, we leave the settings at their default levels.
8. Click Finish.
  
  If you are also using OTD to front-end Oracle Access Manager (OAM/IDM), then you will need to configure your hardware load balancer to additionally insert header 'IS_SSL:ssl' to the incoming request headers.

Configure WebLogic to receive SSL information from Web Tier / Traffic Director

When Oracle Traffic Director is terminating a connection, the attribute 'WebLogic Plug-In Enabled' in WebLogic Server Fusion Middleware Control can be set to 'true'. This way, Oracle Traffic Director communicates the certificate information to the applications deployed on the WebLogic Server. An application can then validate for specific information in the certificate, such as key size or cipher, before allowing the clients to access the application. This flag can be tuned on either within a specific WebLogic Managed Server or at WebLogic cluster level. This ensures that WebLogic is able to appropriately rewrite the headers when SSL termination happens within Traffic Director / Web Tier.

Open http://<wls-admin-hostname>:7001/console and login with weblogic user/password.
Within WLS Managed Server, 'Configuration->General' settings tab, expand 'Advanced Settings' and scroll down to check "Weblogic Plugin Enabled" to 'Yes' and click "Save".
If you have Weblogic cluster enabled, then we recommend doing this at cluster level.

Configure SSL Pass through on Oracle Traffic Director

Oracle Traffic Director when configured for TCP load balancing with a TCP proxy and TCP listeners can be used for SSL pass-through for any TCP based protocol including HTTPS. In this case, the requests are handled as generic TCP connections and SSL will be terminated at the origin servers for HTTPS/LDAPS/FTPS/T3S, and so on.

Managing Certificate Revocation Lists

A Certificate Revocation List (CRL) is a list that a CA publishes to inform users about certificates that the CA has decided to revoke before they expire. CRLs are updated periodically; the updated CRLs can be downloaded from the CA's website.

To ensure that Oracle Traffic Director servers do not trust server certificates that have been revoked by CA, you should download the latest CRLs from the CAs' websites regularly and install them in your Oracle Traffic Director configurations.

You can install CRLs manually. You can also configure Oracle Traffic Director to take the downloaded CRLs from a specified directory and install them automatically at specified intervals.

Installing and Deleting CRLs Manually

You can install and delete CRLs manually by using either Fusion Middleware Control or the WLST.

Installing CRLs Manually Using Fusion Middleware Control

You can install and delete CRLs manually by using either Fusion Middleware Control or the WLST.

To install a downloaded CRL by using the Fusion Middleware Control, do the following:

Log in to Fusion Middleware Control, as described in Displaying Fusion Middleware Control.
Click the WebLogic Domain button at the upper left corner of the page.
Select Administration > OTD Configurations.

A list of the available configurations is displayed.
Select the configuration for which you want to install a certificate.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Security > Certificate Revocation List

A new page displays on screen.
Click the Install CRL button.

The Install Certificate Revocation List dialog box is displayed.
Specify the location of the downloaded CRL file, and click Install CRL.
- A message, confirming successful installation of the CRL, is displayed in the Console Messages pane.
- The CRL that you just installed is displayed on the Certificate Authorities page.

Installing and Deleting CRLs Manually Using WLST

To install a downloaded CRL, run the otd_installCrl command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['file-path'] = '/export/ServerSign.crl'
otd_installCrl(props).

To view a list of the installed CRLs in a configuration, run the otd_listCrls command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
otd_listCrls(props)
---------------------------
"Class 1 Public Primary Certification Authority" "Sat Apr 15 16:59:59 PDT 2000"
"VeriSign Class 3 Code Signing 2010 CA" "Mon Aug 29 14:00:03 PDT 2011"
"VeriSign Class 3 Organizational CA" "Sun May 18 13:48:16 PDT 2014"

To delete a CRL, run the otd_deleteCrl command, as shown in the following example:
```
props = {}
props['configuration'] = 'foo'
props['issuer'] = 'CN=GlobalSign ServerSign CA,OU=ServerSign CA,O=GlobalSign nv-sa,C=BE'
otd_deleteCrl(props)
```
When you delete a CRL, it is removed from the Oracle Traffic Director configuration and from the directory in which the downloaded CRL was stored.

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information about the WLST commands mentioned in this section, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the commands with the --help option.

Update CRLs Automatically

You can configure Oracle Traffic Director to periodically take downloaded CRL files from a specified directory and install them automatically by using either Fusion Middleware Control or the WLST.

At the specified interval, Oracle Traffic Director looks for updated CRL files in the specified directory.

If Oracle Traffic Director detects new CRL files, it installs them in the configuration and logs a message in the server log.
If existing CRL files have been changed, Oracle Traffic Director installs the updated CRL files in the configuration and logs a message in the server log.
If Oracle Traffic Director detects that previously installed CRL files have been removed from the directory, it deletes the CRLs from the configuration and logs a message in the server log.
If no changes are detected in the CRL directory, Oracle Traffic Director does not perform any update.

Configuring Oracle Traffic Director to Install CRLs Automatically Using Fusion Middleware Control

Configure Oracle Traffic Director to install CRLs automatically using the Fusion Middleware Control.

Log in to Fusion Middleware Control, as described in Graphical User Interface-Fusion Middleware Control
Click WebLogic Domain.
Select Administration > OTD Configurations.
Click the name of the configuration that you want to set up to install CRLs automatically.
Click the Traffic Director Configuration In the Common Tasks pane.
Select Security > Certificate Revocation List .
Click the Install CRL button.
Specify the location of the downloaded CRL file, and click Install CRL.
- A message, confirming successful installation of the CRL, is displayed in the Console Messages pane.
- The CRL that you just installed is displayed on the Certificate Authorities page.
Go to the Advanced Settings section of the page.
In the CRL Update Event field, enter the absolute path to the directory that contains the updated CRL files.
Click New Event
Specify the interval or time of the day at which the CRLs should be updated, and then click OK.
- A message, confirming creation of the event, is displayed in the Console Messages pane.
- The new event is displayed in the CRL Update Events list.
  - New events are enabled by default. To change the status, select the Enable/Disable check box.
  - To delete an event, click the Delete button.

Configuring Oracle Traffic Director to Install CRLs Automatically Using WLST

Configure Oracle Traffic Director to install CRLs automatically.

Schedule an event for Oracle Traffic Director to take the downloaded CRLs from the specified directory and install them automatically, by using the otd_createEvent command.

For example, the following command specifies that the CRLs for the configuration foo should be updated after every 12:00.

props = {}
props['configuration'] = 'foo'
props['event'] = 'event-1'
props['command'] = 'update CRL'
props['time'] = '12:00'
otd_createEvent(props)

For more information, see the otd_createEvent command in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the commands with the --help option.