Configuring Security 5-3
Different CAs may have different identification requirements when issuing certificates. One may require the presentation of a users drivers license, while another
may require notarization of the certificate request form, or fingerprints of the requesting party.
The CA publishes its own certificate, which includes its public key. Each network entity has a list of certificates of the CAs it trusts. Before communicating with another
entity, a given entity uses this list to verify that the signature on the other entitys certificate is from a known, trusted CA.
Network entities can obtain their certificates from the same or different CAs. By default, Oracle Wallet Manager automatically installs with trusted certificates from
VeriSign, RSA, Entrust, and GTE CyberTrust.
5.1.1.2.2 Certificate A certificate is a digital data record used for authenticating
network entities such as a server or a client. It is created when a partys public key is signed by a trusted CA. A certificate ensures that a partys identification information is
correct, and that the public key actually belongs to that party.
A certificate contains the partys name, public key, and an expiration date—as well as a serial number and certificate chain information. It can also contain information about
the privileges associated with the certificate.
When a network entity receives a certificate, it verifies that it is a trusted certificate—one issued and signed by a trusted certificate authority. A certificate
remains valid until it expires or is terminated.
Oracle Web Cache supports the following:
■
Server-side certificates: A server-side certificate is a method for verifying the
identity of the contacted server. It binds information about the server to the servers public key and must be signed by a trusted CA.
For server-side certificates, Oracle Web Cache sends the server certificate to the client browser during the SSL handshake, then processes the request for the object.
If the requested object is not stored in the cache, the cache forwards the request to the application Web server, a peer cache in a cluster, or a subordinate cache in a
hierarchy.
One server-side certificate is required for each unique site configuration. HTTPS does not support multiple virtual hosts on a single port. For example, an
environment with 20 site IP address and port number configurations requires 20 separate certificates.
■
Client-side certificates: A client-side certificate is a method for verifying the
identity of the client. It binds information about the client user to the users public key and must be digitally signed by a trusted CA. Certificate Revocation Lists
CRLs validate the peer certificate in the SSL handshake and ensure that the certificate is not on the list of revoked certificates issued by the CA.
For client-side certificates, the client browser sends the certificate to the cache during the SSL handshake, then the cache processes the request for the object. If
the requested object is not stored in the cache, the cache forwards the request to the application Web server, a peer cache in a cluster, or another cache in a
hierarchy. To transfer information about the client-side certificate to another cache or to the application Web server, Oracle Web Cache adds HTTP headers to
the request. These headers begin with the string SSL-Client-Cert.
In addition, depending on your deployment, you configure caches to accept the certificate information in HTTP headers from peer caches or from any entities
5-4 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache
such as a provider or remote cache or to not accept the certificate information in headers.
Note the following about client-side certificates:
■
Client-side certificates are not required for HTTPS requests. They are generally used when PKI-based user authentication is needed, such as in
finance, government, or military applications.
■
You can specify that an entire site require client-side certificates.
■
If the listening port requires client certificates, then the connection is refused. If the site requires client certificates and the SSL port does not, then HTTP
error 403 Forbidden returns.
■
Oracle Web Cache supports the use of client-side certificates with Oracle HTTP Server only.
■
Oracle Web Cache does not support client-side certificates with a distributed cache hierarchy because the security of the certificates cannot be guaranteed.
■
Although the Oracle HTTP Server supports OpenSSL certificate revocation lists, Oracle Web Cache does not. If you use client-side certificates, you must
modify your application to check if the client-side certificate has been revoked. You can do this using a CGI script or servlet.
■
Oracle Fusion Middleware does not support Microsoft Server Gated Cryptography Certificates SGC or VeriSign Global Server IDs. This
cryptography enables export version browsers to transparently upgrade to strong 128-bit encryption from weaker 40-bit encryption when communicating
with an application server. Without this cryptography, browsers with the weaker 40-bit encryption cannot negotiate a secure connection to Oracle
Fusion Middleware.
5.1.1.2.3 Wallet A wallet is a repository used to manage authentication data such as
keys, certificates, and trusted certificates needed by SSL. A wallet has an X.509 version 3 certificate, private key, and list of trusted certificates.
Security administrators use Oracle Wallet Manager to manage security credentials on the Oracle Web Cache server. Wallet owners use it to manage security credentials on
clients. Specifically, Oracle Wallet Manager is used to do the following:
■
Generate a public-private key pair and create a certificate request for submission to a certificate authority.
■
Install a certificate for the identity.
■
Configure trusted certificates for the identity. To configure HTTPS for Oracle Web Cache, create a wallet on the Oracle Web Cache
server for each supported site. You specify the location of the wallet for each of the Oracle Web Cache HTTPS listening and operations ports to support incoming HTTPS
requests, and the origin server to support outgoing HTTPS requests. You can share one wallet, or you can create separate wallets. If you use the same wallet, keep in mind
that it can support only one server-side certificate.
Note that Oracle Web Cache installs a default wallet with a default certificate, but this wallet should only be used for testing purposes, not in production environments. The
SSL connection is not considered secure when using the default wallet. In a production environment, create a new wallet and create a new certificate or import a trusted
certificate into the wallet.
Configuring Security 5-5
See Oracle Fusion Middleware Administrators Guide for further information about Oracle Wallet Manager.
5.1.1.2.4 How SSL Works To describe how SSL works in an HTTPS connection, the
word client is used to describe either a browser or Oracle Web Cache, and the word server is used to describe either Oracle Web Cache or an origin server. For example,
when a browser is the client, the server can be Oracle Web Cache or an origin server; when Oracle Web Cache is the client, the server can be an origin server.
The authentication process between the client and server consists of the steps that follow:
1.
The client and server determine which cipher encryption algorithm to use.
2.
SSL performs the handshake between the client and the server to establish a secure connection.
An SSL handshake includes the following actions:
1.
The client and server establish which cipher suites to use.
2.
The server sends its certificate to the client, and the client verifies that the servers certificate was signed by a trusted CA.
3.
Optionally, the server requests a client certificate and the client responds by sending the client certificate to the server. The server verifies that the client
certificate was signed by a trusted CA.
4.
The client and server exchange key information using public key cryptography; based on this information, each generates a session key. All subsequent
communications between the client and the server is encrypted and decrypted by using this set of session keys and the cipher.
5.1.1.3 SSL Acceleration
Oracle Web Cache provides SSL acceleration by moving the SSL processing to the Web tier.
In addition to off-board SSL acceleration solutions, Oracle Fusion Middleware supports both software-only SSL operations and nCiphers BHAPI-compliant
hardware for deployment on servers running Oracle Web Cache and Oracle HTTP Server. When executed in software, SSL operations place a strain on server CPU
resources, causing a reduction in throughput and slower overall performance. The nCipher hardware off loads the SSL key exchange processing from a servers CPUs,
increasing the number of concurrent SSL connections and improving response times for SSL-protected content.
See http:www.ncipher.com
for more information about nCipher.
5.1.2 Resources Protected
By default, the user that performed the installation is the owner of Oracle Web Cache files. Most files are readable by the user ID specified in the Process Identity page of
Oracle Web Cache Manager Properties Process Identity.
If you change the process identity user, you must manually change the ownership of Oracle Web Cache files and directories to the new user ID and group ID with the
chown command.
5-6 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache
5.1.3 Authorization and Access Enforcement
The mod_access module of Oracle HTTP Server controls access to the URLs based on characteristics of a request, such as host name or IP address. Oracle Web Cache does
not restrict IP address restrictions on a URL basis. If you are using mod_access with Oracle Web Cache, ensure that the protected resources are not cached either by not
specifying a caching rule or by explicitly setting a caching rule not to cache the content.
To pass the client IP directly to the Oracle HTTP Server, configure the Order directive in the httpd.conf file. For more information, see the Oracle Fusion Middleware
Administrators Guide for Oracle HTTP Server.
5.1.4 Leveraging Oracle Identity Management Infrastructure
The Oracle Identity Management infrastructure centralizes management of security across the enterprise
■
Section 5.1.4.1, About Caching Content from Oracle Single Sign-On Servers
■
Section 5.1.4.2, About Caching Oracle Single Sign-On Partner Applications mod_ osso
■
Section 5.1.4.3, About Authentication through Oracle Single Sign-On
5.1.4.1 About Caching Content from Oracle Single Sign-On Servers
For security reasons, you should not cache content from Oracle Single Sign-On servers
5.1.4.2 About Caching Oracle Single Sign-On Partner Applications mod_osso
You can configure Oracle Web Cache to cache content for Oracle HTTP Servers running Single Sign-On partner applications. By default, mod_osso protected pages
are configured as non-cacheable with a Surrogate-Control: no-store response header.
To override mod_osso default behavior, set OssoSendCacheHeaders to off in the httpd.conf file. For example:
Location foo OssoSendCacheHeaders off
Location
This example disables the setting by mod_osso of any cache headers for any URL that starts with foo. For these URLs, the application is responsible for setting the cache
control headers, including Surrogate-Control as appropriate.
If Oracle Web Cache is load balancing requests for identical Single Sign-On partner applications, configure the Oracle HTTP Servers as a cluster, so the applications act as
a single partner application. You can then configure Oracle Web Cache to perform stateless load balancing of requests to the servers. If the application mid-tier is not
clustered, stateful load balancing is necessary.
5.1.4.3 About Authentication through Oracle Single Sign-On
You can configure Oracle Web Cache to require authentication through Oracle Single Sign-On. Incoming requests must have a valid Oracle Single Sign-On cookie to be
served by Oracle Web Cache. See Section 5.8
for configuration details.
Configuring Security 5-7
5.2 Configuring Password Security
Before submitting invalidation and statistics monitoring requests, establish secure passwords for sending the requests.
The invalidator account is an administrator authorized to send invalidation requests. The invalidator account sends HTTP POST requests to invalidate objects
in the cache.
The administrator account is the Oracle Web Cache administrator authorized to log in to Oracle Web Cache Manager and make configuration changes through that
interface. This administrator is also authorized to send statistic monitoring requests to the Oracle Web Cache statistics monitoring port. If after monitoring metrics from
Fusion Middleware Control you need additional performance metrics, you can access the statistic monitoring port with the administrator account to view detailed
performance metrics. See
Section 8.4 .
The default password for these accounts is the password you supplied in the Web Cache Administrator page of the Oracle Universal Installer. Before you begin
configuration, change the passwords for these accounts to a secure password. You must perform this configuration in Fusion Middleware Control.
To establish secure passwords for the invalidator and monitor accounts:
1.
Navigate to the Web Cache Home page in Fusion Middleware Control. See Section 2.6.2
.
2. From the Web Cache menu, select Administration Passwords.
The Passwords page displays.
3. In the New Password field, enter a new password, keeping the following
restrictions in mind:
■
Passwords must be between 5 and 30 characters.
■
At least one character must be a number.
■
Passwords can contain only alphanumeric and underscore _ characters.
■
Passwords must begin with an alphabetic character. Passwords cannot begin with a number, the underscore _, the dollar sign , or the number sign .
■
Passwords cannot be Oracle reserved words. The Oracle Database SQL Reference lists the reserved words.
4. In the Confirm Password field, reenter the new password to confirm you entered
the password correctly.
5. Click Apply.
6.
Restart Oracle Web Cache. See Section 2.13
. If Oracle Web Cache is not restarted, you may encounter an error when accessing
some Fusion Middleware Control pages.
5.3 Configuring Access Control
By default, the computer on which you installed Oracle Web Cache is the trusted host. You can change the trusted subnet or trusted host from which administration,
invalidation, and statistics monitoring requests can take place.
To specify if some or all of the traffic to an application is restricted to use HTTPS:
