This chapter contains the following sections:
Before you begin administering Oracle Traffic Director security, you need to understand some basic concepts about Oracle Traffic Director security management, the set of security standards supported by Oracle Traffic Director , and the tasks involved in securing an Oracle Traffic Director domain.
This section provides basic information about security-related concepts. It contains the following topics:
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 Transport Layer Security (TLS) v1, v1.1, v1.1, v1.2 and v1.3.
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 http
s
://
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.
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.
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.1, 1.2
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_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
Cipher Suites Supported in Oracle Traffic Director
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_256_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_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
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.
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
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 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).
To obtain a digital certificate, you must generate a Certificate Signing Request (CSR) and issue it to a reputable CA. The CA returns a digital certificate that is signed with the CA's private key and that is used for establishing identity. You then import the digital certificate for identity into your identity keystore.
This section contains the following topics:
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 Keypairfor 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 section Generating 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 req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 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='foo', password='<keystore password>', keypasswords='key passwords', type='OracleWallet', permission=true, filepath='<directory containing wallet>')
Using orapki
cd <ORACLE_HOME>/oracle_common/bin ./orapki wallet create -wallet ./myservercert -pwd <password> ./orapki wallet add -wallet ./myservercert -keysize 1024 -dn "CN=Custom_Root_CA,O=oracle,C=US" -self_signed -validity 3650 -pwd <password>
# Importing the certificate using wlst command svc = getOpssService("KeyStoreService") svc.importKeyStore(appStripe='OTD', name='foo', password='<keystore password>', keypasswords='<key passwords>', type='OracleWallet', permission=true, filepath='<directory containing wallet>')
You can generate a keypair if you do not need your certificate to be signed by a CA, or if you want to test the SSL/TLS implementation while the CA is in the process of signing your demo CA certificate.
Note that if you use a keypair to enable SSL/TLS for an Oracle Traffic Director virtual server, when a client accesses the https://
URL of the virtual server, an error message is displayed indicating that the signing CA is unknown and not trusted. To proceed with the connection, the client can choose to trust the self-signed certificate.
You can generate a keypair by using either Fusion Middleware Control or the WLST.
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.
See RSA and ECC Certificates.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.com', OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024', ext_san="DNS:test.com,DNS:www.test.com,DNS:my.test.com")
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate
command.
See generateKeyPair
in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help
option.
Note:
Alternate domain names for the server (also known as Subject Alternate Names or SAN) can be added to the keypair using the ext_san
parameter. Ensure that you specify the correct syntax for specifying domain names.
Since many modern browsers ignore the CN (Common Name) field when matching hostnames, you may need to add the domain name mentioned in the CN as an alternate domain name as well using the ext_san
parameter to ensure browser interoperability.
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.
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. 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.
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
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
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')
Existing certificates could be self signed certificates or certificates with keypair generated outside the current Oracle Traffic Director installation.
Note:
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.Importing an Existing Certificate Using WLST
Import JKS keystore: The following commands show how the CA signed certificate, the private key and CA certificate can be added to a JKS keystore which can then be imported into the Oracle Traffic Director configuration using WLST commands.
# 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 cat intermediate.pem root.pem > cacert.pem 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 # Import the JKS key store created above into the OTD configuration using WLST: svc = getOpssService("KeyStoreService") svc.importKeyStore(appStripe='OTD', name='foo', password='<keystore password>', keypasswords='key passwords', aliases='myservercert', type='JKS', permission=true, filepath='mykeystore.jks')
Import Oracle Wallet: The certificate can also be imported from an Oracle wallet provided the wallet contains the CA signed certificate, the private key, the CA certificate and any intermediate certificates that are needed to form the certificate chain.
svc = getOpssService("KeyStoreService") svc.importKeyStore(appStripe='OTD', name='foo', password='<keystore password>',keypasswords='key passwords', type='OracleWallet', permission=true, filepath='<directory containing wallet>')
-----BEGIN CERTIFICATE----- (Trusted certificate) -----END CERTIFICATE-----
Importing a Trusted Certificate Using Fusion Middleware Control
importKeyStoreCertificate
command, as shown in the following example.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')
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 getKeyStoreCertificates
command, as shown in the following example.
svc = getOpssService("KeyStoreService") svc.getKeyStoreCertificates(appStripe='OTD', name='myconfig', password='', alias='mycert')
You can delete certificates in a configuration by using either Fusion Middleware Control or the WLST.
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.
Learn how to configure Oracle Traffic Director to use Secure Sockets Layer (SSL)/ Trasport Layer Security (TLS).
Topics
Configuring SSL/TLS Between Oracle Traffic Director and Clients
Configuring SSL/TLS Between Oracle Traffic Director and Origin Servers
Configure SSL Termination At a Hardware Load Balancer front-ending Oracle Traffic Director
Configure WebLogic to receive SSL information from Web Tier / Traffic Director
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:
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:
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.
To configure two-way SSL/TLS between Oracle Traffic Director and origin servers, do the following:
Configuring Ciphers On an Origin Server Pool Using Fusion Middleware Control
Log in to Fusion Middleware Control, as described in Graphical User Interface-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.
This section lists the 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.
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 (Oracle Traffic Director) / reverse proxy solution.
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.
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.
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.
Related Topics
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:
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.
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.
To configure Oracle Traffic Director to install CRLs automatically using WLST, do the following:
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)
See the otd_createEvent
command in the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the commands with the --help
option.