MY FAVORITE SINGER LISTEN TO HER ONLINE

WELCOME TO THE ECTG CORP SITE

 

guitar.gif

piano.gif

sax.gif

violin.gif

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.

banjo.jpg

home.gif

Using Web Logic SSL

I. Introduction
Authentication
Encryption
How is SSL transported?

II. Setting up WebLogic SSL
Acquiring a certificate for your WebLogic Server
Installing certificates on a WebLogic Server

III. Using SSL in the WebLogic environment
Making client SSL connections to WebLogic Server
Setting up two-way authentication
Setting up WebLogic to require two-way authentication
Requesting and accepting certificates from clients
Mapping a client certificate to a WebLogic Server user
Getting a certificate for a browser
Setting up a Java client
Ping example
JNDI client SSL example
HTTPS example
Opening a secure connection to another server
Using SSL in servlets

IV. Questions and Answers about SSL

V. Change history

Other related documents
Installing WebLogic (Windows)
Using WebLogic ACLs (Access Control Lists)
The Developers Guides
SSL 3.0 Specification
Crypto Standards & Protocols
Frequently asked questions about Cryptography

I. Introduction

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:


https://myserver.com/mypage.html
  t3s://myserver.com:7002/mypage.html

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. See the Administrators Guide Setting WebLogic Properties for more properties you can set to configure WebLogic SSL.

  6. Begin using SSL in the WebLogic environment.

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:

  weblogic.system.SSLListenPort=7001
  weblogic.security.ssl.enable=true
  weblogic.security.key.server=demokey.pem
  weblogic.security.certificate.server=democert.pem
  weblogic.security.certificate.authority=ca.pem

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.

Obtaining a Web Server Certificate

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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

  5. 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.

  6. 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

    1

    Hosted by www.Geocities.ws