Apache

Apache

Introduction::

Apache web server is a web server application.
Web server application helps to deliver web content to be accessed through the internet.
It is commonly referred to as Apache.
Apache Web server played a key role in the initial growth of the WWW(World Wide Web)
It is originally based on NCSA HTTPd server.

Development of Apache began in early 1995 after work on NCSA code stalled.
Apache overtook NCSA HTTPd as the dominant HTTP server
Apache remained the most popular HTTP server in use since April 1996

In 2009, it became the first web server software to serve more than 100 million websites.

Apache is developed and maintained by an open community of developers.
The development takes place under the auspices of Apache software Foundation.
It is most commonly used on a Unix-like system.

The software available for Unix,Linux,Microsoft windows,Solaris,OpenVMS and etc ......

Apache released under Apache License 2.0

As of June 2013, Apache has served 54.2% of all websites and 53.3% of top servers across the world.

The original author of Apache Web server is Robert McCool.
Apache Web server written in C language.

Official website: httpd.apache.org

Apache HTTP Server Plug-In Overview

The Apache HTTP Server Plug-In allows requests to be proxied from an Apache HTTP Server to WebLogic Server. The plug-in enhances an Apache installation by allowing WebLogic Server to handle requests that require the dynamic functionality of WebLogic Server.

The plug-in is intended for use in an environment where an Apache Server serves static pages, and another part of the document tree (dynamic pages best generated by HTTP Servlets or JavaServer Pages) is delegated to WebLogic Server, which may be operating in a different process, possibly on a different host. To the end user—the browser—the HTTP requests delegated to WebLogic Server still appear to be coming from the same source.

HTTP-tunneling, a technique which allows HTTP requests and responses access through a company’s firewall, can also operate through the plug-in, providing non-browser clients access to WebLogic Server services.

The Apache HTTP Server Plug-In operates as an Apache module within an Apache HTTP Server. An Apache module is loaded by Apache Server at startup, and then certain HTTP requests are delegated to it. Apache modules are similar to HTTP servlets, except that an Apache module is written in code native to the platform.

Note: Apache 2.0 Plug-In has been deprecated in WebLogic Server 10.0 release.

Installing the Apache HTTP Server Plug-In

You can install the Apache HTTP Server Plug-In as an Apache module in your Apache HTTP Server installation and link it as a Dynamic Shared Object (DSO).

A DSO is compiled as a library that is dynamically loaded by the server at run time, and can be installed without recompiling Apache.


Installing the Apache HTTP Server Plug-In as a Dynamic Shared Object

The Apache plug-in is distributed as a shared object (.so) for Solaris, Linux, Windows, and HPUX11 platforms. BEA WebLogic supplies versions of shared object files that vary according to platform, whether or not SSL is to be used between the client and Apache, and the SSL encryption strength (regular or 128 bit—128 bit versions are only installed if you install the 128 bit version of WebLogic Server).


Locations of Plug-In Shared Object Files

Solaris -----------             WL_HOME/wlserver_10.0/server/plugin/solaris/sparc
Linux -------------            WL_HOME/wlserver_10.0/server/plugin/linux/i686
WL_HOME/wlserver_10.0/server/plugin/linux/ia64
WL_HOME/wlserver_10.0/server/plugin/linux/s390
Windows -----------         WL_HOME\wlserver_10.0\server\plugin\win\32 or
WL_HOME\wlserver_10.0\server\plugin\win\64
HPUX11 ------------        WL_HOME/wlserver_10.0/server/plugin/hpux11/IPF64
WL_HOME/wlserver_10.0/server/plugin/hpux11/PA_RISC

WARNING: If you are running Apache 2.0.x server on HP-UX11, set the environment variables specified immediately below before you build the Apache server. Because of a problem with the order in which linked libraries are loaded on HP-UX, a core dump can result if the load order is not preset as an environment variable before building. Set the following environment variables before proceeding with the Apache configure, make, and make install steps, (described in Apache HTTP Server documentation at http://httpd.apache.org/docs-2.1/install.html#configure):

export EXTRA_LDFLAGS="-lstd -lstream -lCsup -lm -lcl -ldld -lpthread"

Apache Plug-In Shared Object File Versions

Apache Version Regular Strength Encryption 128-bit Encryption
Standard Apache Version 2.0.x mod_wl_20.so mod_wl28_20.so
Standard Apache Version 2.2.x mod_wl_22.so mod_wl28_22.so

To install the Apache HTTP Server Plug-In as a dynamic shared object:

 1. Locate the shared object directory for your platform.
 2. Identify the plug-in shared object file for your version of Apache.
 3. Verify that the WebLogic Server Apache HTTP Server Plug-In mod_so.c module is enabled.

The Apache HTTP Server Plug-In will be installed in your Apache HTTP Server installation as a Dynamic Shared Object (DSO). DSO support in Apache is based on a module mod_so.c, which must be enabled before mod_wl_20.so is loaded. If you installed Apache HTTP Server using the script supplied by Apache, mod_so.c is already enabled. Verify that mod_so.c is enabled by executing the following command:

APACHE_HOME\bin\apache -l
(Where APACHE_HOME is the directory containing your Apache HTTP Server installation.)

This command lists all enabled modules. If mod_so.c is not listed, you must rebuild your Apache HTTP Server, making sure that the following options are configured:

...
--enable-module=so
--enable-rule=SHARED_CORE
...
See Apache 2.0 Shared Object (DSO) Support at
http://httpd.apache.org/docs/2.0/dso.html.

 4. Install the Apache HTTP Server Plug-In module for Apache 2.0.x by copying the mod_wl_20.so file to the APACHE_HOME\modules directory and adding the following line to your APACHE_HOME/conf/httpd.conf file manually:
LoadModule weblogic_module     modules/mod_wl_20.so

 5. Define any additional parameters for the Apache HTTP Server Plug-In.
The Apache HTTP Server Plug-In recognizes the parameters listed in General Parameters for Web Server Plug-In.To modify the behavior of your Apache HTTP Server Plug-In, define these parameters:

. In a Location block, for parameters that apply to proxying by path, or
. In an IfModule block, for parameters that apply to proxying by MIME type.

 6. Verify the syntax of the APACHE_HOME\conf\httpd.conf file with the following command:

APACHE_HOME\bin\apachectl -t

The output of this command reports any errors in your httpd.conf file or returns:

Syntax OK
 7. Restart WebLogic Server

 8. Start (or restart if you have changed the configuration) Apache HTTP Server.

 9. Test the plug-in by opening a browser and setting the URL to the Apache Server + “/weblogic/”, which should bring up the default WebLogic Server HTML page, welcome file, or default servlet, as defined for the default Web Application on WebLogic Server. For example:
http://myApacheserver.com/weblogic/

Configuring the Apache HTTP Server Plug-In

After installing the plug-in in the Apache HTTP Server, configure the WebLogic Server Apache Plug-In and configure the server to use the plug-in. This section explains how to edit the Apache httpd.conf file to instruct the Apache server to load the WebLogic Server library for the plug-in as an Apache module, and to specify the application requests that should be handled by the module.

Editing the httpd.conf File

Edit the httpd.conf file in your Apache HTTP server installation to configure the Apache HTTP Server Plug-In.

This section explains how to locate and edit the httpd.conf file, to configure the server to use the WebLogic Server Apache Plug-In, to proxy requests by path or by MIME type, to enable HTTP tunneling, and to use other WebLogic Server plug-in parameters.

1. Open the httpd.conf file.

The file is located at APACHE_HOME\conf\httpd.conf (where APACHE_HOME is the root directory of your Apache HTTP server installation).

2. Ensure that the WebLogic Server modules are included for Apache 2.0.x, manually add the following line to the httpd.conf file:

LoadModule weblogic_module   modules\mod_wl_20.so

3. Add an IfModule block that defines one of the following:

For a non-clustered WebLogic Server:

The WebLogicHost and WebLogicPort parameters.

For a cluster of WebLogic Servers:

The WebLogicCluster parameter.

For example:

<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7001
</IfModule>

4. To proxy requests by MIME type, add a MatchExpression line to the IfModule block. Note that if both MIME type and proxying by path are enabled, proxying by path takes precedence over proxying by MIME type.

For example, the following IfModule block for a non-clustered WebLogic Server specifies that all files with MIME type .jsp are proxied:

<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7001
MatchExpression *.jsp
</IfModule>

You can also use multiple MatchExpressions, for example:

<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7001
MatchExpression *.jsp
MatchExpression *.xyz
</IfModule>

If you are proxying requests by MIME type to a cluster of WebLogic Servers, use the WebLogicCluster parameter instead of the WebLogicHost and WebLogicPort parameters. For example:

<IfModule mod_weblogic.c>
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
MatchExpression *.jsp
MatchExpression *.xyz
</IfModule>

5. To proxy requests by path, use the Location block and the SetHandler statement. SetHandler specifies the handler for the Apache HTTP Server Plug-In module. For example the following Location block proxies all requests containing /weblogic in the URL:
<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
</Location>

6. Optionally, enable HTTP tunneling for t3 or IIOP.

A. To enable HTTP tunneling if you are using the t3 protocol and weblogic.jar, add the following Location block to the httpd.conf file:

<Location /HTTPClnt>
SetHandler weblogic-handler
</Location>
B. To enable HTTP tunneling if you are using the IIOP, the only protocol used by the WebLogic Server thin client, wlclient.jar, add the following Location block to the httpd.conf file:

<Location /iiop>
SetHandler weblogic-handler
</Location>

7. Define any additional parameters for the Apache HTTP Server Plug-In.

The Apache HTTP Server Plug-In recognizes the parameters listed in General Parameters for Web Server Plug-Ins. To modify the behavior of your Apache HTTP Server Plug-In, define these parameters either:

. In a Location block, for parameters that apply to proxying by path, or
. In an IfModule block, for parameters that apply to proxying by MIME type.


Including a weblogic.conf File in the httpd.conf File

If you want to keep several separate configuration files, you can define parameters in a separate configuration file called weblogic.conf file, by using the Apache Include directive in an IfModule block in the httpd.conf file:

<IfModule mod_weblogic.c>
# Config file for WebLogic Server that defines the parameters
Include conf/weblogic.conf
</IfModule>

The syntax of weblogic.conf files is the same as that for the httpd.conf file.

This section describes how to create weblogic.conf files, and includes sample weblogic.conf files.


Creating weblogic.conf Files

Be aware of the following when constructing a weblogic.conf file.

. If you are using SSL between the Apache HTTP Server Plug-In and WebLogic Server, you cannot define parameters in a file accessed, as the weblogic.conf file is, via the Apache Include directive.
. Enter each parameter on a new line. Do not put ‘=’ between a parameter and its value. For example:

PARAM_1 value1
PARAM_2 value2
PARAM_3 value3
. If a request matches both a MIME type specified in a MatchExpression in an IfModule block and a path specified in a Location block, the behavior specified by the Location block takes precedence.

. If you define the CookieName parameter , you must define it in an IfModule block.

. If you use an Apache HTTP Server <VirtualHost> block, you must include all configuration parameters (MatchExpression, for example) for the virtual host within the <VirtualHost> block .

. If you want to have only one log file for all the virtual hosts configured in your environment, you can achieve it using global properties. Instead of specifying the same Debug, WLLogFile and WLTempDir properties in each virtual host you can specify them just once in the <IfModule> tag.

. Sample httd.conf file:

<IfModule mod_weblogic.c>
WebLogicCluster johndoe02:8005,johndoe:8006
Debug ON
WLLogFile             c:/tmp/global_proxy.log
WLTempDir             "c:/myTemp"
DebugConfigInfo       On
KeepAliveEnabled ON
KeepAliveSecs  15
</IfModule>

<Location /jurl>
SetHandler weblogic-handler
WebLogicCluster agarwalp01:7001
</Location>

<Location /web>
SetHandler weblogic-handler
PathTrim /web
Debug OFF
WLLogFile c:/tmp/web_log.log
</Location>

<Location /foo>
SetHandler weblogic-handler
PathTrim /foo
Debug ERR
WLLogFile c:/tmp/foo_proxy.log
</Location>
. All the requests which match /jurl/* will have Debug Level set to ALL and log messages will be logged to c:/tmp/global_proxy.log file. All the requests which match /web/* will have Debug Level set to OFF and no log messages will be logged. All the requests which match /foo/* will have Debug Level set to ERR and log messages will be logged to c:/tmp/foo_proxy.log file

. BEA recommends that you use the MatchExpression statement instead of the <files> block.

Sample weblogic.conf Configuration Files

The following examples of weblogic.conf files may be used as templates that you can modify to suit your environment and server. Lines beginning with # are comments.

Example Using WebLogic Clusters

# These parameters are common for all URLs which are
# directed to the current module. If you want to override
# these parameters for each URL, you can set them again in
# the <Location> or <Files> blocks. (Except WebLogicHost,
# WebLogicPort, WebLogicCluster, and CookieName.)

<IfModule mod_weblogic.c>
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
ErrorPage http://myerrorpage.mydomain.com
MatchExpression *.jsp
</IfModule>
##############################################################################################################################################################

SSL(Security Socket Layer)

SSL:

we are going to set-up SSL on Apache Web Server with the WebLogic plug-in that load balances to a WebLogic Dynamic Cluster (with a few managed servers that have SSL enabled), by using a custom identity and custom trust (as we are going to use self signed certificates).

WebLogic supports secure communications with clients and other servers using either Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connections. Note that TLS is essentially the next generation SSL. SSL supports two different connection modes or types. The two types are commonly called one-way and two-way SSL. One-way SSL allows the SSL client to verify that the SSL server is, in fact, who it claims to be. Two-way SSL extends one-way SSL by allowing the SSL server to verify that the client is who it claims to be.

These verifications are accomplished through the use of public/private key technology. This technology uses a set of two related keys known as a public key and a private key for encryption and signing purposes. Anything encrypted using the public key can only be decrypted using the private key, and vice versa. As the names suggest, the owner of the private key keeps this key locked away where only the owner has access to it and gives its public key to everyone who might need it. Private key files are additionally encrypted with a pass phrase that must be supplied to get the actual private key as an additional safety check against unauthorized use. The standard way of distributing public keys is to use X.509 certificates that contain information about the certificate's owner and the public key.

X.509 certificates are issued by certificate authorities that digitally sign the certificates with their private key to allow verification through the use of their public key. In some cases, the signing authority's certificate might have been signed by another authority and so on. This brings about the notion of a certificate chain where the top of the chain is known as the root certificate authority (CA) whose certificate is always self-signed. When we get the CA's certificate, that certificate will generally contain the entire certificate chain back to the root CA. This root CA or certificate chain is used by the receiver of the original certificate to determine whether it trusts that the certificate is legitimate.

With one-way SSL, the SSL client uses the server's certificate (actually, the public key contained in the certificate) to encrypt a symmetric session key that is sent to the server. The server decrypts the session key with its private key. Both the client and the server use that key to encrypt and decrypt data for the duration of the session. This is why it is critical for the server to keep its private key safe and its pass phrase a secret.


With two-way SSL, the server will request a certificate from the client that it then uses to identify and authenticate the client. In order for the client to trust the certificate provided by the server, it must verify the signing chain of the server's certificate. If the client trusts the server's certificate authority, it can verify the server's certificate and prove that it is real and has not been tampered with. This verification requires the client to have the CA's certificate for the server available locally, as a notion of which certificates the client will trust. The server must use the exact same mechanisms to verify the client's certificate. The server requires the client's root CA's certificate locally for two-way SSL. Notice the concepts of identity and trust for both the SSL server and the SSL client. The identity is the certificate and private key. The trust is the certificate authority.

Configure SSL in WebLogic:

1. Generating the certificate:

Step 1: Open command prompt and set the environment by running the setDomainEnv script.
(C:\bea10.3\user_projects\domains\practice_domain\bin\setDomainEnv.cmd)
Step 2: Generate the private and public key pair for demonstration we would use keytool java utility to do so. how ever we can use other utilities like openssl etc.
keytool -genkey -alias mykey -keyalg RSA -keysize2048 -keystore identity.jks
Step 3: Generate a certificate signing request (CSR) and send it to Certificate Authority.
keytool -selfcert -alias mykey -keystore identity.jks
Step 4: Create a identity keystore, this can be done my exporting
keytool -export -alias mykey -file cert.cer -keystore identity.jks
Step 5: Create a trust keystore this can be done my importing.
keytool -import -alias mykey -file cert.cer -keystore trust.jks -noprompt
To verify the contents of the keystore, you can use the below command....
keytool -list -v -keystore <keystore-name> -storepass<keystore- password>

2. Configuring the keystore on the WebLogic Server:

Step 1: Log into the Admin Console, Click on servers
Step 2: Click on lock and edit
step 3: Select the server on which you want to configure the SSL certificate.(Ex:managedserver1)
step 4: Click on key restores
Step 5: Select Custom identity and Custom trust

Identity :
CustomIdentitykeystore: C:\bea10\user_projects\domains\Trainig_domain\identity.jks
Custom Identity keystore type: jks
Custom identity passphrase: Sv12345
Trust:
Custom trust keystore: C:\bea10\user_projects\domains\Trainig_domain\trust.jks
Custom trust keystore type: jks
Custom trust passphrase: Sv12345
àsave     ---àAcivate changes

Step 6: Click on SSL
Step 7: Enter identity
Private key alias:mykey
Private passpharse: sv12345
---save     ---Activate changes

To check SSL type browser https://localhost:5003
(managedserver1 ssl portnumber)
/mess
(deploying application)

1-way SSL Diagram:

2-way SSL Diagram: