WAS : express, base, ND

Express is like tomcat, only WAR no EJB module. Furthermore single instance for dev-prod to simplify the deployment.

Base, able to handle EJB module. Not support cluster and only support server1 Appserver.
Server1 cant be started or stopped using ISC.

ND, support cluter and multi app servers.

Note :
About ISC :
there is a isclite.ear module in config/cells/node/applications/ if ISC is installed.
In base, you may not install ISC, nor defaultapp (snoop/hello), nor sampleApp(plant)
But you are auto installing the ivtApp.ear and query.ear.
IvtApp.ear is used during the firstStep to verifiy instalation result, like start hem and test the ports.

About trial period:
can be tricked by changing the date of the OS.

Security 3 : websphere, plugin, IHS key database

IHS --> SSLengine ON
Certificate location
keyfile location
chainfile location

Plugin : CMS type=> .kdb
ikeyman tools => generate self-signed cert
extract it to a .arm file
transfer it to a WAS servers to be put it in key (or trust file)
more precisely is "ADD" in signer certificate (not personal certificate)

WAS : jks = javakeystore => a db file of certicates collection (new generated by ikeyman tool)
a. one.jks => private key and trusted certs are here
b. key.jks and trust.jks => private key in key.jks while trusted certs in trust.jks

ikeyman tools ==> generate self-signed cert in personal certs
extract it to a .arm file
transfer it to a Plugin servers to be put it in key.kdb
==> signer certificates => ADD
I wonder why, we need "add" to signer certs as well in WAS side.

If you use LDAPS in WAS, then you "add" also the ldap server certs in that jks file.

Note : 1. dont forget to set the path in ISC to the correct location of jks file
2. ikeyman tools is GUI, gsk7cmd is CLI,
3. keytool can be used as well to read the jks wihtout password
4. during the creation of jks, it prompts password, this password is encrypted in a stash file.
5. .arm = .cer
6. keyring = keystore
7. signer certificate = trust certs = ssl from client side
8. key = private key = ssl from server side

reference : http://publib.boulder.ibm.com/infocenter/wasinfo/v4r0/index.jsp?topic=/com.ibm.websphere.v4.doc/wass_content/06061801a07.html

Security 2 : certificates, CA, SSL

How browser and SSL web server connected:

1. browsers usually have the "trust root CA" already which means have those public key
2. first it will work in asymmetric method
3. Certificate of web server containing CN/domain name, digital signature CA (result of encrypting priv key CA : maybe with HASH), HASH (or fingerprint), public key of the web server.
4. Pub key in browser will decrypt the dig signature CA
5. It will get the HASH and compare with the HASH in the certificate
This verify if the CA is really the CA, example: this Cert really come form verisign.
6. After browser verify it, it use the public key web server in the certs to encrypt the req along with sessionID
7. Web server got it and decrypt using it priv key.
8. At this point, web server will do the symmetric key encryption using the sessionID as the shared code.

Note : Dont be confused, there are CA key pair and also web server key pair.
Asymmetric encrypt is slower than symmetric.

>>>>>>>>>>>>>>>>>>>>>>>>>>>

In unix use openssl command
First you generate the priv key RSA.
then from that you create a .csr file. CSR : certificate request
which need some input as domain name, etc.....
then you send the .csr to a CA
if it is commercial CZ, they may contact you for verify and to be paid
then CA will send you the .cert files/.arm files
set the cert localtion on the virtual host section of your http
also set the key file location in the same section
also set the SSLCertificateChainFile in the same section.
==> this last file is a plain text file containing the structure intermediate CA up to root CA
==> explain later on in next


>>>>>>>>>>>>>>>>>>>>>>>>>>

CA :
A. private CA
B. commercial CA

1. root CA : the root, issued to and issued by itself, and signed by it self.
2. intermediate CA : the derivatives up to several level, issued by : rootCA/above intermediate CA
issued to : itself. signed by the ROOT CA or above intermCA.

In secure case : root CA is std alone, intermediate CA is in network. You create csr in intermCA, bring it over usb to root CA. you generate the cert, and bring over usb again to intermCA, and install it. Now you have rootCA signed cert at your intermCA.
Now you can create any new certs to be used by web servers.
Remember in web servers, you need set the chain file (in order client browser can auth the intermCA upto the rootCA).

reference: http://usefulfor.com/nothing/2008/03/20/howto-create-an-intermediate-certifica-authority-ca-using-openssl/

chain file looks like:

--BEGIN--
FDARGARGAGAGFDGFDGDCCCC
the intermCA2
DSFSDGDSFHSHSHSD%^GG#TG
--END--
--BEGIN--
the intermCA1
--END--
--BEGIN--
the rootCA
--END--


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

summary : certificate is public key with some info of your data
can be digitally signed by a CA or commercial CA
digitally sign means as written in digital signature workflow

Security 1 : Asymmetric, symmetric, hash, digital signature, email encryption

Symmetric : shared code
Asymmetric: pair key - public & private

Hash : SHA or MD5 ==> algorithm to make a data into short form, use to verify if data altered or not along the way. Example : email + hash = 010101100 (this is called fingerprint)

Digital signature ==> fingerprint + private key encryption

you sent : email + digital signature (for now we ignore the email encryption)

recipient has your pub key!
recipient also has the hash!
==> first it will hash the email and it will get the fingerprint 010101100
==> second it will decrypt the dig signature with the pub key and it will get the fingerprint
==> A. comparing the fingerprint step 1 and 2 above, if not equal then email was altered!!
B. also if the pub key failed to decrypt at step 2, then it means the private key wrong, which could means it was not sent by the real person (bcoz private key is only had by the real)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Now, about email encryption:
the encryption is done by the pub key, and is called RSA method.

Sender has the pub key of recipient and encrypt the email with it.
Recipient will use his priv key to decrypt it.

Note : Even if someone else has recipient pub key, it does not mean he can reverse back the data. Only one who has private key can decrypt it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

MQ v7 example to make connection

Structure:
Qremote -- transmissionQ(XmitQ) -- channel -- RemoteServer:listener -- RemoteServer:Qlocal

Qremote:
===> Just a shadow of remoteQL
runmqsc
def qr(nameQR ex. QRMTYY) rname( nameQL on remote server : QL.AY) rqmname( nameQM remote : QMCYY) +
xmitq(QMCYY)

Note : xmitq is optional, if u use default,by default it will go to xmitq whose name same as rqmname. That is why if no xmitq with same name with rqmname: 'amqsput QremoteName' will show error.
If you use uncommon name for the xmitQ (different name with the rqmname), you must put parameter xmitq there.


XmitQ
==> Queue Gateway of all Qremote using this value XmitQ as parameter
runmqsc
def ql(QMCYY) usage (xmitq)


Channel
==> Defining to where, hostname and port of remote server.
runmqsc
def chl(qmcxx.qmcyy) chltype(sdr) trptype(tcp) conname ('ip(port)') xmitq(qmcYY)

Note : this channel will be used by this xmitQ

>>>>>>>>>>>>>>>>>>>>>
BTW, you need to set deadletterQ as well:
runmqsc
def ql(DQL)
alter qmgr deadq(dlq)
>>>>>>>>>>>>>>>>>>>>>>


AT REMOTE SERVER:

listener
runmqlsr -t TCP -p 90XX -m qmgrname

Note : after this you create channel receiver : def chl(xxx) chltype(rcvr) trptype(tcp)
dont forget to create qlocal (QL.AY)


BACK TO LOCAL SERVER


TESTING:
runmqsc
ping chl (qmcxx.qmcyy) ==> this one only test if remote listener port open
runmqchl -c qmcxx.qmcyy -m qmgrname ==> activate channel (has dependancy on listener port AND correct name of xmitQ existence)


PUTTING MESSAGE:
amqsput Qremote (qmgrname)
==> remember this is just shadow, message will go to xmitQ name related
-=> So check it with amqsbcg/gbr xmitQname (to see if message stuck in local server)
amqsgbr is more concise than amqsbcg.


CHECKING MESSAGE @remote server:
amqsgbr QL.AY (qmgrname)
amqsbcg QL.AY (qmgrname)

NOW, if you wanna set message goes to DeadletterQ (when everything is ok):
amqsput XmitQname
==> because channel doesnt know where to transfer it (unlike QR which has Qlocal of remote server)
==> And of course the DeadletterQ is in the local server.

NOW, if channel failed, and you use that : amqsput XmitQname,
it will go to XmitQ, test by : amqsgbr xmitQname.


ADDITOINALLY:
crtmqm -q qmgrname (make it as default qmgr)

MQ v7 Triggering amqsreq.exe and amqsech.exe

Those files should be in:
D:\Program Files\IBM\WebSphere MQ\tools\c\samples\bin

That "c" dir is created only if you install the "development toolkit" during the instalation,
or you can run it again the setup.exe of MQ, to add this feature.

NOTE: IF U SEARCH FOR AMQSBCG.EXE, IT IS ALSO THERE AFTER THIS FEATURE INSTALLED

After this, it will be put in PATH variable, so you must close the "cmd" windows and open new one "cmd" in order to get the refreshed "PATH" variable.

"cmd" == start - run - cmd

WAS + proxy (edge server)

Excerpt from http://www-10.lotus.com/ldd/lcwiki.nsf/dx/configuring-a-reverse-proxy-server2


Configuring a reverse proxy server (2.0)

Overview
A reverse proxy server intercepts client requests to Lotus Connections servers and, when possible, returns cached data rather than contacting the true destination server. A reverse proxy reduces the amount of traffic that a back-end server must perform to satisfy duplicate requests for data, while at the same time improving the response time for those requests.
You can set up a reverse proxy by using WebSphere Application Server Edge components (formerly Edge Server). Edge components can control client access to Web servers and improve access to Web-based content over the Internet or a corporate intranet.

Infrastructure
The topology in this deployment uses a cluster of Lotus Connections servers connected to a remote HTTP server, a remote database server, and a remote LDAP server. These are deployed in a private network behind a firewall. Client request are intercepted and handled by the transparent proxy server. Users are not aware that a proxy exists in the configuration.

This deployment was tested on a Microsoft Windows Server 2003 platform. The following figure illustrates the topology used in this deployment:

Specifications
The following table lists the specifications of the systems used in this deployment:
Component Software OS System
Reverse Proxy IBM WebSphere Application Server Edge Components 6.1 Windows Pentium IV CPU, 3.0 GHz, 500 MB RAM
Web Server IBM HTTP Server 6.1.13 with SSL enabled Windows
Linux 2 Dual-Core CPUs, 2.0 GHz, 8 GB RAM
1 Quad-Core CPU, 1.6 GHz, 4 GB RAM
Lotus Connections 1.0.2
Lotus Connections 2.0
IBM WebSphere Application Server 6.1.0.13
IBM WebSphere Application Server 6.1.0.13 Windows
Linux 2 Dual-Core CPUs, 2.0 GHz, 8 GB RAM
Database DB2 9.1.4
Oracle 10g 10.2.0.3 Windows
Linux 2 Dual-Core CPUs, 2.0 GHz, 8 GB RAM

















Step-by-Step instructions
Before deploying this infrastructure, the product and all related components must be installed.

Installing WebSphere Edge Components

1. Download Edge Components (part number: C88UQML): https://w3-104.ibm.com/software/xl/download/ticket.do?openform
2. Launch the Edge Components launchpad.bat file and install the Caching Proxy component. For more information about installing, see the Edge components information center.
3. Start the proxy service: Click Start > Control Panel > Administrative Tools > Services, and then select IBM Caching Proxy and start the service.
4. Enter the URL of the target Web server: Click Start > All Programs > Edge Components > Caching Proxy > Configuration Wizard. Enter the URL of the Target Web Server, and click Next.
5. Enter a User Name and Password for a new administrator account, and click Next. Click Finish and OK.
6. Open the ibmproxy.conf file (usually located in the \cp\etc\en_US directory) and add the following line to the Start new mapping rules section:

Add Pass /pub/* \cp\server_root\pub\en_US\*


Save the file.
7. Configure the proxy: Open Proxy Configuration > Proxy Settings, select the HTTP check box, and click Submit.
8. Click Proxy Performance, deselect the Run as a pure proxy check box, and click Submit.
9. Restart the proxy server and test the configuration: Open a web browser and navigate to "http://Your_Proxy_Server.com/", where is a Lotus Connections feature (such as Activities or Blogs). If the web page for the selected feature appears, the reverse proxy is working correctly.
You can check the reverse proxy logs under: C:\Program Files\IBM\edge\cp\server_root\logs.


Enabling SSL

A. Create a personal certificate on the proxy server

1. Create a key database for proxy server: Click Start > All Programs > IBM WebSphere > Edge Components > Caching Proxy > Start Key Management Utility.
2. Click Key Database File and select New.
3. Enter the following information and click OK:
Key database type: CMS
File Name: ProxyKey.kdb
Location: C:\ProxyDB
4. At the password prompt, enter your password and select the Stash the password to a file? check box.
5. Create a personal certificate: Click Create > New Self-Signed Certificate....
6. Enter the following information and click OK:
KeyLabel: ProxyCert
Version : X509V3
Key Size : 1024
Common name : Your_Proxy_Server.com
Organization : ibm


B. Import a signer certificate from the Web server

1. Extract the PluginCert.arm file from the IBM HTTP Server. (For more information about IHS, see Edge components information center): Open the plugin-key.kdb file (under C:\IBM\HTTPServer\Plugins\etc\) and click OK. Enter your password when prompted, and click OK.
2. Click WebSphere Plugin Key > Extract Certificate... and enter the following data:
Data type: Base64-encoded ASCII data
Certificate file name: PluginCert.arm
Location: C:\
Click OK.
3. Import the IHS Signer Certificate to the proxy server: Click Start > All Programs > IBM WebSphere > Edge Components > Caching Proxy > Start Key Management Utility, and open the ProxyKey.kdb file.
4. Click Signer Certificates > Add, and enter the following information:
Data type : Base64-encoded ASCII data
Certificate file name : PluginCert.arm
Location : C:\
Click OK
5. When prompted to enter a label, type PluginCert, and click OK.


C. Configure SSL on the proxy server

1. In the proxy server's admin console, open Proxy Configuration > SSL Settings.
2. Select the Enable SSL check box.
3. Select the Attempt to cache content on a secure request check box.
4. Enter the kdb location, for example, c:\ProxyKDB\ProxyKey.kdb, in the Key Ring Database file field.
5. Enter the password file location, for example, c:\ProxyKDB\ProxyKey.sth, in the Key Ring Database Password File field.
6. Click Submit.


D. Modify the ibmproxy.conf file
1. Add the following lines to enable Proxy and ReversePass directives:

Proxy /*
http://venturacn24.cn.ibm.com/* :80


Proxy /*
https://venturacn24.cn.ibm.com/* :443


ReversePass http://Your_HTTP_Server.com/*
http://Your_Proxy_Server.com/*


ReversePass https://Your_HTTP_Server.com/*
https://Your_Proxy_Server.com/*


2. Add the following line to enable the SendRevProxyName directive:

SendRevProxyName yes


3. Add the following lines to enable cache directives (optional):
CacheTimeMargin 0 seconds
CacheQueries Always http://Your_HTTP_Server.com/*
CacheQueries Always https://Your_HTTP_Server.com/*
4. Save the ibmproxy.conf file.
5. Restart the proxy server and test the configuration: Open a web browser and navigate to "https://Your_Proxy_Server.com/", where is a Lotus Connections feature (such as Activities or Blogs). If the web page for the selected feature appears, the reverse proxy in SSL mode is working correctly.
You can check the reverse proxy logs under: C:\Program Files\IBM\edge\cp\server_root\logs.

E. Test the configuration
1. Restart the proxy server.
2. Open a web browser and navigate to "https://Your_Proxy_Server.com/", where is a Lotus Connections feature (such as Activities or Blogs). If the web page for the selected feature appears, the reverse proxy in SSL mode is working correctly.
You can check the reverse proxy logs under: C:\Program Files\IBM\edge\cp\server_root\logs.

Recommended reading

* WebSphere Application Server Concepts, Planning, and Installation for Edge Components: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.edge.doc/welcome.html
* Reverse proxy definition: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzaie/rzaieproxytypes.htm
* WebSphere Application Server Network Deployment: http://www-306.ibm.com/software/webservers/appserv/was/network/edge.html