IS VERY IMPORTANT TO UNDERSTAND HOW SECURE
SITES ARE MADE ONLINE, IS AGAIN ABOUT JAVA, THE PAGE IS TRANSFERRED
WITH ITS INFORMATION ONCE AND ONLY ONCE, WILL BE RENDERED AS A TOKEN
THE BROWSERS PRODUCE BY DEFUALT 2 KEYS ONE OF
THEM IS SAVED ENCRYPTED OR NOT AS A PRIVATE TO ENSURE COMPLETE
SECURITY.
YOU WILL BE REFERRED WITH MESSAGES, ALSO
YOU WILL BE USING A LOGIC SERVER AS A CERTIFICATE AUTHORITY SOOURCE.
WebLogic SSL offers private and reliable connections using SSL (Secure
Sockets Layer), the standard protocol for secure web connections developed
by Netscape Communications.
SSL provides secure connections by allowing two applications connecting
over a network to authenticate the others' identity and by
encrypting the data exchanged between the applications.
Authentication allows a client or server application to verify the
identity of the application on the other end of a network connection.
Encryption makes data transmitted over the network intelligible only to
the intended recipient.
WebLogic SSL implements the SSL 3.0 specification. It
does not support SSL 2.0. WebLogic Server includes a pure-Java SSL
implementation. A native library that provides faster performance for some
SSL operations is provided for some platforms. The native version is used
automatically if it exists.
WebLogic Server supports SSL on a dedicated listen port, which defaults
to port 7002. To establish an SSL connection, a web browser connects to
WebLogic Server by supplying the SSL listen port and the HTTPS schema in
the connection URL, for example https://myserver:7002.
A Java application can get an SSL connection to WebLogic Server by
supplying the T3S schema in the connection protocol. For example, to
connect with JNDI, a client sets the Context.PROVIDER_URL environment variable to the WebLogic
Server URL with the t3s schema, as in this example:
Context ctx = null;
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
ht.put(Context.PROVIDER_URL,
"t3s://localhost:7001");
try {
ctx = new InitialContext(ht);
// Use the context in your program
}
catch (NamingException e) {
}
finally {
try {ctx.close();}
catch (Exception e) {
}
}
SSL is computationally intensive and adds significant overhead to a
connection. You should avoid using it when it is not necessary. For
example, in an e-commerce application, use the regular HTTP protocol for
catalog searches, then switch to HTTPS to secure the customer's personal
data during order processing. HTTPS connections take longer to negotiate.
By default, WebLogic Server waits up to 25 seconds for an SSL connection
before it times out the connection (as opposed to 5 seconds for a plain
connection). You may need to configure a higher connection timeout value
for SSL. See
Setting
client timeout in Setting WebLogic properties for help.
An SSL connection begins with a handshake protocol during which the
applications exchange certificates, agree on the encryption algorithms to
use, and generate the encryption keys used for the remainder of the
session.
Authentication
SSL uses public key encryption technology for authentication. With
public key encryption, a public key and private key are generated for an
individual or other entity such as a web server or application server. The
keys are related such that data encrypted with the public key can only be
decrypted using the corresponding private key. The private key is
carefully protected so that only the owner can decrypt messages. The
public key, however, is distributed freely so that anyone can encrypt
messages intended for the owner.
Certificates
With SSL, the public key is embedded into a certificate (also
called a digital ID) with additional information describing the
owner of the public key, such as name, street address, and e-mail address.
To support SSL connections for clients, you need to obtain a server
certificate and install it in WebLogic Server. The server certificate
includes the URL of the WebLogic Server, for example, http://www.yourdomain.com.
The data embedded in a certificate is verified by a certificate
authority (CA) and digitally signed with the CA's certificate.
Well-known certificate authorities include VeriSign and
Entrust.net. VeriSign, for example,
offers different certification types that indicate to what degree VeriSign
has verified the certificate holder.
A CA certificate that is used to sign other certificates is called a
root certificate. Root certificates for trusted CAs are installed
into applications that authenticate certificates. For example, web
browsers are usually distributed with several common CA root certificates
pre-installed. If you want WebLogic Server to also be able to authenticate
certificates presented by its clients, you can install up to four CA root
certificates. WebLogic Server will authenticate only client certificates
issued by one these CAs.
An application participating in a an SSL connection is authenticated
when the other party evaluates and accepts their certificate. Web
browsers, web servers, and other SSL-enabled applications generally accept
as genuine any certificate that is signed by a trusted CA and is otherwise
valid. For example, a certificate can be invalidated because it has
expired or the CA certificate used to sign it has expired. A server
certificate can be invalidated if the URL of the server that presented the
certificate does not match the URL embedded in the certificate. Web
browsers are usually configured to warn the user when they encounter a
suspect certificate and let the user decide whether to continue with the
connection.
One-way and two-way authentication
SSL authentication can be one-way or two-way. With one-way
authentication, which is the WebLogic Server default, the server is
required to present a certificate to the client, but the client is not
required to present a certificate to the server. To successfully negotiate
an SSL connection, the client must authenticate the server, but the server
will accept any client into the connection. One-way authentication is
common on the Internet, where customers want to create secure connections
before they share personal data.
With two-way authentication, the client also presents a certificate to
the server. WebLogic Server can be configured to require clients to submit
certificates issued by any of up to four specified CAs.
Client authentication is useful when you must restrict access to
trusted clients only. For example, you could restrict access by accepting
only clients with certificates you provide them. In this case, you are the
CA. This requires additional software that allows you to generate
certificates. (With BEA software, you can generate a certificate
request to submit to a CA, but you cannot generate a
digitally-signed certificate.)
WebLogic Server also supports server-to-server authentication, where a
server can request a secure connection to another server and a server can
be configured to require high security connections.
Encryption
The protocol for establishing an SSL connection includes negotiating
the most secure encryption algorithm both client and server support. The
most commonly used encryption algorithms are:
RSA (Rivest, Shamir, and Adelman, the names of its designers) for
key exchange
DES (Data Encryption Standard) and its variants RC2 (a block cipher)
and RC4 (a faster stream cipher) for bulk encryption
MD5 and SHA for message digests
A cipher suite is made up of three algorithms -- one each for
key exchange, bulk encryption, and message digest. For example, the cipher
suite RSA_WITH_RC4_128_MD5 uses
RSA for key exchange, RC4 with a 128-bit key for bulk encryption, and MD5
for message digest.
BEA provides two versions of WebLogic Server. The generally-available
version supports 512-bit certificates and 40-bit bulk data encryption. You
can obtain a version that supports 768-bit and 1024-bit certificates and
128-bit bulk data encryption by contacting your BEA sales representative.
How is SSL transported?
The SSL protocol is customarily "tunneled" over an IP-based protocol.
"Tunneling" means simply that each SSL record is encapsulated and packaged
up with the proper headers to send over another protocol. SSL
communications between web browsers and WebLogic Server are encapsulated
in HTTPS packets for transport, the "S" signaling that SSL is in use. Java
clients connecting to WebLogic Server with SSL tunnel over BEA's
multiplexed T3 protocol.
The use of SSL is signified in the protocol scheme of the URL, for
example:
Tunneling adds overhead to any sort of communications. Using a
communication protocol that must be unencrypted or authenticated will add
noticeably to a client's perceived wait time.
WebLogic supports HTTPS with browsers that support SSL3. The JVM (Java
Virtual Machine) doesn't currently support the HTTPS protocol adapter and
consequently WebLogic depends on the implementation of SSL in the browser.
Non-browser clients can form an SSL connection to WebLogic Server by
using WebLogic's T3S protocol, which has SSL support. Java programs
running in WebLogic Server can establish T3S connections to other WebLogic
Servers or HTTPS connections to other servers that support SSL, such as
web servers or secure proxy servers.
II. Setting up WebLogic SSL
To use SSL with WebLogic, you need a private key and a digitally-signed
certificate containing the matching public key. If the certificate
authority who signed your certificate is not well-known, you may also need
to install their root certificate in your WebLogic Server. Here are the
steps:
Acquire
a certificate for your server. You can use the Certificate servlet
to generate a public key, private key, and a certificate request, which
contains your public key. To obtain a certificate, you send the
certificate request to a certificate authority (CA) and follow their
procedures for obtaining a signed certificate.
Note:
Certificates from Microsoft Internet Information Server and
Netscape Enterprise Server cannot be used with WebLogic Server
because they are stored in a proprietary
format.
Install
the certificate you received from the CA in the per-server directory
of your WebLogic Server. You can use certificates in either .der or .pem format.
Set
properties in the weblogic.properties file to enable SSL and specify your
certificate and private key files. You can also set
certificate
chain properties to allow clients to authenticate the certificate
authority who issued your certificate.
For
two-way authentication, set properties in the weblogic.properties file so that the
WebLogic Server requests certificates from clients. Install the root
certificates for CAs whose certificates your WebLogic Server will
accept.
See the Administrators Guide
Setting
WebLogic Properties for more properties you can set to configure
WebLogic SSL.
An SSL client typically keeps a list of trusted certificate authorities
and alerts the user when a server presents a certificate that is not
issued by a recognized authority. Extending the list of trusted
certificate authorities is part of security configuration.
Newer browsers (beginning with Netscape version 2.x and Internet
Explorer 4.0) can extend this list dynamically using a sequence of dialogs
presented to the user when a questionable certificate is encountered.
Earlier browsers have a hard-coded list of valid certificate authorities.
If one of these browsers encounters a certificate from an unknown CA, it
will not complete a secure connection. For these earlier browsers
(Netscape 1.x, Internet Explorer 2.x and 3.x), you must request a
certificate from a recognized certificate authority like VeriSign or
Entrust.net.
For a demonstration of using SSL with WebLogic, you can use the .pem files in the weblogic/myserver directory. The ca.pem file is a demonstration CA root
certificate. For this certificate, WebLogic is the certificate authority.
The democert.pem file is a
certificate signed with the public key in ca.pem. The demokey.pem file is the private key that matches the public
key in democert.pem.
To install these files, copy them to your per-server directory (if it
is other than /weblogic/myserver,
and add these properties to your weblogic.properties file:
These properties are already enabled in the distributed weblogic.properties file.
The demonstration certificate files help to understand how SSL
certificates work, but are not useful for secure communications, since
WebLogic is not a well-known or trusted certificate authority.
Acquiring a certificate for your WebLogic Server
To acquire a certificate from a certificate authority, you submit your
request in a particular format called a "Certificate Signature Request"
(CSR). The WebLogic distribution includes a server certificate signature
request generator. This is a servlet that collects information from you
and generates a private key file and a certificate request file. The
servlet generates requests that you can submit to VeriSign or Entrust.net.
WebLogic Server is available with exportable- or
domestic-strength SSL.
Exportable SSL supports 512-bit certificates and 40-bit bulk data
encryption.
Domestic SSL also supports 768-bit and 1024-bit certificates, and
56-bit and 128-bit bulk data encryption.
The standard WebLogic Server distribution supports exportable-strength
SSL only. The domestic version is available only by request to your BEA
sales representative. Since the United States Government relaxed
restrictions on exporting encryption software in early 2000, the domestic
version of WebLogic Server can be used in most countries.
The domestic WebLogic Server distribution is recommended because it
allows stronger encryption. If you generate your CSR using the exportable
WebLogic Server distribution, you cannot support high-strength connections
and you cannot authenticate clients that present domestic-strength
certificates.
Prerequisites
Check the following prerequisites before you continue:
WebLogic Server must be installed, running, and configured to
support SSL.
If you want to support domestic-strength browsers and strong
encryption, make sure you have the domestic version of WebLogic Server
before you generate a CSR.
You can verify that SSL is operational and that you have domestic
strength SSL by searching the WebLogic Server log for a message like
this one:
<SSLListenThread> Using domestic strength SSL.
You must know the password for your WebLogic Server "system".
If you do not know this password, you will need the help of your
WebLogic Server system administrator.
To purchase a web server certificate for WebLogic Server, you choose a
Certificate Authority and follow the enrollment instructions on their web
site. During the enrollment process, you are instructed to Generate a CSR.
At that point, you use the WebLogic Server Certificate Request Generator
servlet to generate a CSR. Then you continue with the the Certificate
Authority's enrollment procedure, submitting the CSR according to their
instructions.
Follow these steps:
Select a Certificate Authority and follow the instructions on their
web site to purchase a certificate.
VeriSign, Inc. offers two
options for WebLogic Server: Global Site Services, which features
strong 128-bit encryption for domestic and export web browsers, and
Secure Site Services, which offers 128-bit encryption for domestic web
browsers and 40-bit encryption for export web browsers.
Entrust.net certificates
offer 128-bit encryption for domestic browser versions and 40-bit
encryption for export browser versions.
When you are instructed to select a server type, choose "BEA
WebLogic Server" to ensure that you receive a certificate that is
compatible with WebLogic Server.
When you reach the step in the Certificate Authority's enrollment
procedure where you are instructed to Generate a CSR, continue with the
next step in this process.
In a web browser, enter the URL for the WebLogic Server Certificate
Request Generator servlet. The URL is in this format:
http://hostname:port/Certificate
hostname is the DNS name of the computer running WebLogic
Server.
port is the port number where WebLogic Server listens for
connections. The default is 7001.
For example, if WebLogic Server is running on the computer named
"ogre" and it is configured to listen at the default port 7001, enter
this URL in your browser:
http://ogre:7001/Certificate
The browser prompts for a WebLogic Server login and password. Log in
as system.
The Certificate Request Generator servlet loads a form in your
browser.
Complete the Certificate Request Generator form as follows:
Country
code
The
two-letter ISO code for your country. The code for the United
States is "US". You can find a complete list
here.
Organizational unit
name
The name
of your division, department, or other operational unit of your
organization.
Organization
name
The name
of your organization. The certificate authority may require that
the host name you enter in this field is in a domain registered to
this organization.
E-mail
address
Enter the
e-mail address of the host administrator.
Full host
name
Enter the
fully-qualified name of the server where the certificate will be
installed. This is the name used for DNS lookups of the server,
such as www.mydomain.com. Browsers compare the site name
in the URL to the name in the certificate. If you change the site
name later, you must request a new certificate.
Locality
name (city)
Enter the
name of your city, town, or other locality. If you operate with a
license granted by a city, this is a required field and you must
enter the name of the city that granted your license, and you must
enter your State or Province in the State name field.
State
name
If you are
in the United States or Canada, enter the name of the State or
Province in which your organization operates. Do not
abbreviate.
Random
string
Enter a
string of characters to be used by the encryption algorithm. You