Setup Self SSL with tomcat...

Type the following command in UNIX

keytool -genkey -alias mycert -keyalg RSA -keystore /etc/tomcat6/keystore

and answered the prompts

Then edit my server.xml file and uncommented/edited this line

maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/etc/tomcat6/keystore"
keystorePass="mypassword" />


https://localhost:8443

Install Tomcat 6 on CentOS 5

Tomcat 6 on CentOS 5

It is easy to install tomcat6 on CentOs without wasting the time.

Step 1 cd /etc/yum.repos.d
Step 2 wget 'http://www.jpackage.org/jpackage50.repo'
Step 3 yum update
Step 4 yum install tomcat6 tomcat6-webapps tomcat6-admin-webapps
Step 5 service tomcat6 start

Path to deploy the application /var/lib/tomcat6/webapps/

conf path: - /usr/share/tomcat6/webapps

SSH password less authentication

SSH use to login from one PC to another without supplying the passwords.

# ssh-keygen -t rsa (Press Enter)

Generating public/private rsa key pair.
Enter file in which to save the key (/home/skx/.ssh/id_rsa): (Enter)
Enter passphrase (empty for no passphrase): (empty)
Enter same passphrase again: (empty)
Your identification has been saved in /home/skx/.ssh/id_rsa.
Your public key has been saved in /home/skx/.ssh/id_rsa.pub.

# ssh-copy-id -i ~/.ssh/id_rsa.pub username@remote_host - IP Address

Windows Server processes

1) smss.exe
Description
smss.exe is a process which is a part of the Microsoft Windows Operating System. It is called the Session Manager Subsystem and is responsible for handling sessions on your system. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
smss.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
smss.exe general information
Author: Microsoft Corp.
Part of: Microsoft Windows Operating System
Common Path(s): %system%\smss.exe

2) csrss.exe
Description
The Microsoft Client Server Runtime Server subsystem utilizes the process csrss.exe for managing the majority of the graphical instruction sets under the Microsoft Windows operating system. As such Csrss.exe provides the critical functions of the operating system, and its termination can result in the Blue Screen of Death being displayed.

Csrss.exe controls threading and Win32 console window features. Threading is where the application splits itself into multiple simultaneous running tasks. Threads supported by csrss.exe are different from processes in that threads are commonly contained within the process, with various threads sharing resources within the same process. The Win32 console is the plain text window in the Windows API system (programs can use the console without the need for image display).

In mobile devices such as notebooks and laptops, the process csrss.exe is closely dependent on power management schemes implemented by the system as defined under the Control Panel option.

Recommendation
csrss.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
csrss.exe general information
Author: Microsoft Corp
Part of: Microsoft Windows Operating System
Common Path(s): %system%\csrss.exe
3) winlogon.exe
Description
Description
winlogon.exe is a process belonging to the Windows login manager. It handles the login and logout procedures on your system. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
winlogon.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
winlogon.exe general information
Author: Microsoft Corp.
Part of: Microsoft Windows Operating System
Common Path(s): %system%\winlogon.exe
services.exe
Description
services.exe is a part of the Microsoft Windows Operating System and manages the operation of starting and stopping services. This process also deals with the automatic starting of services during the computers boot-up and the stopping of services during shut-down. This program is important for the stable and secure running of your computer and should not be terminated
Recommendation
services.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
services.exe general information
Author:
Microsoft Corp.

Part of:
Microsoft Windows Operating System

Common Path(s):
%system%\services.exe
lsass.exe
Description
The process lsass.exe serves as the Local Security Authentication Server by Microsoft, Inc. It is responsible for the enforcement of the security policy within the operating system. This process checks whether a user’s supplied identification is valid or not whenever he or she tries to access the computer system.

With the execution of the file lsass.exe, the system acquires security by preventing the access of unwanted users to any private information. The file lsass.exe also handles the password modifications done by the user.

The process lsass.exe mainly operates in the system through its ability to create access tokens. These tokens encapsulate the file’s security descriptor, which contains the necessary information to process user authentication such as data on which user holds access to the system and whether the access is mandatory or discretionary.
Recommendation
lsass.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
lsass.exe general information

Author:
Microsoft Corp.

Part of:
Microsoft Windows Operating System

Common Path(s):
%system%\LSASS.exe
%system%\system32\lsass.exe
svchost.exe
Description
The file svchost.exe is the Generic Host Process for Win32 Services used for administering 16-bit-based dynamically linked library files (DLL files) including other supplementary support applications.

As operating systems became more complex Microsoft decided to run more software functionality from a dynamic link library (DLL) interface. However DLLs are unable to launch themselves and require at least one executable program, i.e. svchost.exe, is needed to bridge between the library process and the operating system.

Through the solitary file svchost.exe, the DLLs efficiently contain and dispense Win32 services as well as neatly facilitate the execution of svchost.exe’s own operations. Acting as a host, the file svchost.exe creates multiple instances of itself. The multiple executions of the file svchost.exe contribute to the stability and security of the operating system by reducing the possibility of a crashing process that causes a domino effect on its neighbor processes, thereby creating a system-wide crash in the machine.
Recommendation
svchost.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Microsoft Windows Operating System

Common Path(s):
%system%\svchost.exe
ccsetmgr.exe
Description
ccsetmgr.exe is a process associated with the Symantec Internet Security suite and is essential to it's functioning. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Symantec Corporation

Part of:
Symantec Internet Security suite

Common Path(s):
%programfilescommon%\Symantec Shared\ccSetMgr.exe
spoolsv.exe
Description
The spoolsv.exe file is described as the Spooler SubSystem App or Windows Print Spooler Service and is the main component of the printing interfaces. The spoolsv.exe file is initialized when the computer starts, and it runs in the background until the computer is turned off.

The process spoolsv.exe transfers the data in a buffer. If the printer needs the data, it will retrieve it from the buffer. While the spoolsv.exe file is storing the data in the buffer, the user can carry out other operations. The spoolsv.exe process is also responsible for queuing printing tasks. Through this function, the user does not need to wait for each printing task to be completed one after the other.

When a printer is in use, the Print Spooler service or the spoolsv.exe file is launched, and the process can be seen running in Windows Task Manager. In case you are not using a printer, the spoolsv.exe process can be closed through the Task Manager.
Recommendation
spoolsv.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Microsoft Windows Operating System
Common Path(s):
%system%\spoolsv.exe
Msdtc.exe
Description
msdtc.exe is the Microsoft Distributed Transaction Coordinator. The process is loaded into the system by Microsoft Personal Web Server and Microsoft SQL Server. The service is used to manage transactions across multiple servers.
Recommendation
msdtc.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Microsoft Personal Web Server

Common Path(s):
N/A
bbattachserver.exe
Description
bbattachserver.exe is a Server belonging to BlackBerry® Attachment Server from Research In Motion Limited
Recommendation
This process is still being reviewed by our team. We shall be adding additional information, such as Security Rating, once the process is reviewed. If you have any information to contribute, you can send it to pl[at]Uniblue[dot]net.
Author:
Research In Motion Limited

Part of:
BlackBerry® Attachment Server

Common Path(s):
e:\program files\research in motion\blackberry enterprise server\attachserver
defwatch.exe
Description
defwatch.exe is a part of Norton Antivirus Corporate Edition, and is responsible for monitoring the virus definition files and initiating processes to bring them up to date if they aren't.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Symantec Corporation

Part of:
Norton Antivirus Corporarte Edition

Common Path(s):
N/A
dfssvc.exe
Description
dfssvc.exe is the Distributed File System service. Only found on Microsoft Windows Server suites, this process is crucial for the DFS service. Essential Microsoft server service.
Recommendation
dfssvc.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Microsoft Windows Server suite

Common Path(s):
N/A
dns.exe
Description
dns.exe is the main process which handles the Microsoft Windows DNS server, if enabled. This program is important for the stable and secure running of your server and should not be terminated.
Recommendation
dns.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Microsoft Windows Server Suites

Common Path(s):
N/A
nhancer.exe
Description
nhancer.exe is a nHancer.exe belonging to nHancer from KSE - Korndörfer Software Engineering
Recommendation
This process is still being reviewed by our team. We shall be adding additional information, such as Security Rating, once the process is reviewed. If you have any information to contribute, you can send it to pl[at]Uniblue[dot]net.
Author:
KSE - Korndörfer Software Engineering

Part of:
nHancer

Common Path(s):
%programfiles%\nhancer
inetinfo.exe
Description
inetinfo.exe is used primarily for debugging Microsoft Windows Server Internet Information Services. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
inetinfo.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Microsoft Windows Server Suites

Common Path(s):
%system%\inetinfo.exe
pds.exe
Description
pds.exe is associated with Intel LANDesk Management Suite software and discovers registered products on your computer. This program is a non-essential process, but should not be terminated unless suspected to be causing problems.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Intel Corporation.

Part of:
Intel Ping Discovery Service

Common Path(s):
N/A


llssrv.exe

Description
llssrv.exe on Microsoft Windows Server suites is a license logging service and should not be stopped under any circumstances.
Recommendation
Monitors and records client access licensing for portions of the operating system (such as IIS, Terminal Server and File/Print) as well as products that aren't a part of the OS, like SQL and Exchange Server. If this service is stopped, licensing will be enforced, but will not be monitored.
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Microsoft Corp.

Part of:
Microsoft License Service

Common Path(s):
N/A
mr2kserv.exe
Description
mr2kserv.exe is a process belonging to the Dell OpenManage and provides Array management functionality. This program is a non-essential process, but should not be terminated unless suspected to be causing problems.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Dell

Part of:
Dell OpenManage

Common Path(s):
N/A
nsctop.exe
Description
nsctop.exe is a process belonging to Symantec System Center. The application searches AV servers on the network.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Symantec Corporation

Part of:
Symantec System Center

Common Path(s):
N/A
ntfrs.exe
Description
ntfrs.exe is process belonging to Windows. It is used to maintain file synchronization of file directory contents among multiple servers. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
ntfrs.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Windows

Common Path(s):
N/A
qserver.exe
Description
qserver.exe is a process associated with the Norton Internet Security Suite and deals with the communication of quarantined files.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Symantec

Part of:
Norton Internet Security Suite

Common Path(s):
N/A

reportersvc.exe
Description
reportersvc.exe is a Symantec Reporting Service from Symantec Corporation belonging to Reporting
Description
reportersvc.exe is a Symantec Reporting Service from Symantec Corporation belonging to Reporting
Author:
Symantec Corporation

Part of:
Reporting

Common Path(s):
%programfilescommon%\symantec shared\reporting agents\win32
sbscrexe.exe
SBS Licensing Service
Description
sbscrexe.exe is a SBS Licensing Service from Microsoft Corporation belonging to Microsoft® Windows® Operating System
Author:
Microsoft Corporation

Part of:
Microsoft® Windows® Operating System

Common Path(s):
%system%
scanexplicit.exe
Description
scanexplicit.exe is a part of Norton Internet Security Suite and scans files submitted to the Quarantine section using a separate set of definitions. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
scanexplicit.exe general information
Author:
Symantec Corporation

Part of:
NAV Symantec Quarantine Scanner

Common Path(s):
N/A
owstimer.exe
owstimer.exe description
Description
owstimer.exe is a SharePoint Timer Service from Microsoft Corporation belonging to Microsoft SharePoint
Recommendation
owstimer.exe general information
Author:
Microsoft Corporation

Part of:
Microsoft SharePoint

Common Path(s):
%programfilescommon%\microsoft shared\web server extensions\50\bin
%programfilescommon%\microsoft shared\web server extensions\60\bin
sqlagent.exe
Microsoft SQL Server Agent
Description
sqlagent.exe is a process belonging to the Microsoft SQL Server Agent and is used for executing scheduled jobs.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Microsoft Corp.

Part of:
Microsoft SQL Server Agent

Common Path(s):
N/A
appmgr.exe
Description
appmgr.exe is a process belonging to the Windows Server operating system which provides remote server management functionality. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
appmgr.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft

Part of:
Microsoft Windows Server

Common Path(s):
%system%\serverappliance\appmgr.exe
conduit.exe
Description
conduit.exe is a conduit_client belonging to Symantec Brightmail AntiSpam[tm] from Symantec Corporation
conduit.exe general information
Author:
Symantec Corporation

Part of:
Symantec Brightmail AntiSpam[tm]

Common Path(s):
%programfiles%\symantec\sbas\scanner\bin
uphclean.exe
Description
uphclean.exe is a process belonging to Microsoft's User profile cleanup service. This program is a non-essential process, but should not be terminated unless suspected to be causing problems.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Microsoft Corporation

Part of:
Microsoft Windows Operating System

Common Path(s):
%programfiles%\uphclean\uphclean.exe
tcpsvcs.exe
Description
tcpsvcs.exe is a part of Microsoft Windows networking components. This essential system process is initiated when the computer uses special TCP/IP networking services such as DHCP, Simple TCP and print services. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
tcpsvcs.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Microsoft Windows Operating System

Common Path(s):
%system%\tcpsvcs.exe
icepack.exe
Description
icepack.exe is a part of the Norton Antivirus Corporate edition suite and acts as a medium between server and client. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Symantec Corporation

Part of:
NAV CE Server/Client - Symantec Quarantine Agent

Common Path(s):
N/A
hndlrsvc.exe
Intel Alert Handler
Description
hndlrsvc.exe is a process associated with Intel Alert Handler which alerts you regarding e-mails, and other options. This is a non-essential process. Disabling or enabling it is down to user preference.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Intel Corporation

Part of:
Intel Alert Handler

Common Path(s):
N/A
iao.exe
Description
iao.exe is a process belonging to Symantec Internet security suite. This program is important for the stable and secure running of your computer and should not be terminated.
Click to run a free scan for iao.exe related errors.

Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
exmgmt.exe
exmgmt.exe description
Description
exmgmt.exe is a process belonging to the Microsoft Exchange Console which allows for configuration of this e-mail server product. This program is a non-essential process, but should not be terminated unless suspected to be causing problems.
Recommendation
Not a critical component, but see the information above before disabling it. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings..
Author:
Microsoft

Part of:
Microsoft Exchange Server Suite

Common Path(s):
%programfiles%\Exchsrvr\bin\exmgmt.exe
mad.exe
mad.exe description
Description
mad.exe is a process which deals with certain important Microsoft Exchange functions such as the loading of DLL's and message logging. This program is important for the stable and secure running of your computer and should not be terminated.
Recommendation
mad.exe should not be disabled, required for essential applications to work properly.. It is highly recommended to Run a Free Performance Scan to automatically optimize memory, CPU and Internet Settings.
Author:
Microsoft Corp.

Part of:
Microsoft Exchance Server

Common Path(s):
N/A


mssearch.exe

mssearch.exe is a process relating to Microsoft Windows Server suite, which is responsible for the cataloguing of indexes for Exchange server and SQL server. This program is important for the stable and secure running of your computer and should not be terminated.
mssearch.exe general information

Author: Microsoft Corp.
Part of: Microsoft Windows Server suite
Common Path(s):
N/A
wmiprvse.exe
wmiprvse.exe description
The wmiprvse.exe file is otherwise known as Windows Management Instrumentation. It is a Microsoft Windows-based component that provides control and information about management in an enterprise environment.

Developers use the wmiprvse.exe file in order to develop applications used for monitoring purposes. These programs can notify users about important events related to network and file or application management right after each event occurs. With wmiprvse.exe, file managers in the enterprise environment are capable of configuring and searching for desktop system information or network and application information across the network.

The wmiprvse.exe file is placed with other services in the shared service host. This started to be applied with the release of MS Windows XP. Providers are also loaded separately in the wmiprvse.exe file since it considers the wmiprvse.exe executable as a host process.

Author: Microsoft
Part of: Microsoft Windows Operating System
Common Path(s):
%system%\wbem\wmiprvse.exe
itadminserver.exe

Description
itadminserver.exe is a ITAdminServer belonging to BlackBerry® Policy Service from Research In Motion Limited
Recommendation
Author: Research In Motion Limited
Part of: BlackBerry® Policy Services
Common Path(s): e:\program files\research in motion\blackberry enterprise server
IMBSERVICE.EXE
Description
imbservice.exe is a IMBSERVICE.EXE belonging to Microsoft® Windows® Small Business Server from Microsoft Corporation
Author:
Microsoft Corporation

Part of:
Microsoft® Windows® Small Business Server

Common Path(s):
%programfiles%\microsoft windows small business server\networking\pop3

Locator.exe
locator.exe is the remote procedure call locator service and is essential for the smooth running of Microsoft Windows. This process maintains a database of publicly declared procedures. This program is important for the stable and secure running of your computer and should not be terminated.
Author:
Microsoft Corp.

Part of:
Microsoft Windows Operating System
Common Path(s):
%system%\locator.exe

w3wp.exe
Description
w3wp.exe is a process associated with application pool in ISS. If you have more than one application pool, you will have more than one instance of w3wp.exe running. This process usually allocates large amounts of resources. This program is important for the stable and secure running of your computer and should not be terminated.
Author:
Microsoft

Part of:
Microsoft Web Server

Common Path(s):
N/A
SFMSVC.EXE - Windows NT Macintosh File Server Service
Sfmsvc.exe is related to Windows NT Macintosh File Server Service.
Manufacturer: Microsoft Corp.
beremote.exe

beremote.exe is a process that belongs to Backup Exec from Veritas. This process should not be removed to ensure that the backup process is not interrupted
Author:
Veritas

Part of:
Backup Exec

Common Path(s):
N/A

pvlsvr.exe

Description
pvlsvr.exe is a part of Veritas Backup Exec and offers essential functionality for Backup Exec. This program is important for the stable and secure running of your computer and should not be terminated.
Author:
VERITAS Software Corporation.

Part of:
Veritas Backup Exec

Common Path(s):
N/A
beserver.exe
Description
beserver.exe is the main backup service for Veritas Backup Exec. This program is essential in keeping backups up to date and should not be terminated.
Author:
VERITAS Software Corporation.

Part of:
Unknown

Common Path(s):
N/A
bengine.exe
Description
bengine.exe is the main backup service for Veritas Backup Exec. This program is essential in keeping backups up to date and should not be terminated.
Author:
Veritas Software Corporation

Part of:
Veritas Backup Exec

Common Path(s):
N/A
benetns.exe
Description
benetns.exe belongs to the Backup Exec application from Veritas. This process provides a remote browsing agent for the Backup Exec service on the backup server. This process should not be removed to ensure that your backup applications works properly.
Author:
VERITAS Software Corporation.

Part of:
Veritas Backup Exec

Common Path(s):
N/A
dlt.exe
Description
dlt.exe is a part of the Dell OpenManage system management software. Essential system process for the running of Dell OpenManage, and should not be disabled whilst this application is used.
Author:
Dell

Part of:
Dell Legacy

Common Path(s):
N/A
savfmsesp.exe
Symantec Mail Security for Microsoft Exchange

Description
savfmsesp.exe is a Symantec Mail Security for Microsoft Exchange from Symantec Corporation belonging to Symantec Mail Security for Microsoft Exchange
Author:
Symantec Corporation

Part of:
Symantec Mail Security for Microsoft Exchange

Common Path(s):
%programfiles%\symantec\smsmse\4.6\server
ccApp.exe
ccapp.exe
Description
The ccapp.exe file stands for Common Client Application and is the executable responsible for checking emails and auto-protect facilities as part of the Norton Antivirus suite.

The ccapp.exe file is used as the Norton Antivirus’ real-time scanner. When Windows loads, the ccapp.exe file also loads as VxD or virtual device driver. As the ccapp.exe file executes behind the scenes, it scans your system for Trojan Horses, viruses, and worms.

Before Windows can completely shut down, the ccapp.exe file will scan the boot drives for sector viruses if a floppy disk can be found inside the drive. In case a virus is detected, a message will be displayed asking you to repair the infected floppy disk boot record.

You will be able to view the details of the scan in the recorded report log. Details in the report include the name of the virus, location of the file infected, time it was detected, and the action taken by the application or the user.
Author:
Symantec Corporation

Part of:
Norton AntiVirus Suite

Common Path(s):
%program files%\common\symantec shared\

vptray.exe
Description
vptray.exe is the tray bar process for Norton AntiVirus. It gives the user fast access to Norton AntiVirus. This process can safely be removed without reducing system security.
Author:
Symantec Corporation

Part of:
Norton AntiVirus

Common Path(s):
N/A
ctfmon.exe
Description
ctfmon.exe is a process belonging to Microsoft Office Suite. It activates the Alternative User Input Text Input Processor (TIP) and the Microsoft Office XP Language Bar. This program is a non-essential system process, but should not be terminated unless suspected to be causing problems.
Author:
Microsoft Corp.

Part of:
Microsoft Office Suite

Common Path(s):
%system%\ctfmon.exe
sqlmangr.exe
Description
sqlmangr.exe is a system tray application from Microsoft which allows the user to start and stop SQL related services. This program is a non-essential system process, but should not be terminated unless suspected to be causing problems.
Author:
Microsoft Corp.

Part of:
Microsoft SQL Server Service Manager

Common Path(s):
%programfiles%\Microsoft SQL Server\80\Tools\Binn\sqlmangr.exe

logon.scr
Microsoft Logon Screensaver

Description
logon.scr is a process belonging to the Microsoft Windows Operating System and provides a screensaver during the login phase. This is a non-essential process. Disabling or enabling it is down to user preference.
Author:
Microsoft

Part of:
Microsoft Windows Operating System

Common Path(s):
%system%\logon.scr


bbconvert.exe
Description
bbconvert.exe is a Convert belonging to BlackBerry® Attachment Server from Research In Motion Limited
Author:
Research In Motion Limited

Part of:
BlackBerry® Attachment Server

Common Path(s):
e:\program files\research in motion\blackberry enterprise server\attachserver


csrss.exe
bbconvert.exe description
Description
bbconvert.exe is a Convert belonging to BlackBerry® Attachment Server from Research In Motion Limited
Author:
Research In Motion Limited

Part of:
BlackBerry® Attachment Server

Common Path(s):
e:\program files\research in motion\blackberry enterprise server\attachserver



winlogon.exe
winlogon.exe is a process belonging to the Windows login manager. It handles the login and logout procedures on your system. This program is important for the stable and secure running of your computer and should not be terminated.
Author:
Microsoft Corp.

Part of:
Microsoft Windows Operating System

Common Path(s):
%system%\winlogon.exe
VPTray.exe
vptray.exe is the tray bar process for Norton AntiVirus. It gives the user fast access to Norton AntiVirus. This process can safely be removed without reducing system security.
Author:
Symantec Corporation

Part of:
Norton AntiVirus

Common Path(s):
N/A
ctfmon.exe

Mono on Linux

Steps:-

1: Install Mono 2.4 And Mod_mono On RHEL5 With Mysql Support
2: To Install BIRT Runtime On RHEL 5

Assumptions
1: You have root access on your RHEL 5 system
2: You are aware of basic sysadmin commands.
Note: This install was tested on a x64 system.

1:Install Mono 2.4 and mod_mono on RHEL5 with Mysql support

Files to Download
Http://Ftp.Novell.Com/Pub/Mono/Sources/Libgdiplus/Libgdiplus-2.4.2.Tar.Bz2
Http://Ftp.Novell.Com/Pub/Mono/Sources/Mono/Mono-2.4.2.3.Tar.Bz2
Http://Ftp.Novell.Com/Pub/Mono/Sources/Xsp/Xsp-2.4.2.Tar.Bz2
Http://Ftp.Novell.Com/Pub/Mono/Sources/Mod_mono/Mod_mono-2.4.2.Tar.Bz2
Http://Mirror.Cogentco.Com/Pub/Mysql/Connector-Net/Mysql-Connector-Net-6.0.4-Noinstall.Zip

RPMs
You need the following rpms to compile mod_mono. You should have these on your RHEL CD.
httpd-devel
apr-devel
apr-util
apr-util-devel

All my sources are placed in /opt/downloads
All my sources will be untared in /opt/build

To install mono on RHEL5

Step 1 : Untar libgdi and build it

tar -jxvf /opt/downloads/libgdiplus-2.4.2.tar.bz2 -C /opt/build
cd /opt/build/libgdiplus-2.4.2
./configure;make;make install

Step 2: Untar mono and build

cd /opt/downloads/mono-2.4.2.3/
./configure ;make;make install

To install mod mono

Step 1: Untar mod_mono package, configure, build & install

tar -jxvf /opt/downloads/mod_mono-2.4.2.tar.bz2
./configure ;make;make install

Move the mod_mono.conf file to the right location so that it is automatically loaded

mv /etc/httpd/conf/mod_mono.conf /etc/httpd/conf.d/

Add this line to the mod_mono.conf
MonoServerPath /usr/local/bin/mod-mono-server2

Step 2: Untar xsp, configure, build & install

tar -jxvf xsp-2.4.2.tar.bz2 -C /opt/build
cd /opt/build/xsp-2.4.2
./configure;make;make install


Now to test mod_mono
copy xsp files to your document root dir

cp -a /usr/local/lib/xsp/test /var/www/html/

Now go to your browser and check out your installation
http://localhost/test/

Now go ahead if you need to install mysql support

cd /opt/build
unzip /opt/downloads/mysql-connector-net-6.0.4-noinstall.zip
mv mysql.data.dll MySql.Data.dll
/usr/local/bin/gacutil -i /opt/build/MySql.Data.dll

Common error

Object reference not set to an instance of an object
Description: HTTP 500. Error processing request.

1: If you do not change the name of the dll you might get this
error below. So make sure your dll is MySql.Data.dll

2: Make sure you save these config settings in your web.conf






Return To Top

2: To install BIRT runtime on RHEL 5

Files to download
Http://Apache.Mirrors.Hoobly.Com/Tomcat/Tomcat-6/V6.0.20/Bin/Apache-Tomcat-6.0.20.Tar.Gz
Http://Www.Eclipse.Org/Downloads/Download.Php?File=/Birt/Downloads/Drops/R-R1-2_5_0-200906180630/Birt-Runtime-2_5_0.Zip
Jre-6u16-Linux-Amd64.Rpm

Note: Since you are installing the Web Viewer on Tomcat 6, you will need to download the Commons Logging Library.

Install Sun JDK

rpm -ivh /opt/downloads/jre-6u16-linux-amd64.rpm

set your java home

export JAVA_HOME=/usr/java/jre1.6.0_16/

Install Apache tomcat

tar -zxvf /opt/downloads/apache-tomcat-6.0.20.tar.gz -C /opt/build/
cd /opt/build/apache-tomcat-6.0.20/bin/
./startup.sh

Test your installation from the browser
http://localhost:8080/
To use the tomcat manager, set manager user for tomcat in tomcat-users.xml

Restart tomcat and check the url http://localhost:8080/manager/html


Install BIRT runtime

cd /opt/build
unzip /opt/downloads/birt-runtime-2.1.3.zip
cd /opt/build/birt-runtime-2_1_3/
cp -a WebViewerExample /opt/build/apache-tomcat-6.0.20/webapps
mv /opt/build/apache-tomcat-6.0.20/webapps/WebViewerExample/ /opt/build/apache-tomcat-6.0.20/webapps/birt-viewer

Install Commons Logging Library

tar -zxvf /opt/downloads/used/commons-logging-1.1.1-bin.tar.gz -C /opt/build

Copy the jar file into birt-viewer

cp /opt/build/commons-logging-1.1.1/commons-logging-1.1.1.jar /opt/build/apache-tomcat-6.0.20/webapps/birt-viewer/WEB-INF/lib/

Use the tomcat manager to see whether birt-viewer has been auto deployed.

Now you can check your birt-viewer report from your browser http://localhost:8080/birt-viewer/

A page confirming that the BIRT viewer has been installed should be displayed.
Click on the link labeled "View Example" to confirm that your installation is working properly.
The BIRT Viewer requires that cookies be enabled.

Common Errors:
I tried BIRT with the default install of jre on RHEL5/ Fedora8 and I came across so many errors.
After a lot of google I gave up on those versions and downloaded tomcat 6 and sun jre and it worked fine.

Create certificate using keytool on glassfish

Create certificate

Use keytool to generate, import, and export certificates. By default, keytool creates a keystore file in the directory where it is run. You can find the keytool utility under the bin directory of java folder.
Note: - When you install Glassfish, it creates a default self-signed certificate as the server certificate. (localhost)

Step:- 1

Delete exiting certificate :-

Type the following command to delete the default self-signed certificate by issuing the following command.
keytool -delete -alias s1as -keystore keystore.jks -storepass

Generate self signed certificate

Steps 1:- Type the following command to create new certificate:
keytool -genkey -alias test

Fill all the information to create the certificate.

Enter keystore password: p@ssw0rd!
What is your first and last name?
[Unknown]: Chandra
what is the name of your organizational unit?
[Unknown]: Paxcel
what is the name of your organization?
[Unknown]: Paxcel
what is the name of your City or Locality?
[Unknown]: Gurgaon
What is the name of your State or Province?
[Unknown]: HR
What is the two-letter country code for this unit?
[Unknown]: IN
Is correct?
[no]: yes
Import certificate

A certificate can be imported into a keystore using keytool. Type the following command to import the certificate:-
keytool -storepass my-keystore-password(paxcel) -alias test -import -file test.cer

Generate expired certificate

Steps:

Default days is 7 and cant not be set 0 day. You need to specify at least 1 day to

create.
keytool -genkey -alias test –validity 1


Note: - To change the location of certificate files - admin console.
Always generate the certificate in the directory containing the keystore and truststore files, by default domain-dir/config.

Open the Glassfish admin console in the web browser.
Login into glassfish admin console (http://localhost:4848), Default uid and password:

admin and adminadmin

a) In the Admin Console tree, select the Application Server node.
b) Select JVM Settings.
c) Click the JVM Options tab.
d) On the JVM Options page, add or modify the following values in the Value

field to reflect the new location of the certificate files:
-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/path/ks-name
-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/path/ts-name

e) Where ks-name is the keystore file name and ts-name is the trust store file name.

f) Click Save.

g) Restart the Application Server if Restart Required displays in the console.

Install certificate in GlassFish server


Here are the instructions for enabling GlassFish v2 as an SSL server when the application server is configured with the developer profile.

1. Delete the default self-signed certificate by issuing the following command (note that the commands in this and subsequent steps are shown on multiple lines for formatting purposes):
keytool -delete -alias s1as -keystore keystore.jks -storepass
where is the password for the keystore, for example, "mypass". Note that s1as is the default alias of the GlassFish v2 keystore.

2. Generate a new key pair for the application server by issuing the following command:
keytool -genkeypair -keyalg
-keystore keystore.jks -validity -alias s1as

where is the algorithm to be used for generating the key pair, for example RSA, and is the number of days that the certificate should be considered valid, for example, 365.
Note that in addition to generating a key pair, the command wraps the public key into a self-signed certificate and stores the certificate and the private key in a new keystore entry identified by the alias.

It's important to ensure that the name of the certificate matches the fully-qualified hostname of your site. If the names don't match, clients connecting to the server will see a security alert stating that the name of the certificate does not match the name of the site. You should notice that the name of the default self-signed certificate matches the fully-qualified hostname.


3. Generate a Certificate Signing Request (CSR) by issuing the following command:
keytool -certreq -alias s1as -file
-keystore keystore.jks -storepass
where is the file in which the CSR is stored, for example, s1as.csr, and is the password for the keystore, for example, changeit.


4. keytool -import -v -alias s1as -file s1as.cert -keystore keystore.jks -storepass
When you import the certificate using the same original alias "s1as", keytool treats it as a command to replace the original certificate with the certificate obtained as reply to a CSR.
s1as (self-signed):
Owner: CN=chandra, OU=Paxcel, O=Paxcel Technologies, L=Gurgaon , ST=Haryana, C=IN
Issuer: CN=Chandra, OU=Paxcel Technologies, O=Paxcel Technologies
, L=Gurgaon, ST=Haryana, C=IN
Serial number: 472acd34
Valid from:

Multiple Private Keys in a GlassFish

Multiple Private Keys in a GlassFish domain
GlassFish uses Java JKS for storing keys and certificates. Out of the box, the keyStore (keystore.jks) and the trustStore (cacerts.jks) reside in $GLASSFISH_HOME/domains/domain1. Even though there are several CA root certificates in cacerts.jks, there is only one private key in keystore.jks.

GlassFish supports the use of multiple private keys in a given domains. For instance, you may have two https listeners having different server private keys. This is a very useful scenario especially when one have EC key. So, in a given domain, we can have one https listener using RSA key for normal browser and one https listener using EC key for PDA.

In this blog, we will discuss the configuration when there are multiple private keys in a given domain of GlassFish. In this case, one needs to specify the private key / certificate to be used for SSL communication. If the information is not specified, then the server will pick up one which may not be desirable. Since one wants to be more precise in security environment, one would like to specify the corresponding certificate nickname in order to pick up the correct key.

There are two kinds of certificate nicknames: inbound, https outbound.

Inbound Certificate Nickname

One needs to specify the inbound cert-nickname for a given listener in domain.xml. For instance, in http listener, it is as follows:



...

Instead of hand-crafting the domain.xml, it would be a good idea to use Admin Console as follows: Configuration > HTTP Services > Http listeners > http-listener-2, and choose SSL tab and enter the valid alias value you want in "Certificate Nickname" textbox. Then one needs to restart the given domain (if there is a change of certificate nickname) in order to activate the change.

Similarly for iiop listeners.

Https Outbound Certificate Nickname

GlassFish also supports the https outbound from server. A private key / certificate is used for https outbound mutual SSL authentication. In this case, we can specify the https outbound certificate nickname as jvm-options in domain.xml:

-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=YOUR_ALIAS

One can achieve this through Admin Console as follows: Application Server > JVM Settings > JVM Options > Add JVM option, and enter the above jvm option in the new textbox. Then one needs to restart the server in order to activate this change.

Delete certificate - Keytool

Deleting a Certificate Using the keytool Utility
To delete an existing certificate, use the keytool -delete command, for example:


keytool -delete -alias keyAlias -keystore keystore-name -storepass password

Sign a digital certificate using the keytool utility

To sign a digital certificate using the keytool utility
After creating a digital certificate, the owner must sign it to prevent forgery. E-commerce sites, or those for which authentication of identity is important can purchase a certificate from a well-known Certificate Authority (CA). If authentication is not a concern, for example if private secure communications is all that is required, save the time and expense involved in obtaining a CA certificate and use a self-signed certificate.

Follow the instructions on the CA’s Web site for generating certificate key pairs.

Download the generated certificate key pair.

Save the certificate in the directory containing the keystore and truststore files, by default domain-dir/config directory. See To change the location of certificate files.

In your shell, change to the directory containing the certificate.

Use keytool to import the certificate into the local keystore and, if necessary, the local truststore.


keytool -import -v -trustcacerts -alias keyAlias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit
If the keystore or private key password is not the default password, then substitute the new password for changeit in the above command.

Restart the Application Server.

Generate a certificate using the keytool utility

To generate a certificate using the keytool utility
Use keytool to generate, import, and export certificates. By default, keytool creates a keystore file in the directory where it is run.

Change to the directory where the certificate is to be run.

Always generate the certificate in the directory containing the keystore and truststore files, by default domain-dir/config. For information on changing the location of these files, see To change the location of certificate files.

Enter the following keytool command to generate the certificate in the keystore file, keystore.jks:


keytool -genkey -alias keyAlias -keyalg RSA -keypass changeit -storepass changeit -keystore keystore.jks
Use any unique name as your keyAlias. If you have changed the keystore or private key password from their default, then substitute the new password for changeit in the above command.

A prompt appears that asks for your name, organization, and other information that keytool uses to generate the certificate.

Enter the following keytool command to export the generated certificate to the file server.cer (or client.cer if you prefer):


keytool -export -alias keyAlias-storepass changeit
-file server.cer
-keystore keystore.jks
If a certificate signed by a certificate authority is required, see To sign a digital certificate using the keytool utility.

To create the truststore file cacerts.jks and add the certificate to the truststore, enter the following keytool command:


keytool -import -v -trustcacerts -alias keyAlias -file server.cer -keystore cacerts.jks -keypass changeit
If you have changed the keystore or private key password from their default, then substitute the new password for changeit in the above command.

The tool displays information about the certificate and prompts whether you want to trust the certificate.

Type yes, then press Enter.

Then keytool displays something like this:


Certificate was added to keystore [Saving cacerts.jks]
Restart the Application Server.

Installing and Configuring SSL Support & XML and Web Services Security

Installing and Configuring SSL Support
What Is Secure Socket Layer Technology?
Secure Socket Layer (SSL) technology allows web browsers and web servers to communicate over a secure connection. In this secure connection, the data that is being sent is encrypted before being sent and then is decrypted upon receipt and before processing. Both the browser and the server encrypt all traffic before sending any data. SSL addresses the following important security considerations.
• Authentication: During your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials in the form of a server certificate. The purpose of the certificate is to verify that the site is who and what it claims to be. In some cases, the server may request a certificate that the client is who and what it claims to be (which is known as client authentication).
• Confidentiality: When data is being passed between the client and the server on a network, third parties can view and intercept this data. SSL responses are encrypted so that the data cannot be deciphered by the third party and the data remains confidential.
• Integrity: When data is being passed between the client and the server on a network, third parties can view and intercept this data. SSL helps guarantee that the data will not be modified in transit by that third party.
To install and configure SSL support on your stand-alone web server, you need the following components. SSL support is already provided if you are using the Application Server. If you are using a different web server, consult the documentation for your product.
• A server certificate keystore (see Understanding Digital Certificates).
• An HTTPS connector (see Using SSL).
To verify that SSL support is enabled, see Verifying SSL Support.
Understanding Digital Certificates
________________________________________
Note: Digital certificates for the Application Server have already been generated and can be found in the directory /domains/domain1/config/. These digital certificates are self-signed and are intended for use in a development environment; they are not intended for production purposes. For production purposes, generate your own certificates and have them signed by a CA.
________________________________________
To use SSL, an application server must have an associated certificate for each external interface, or IP address, that accepts secure connections. The theory behind this design is that a server should provide some kind of reasonable assurance that its owner is who you think it is, particularly before receiving any sensitive information. It may be useful to think of a certificate as a "digital driver's license" for an Internet address. It states with which company the site is associated, along with some basic contact information about the site owner or administrator.
The digital certificate is cryptographically signed by its owner and is difficult for anyone else to forge. For sites involved in e-commerce or in any other business transaction in which authentication of identity is important, a certificate can be purchased from a well-known certificate authority (CA) such as VeriSign or Thawte.
Sometimes authentication is not really a concern--for example, an administrator may simply want to ensure that data being transmitted and received by the server is private and cannot be snooped by anyone eavesdropping on the connection. In such cases, you can save the time and expense involved in obtaining a CA certificate and simply use a self-signed certificate.
SSL uses public key cryptography, which is based on key pairs. Key pairs contain one public key and one private key. If data is encrypted with one key, it can be decrypted only with the other key of the pair. This property is fundamental to establishing trust and privacy in transactions. For example, using SSL, the server computes a value and encrypts the value using its private key. The encrypted value is called a digital signature. The client decrypts the encrypted value using the server's public key and compares the value to its own computed value. If the two values match, the client can trust that the signature is authentic, because only the private key could have been used to produce such a signature.
Digital certificates are used with the HTTPS protocol to authenticate web clients. The HTTPS service of most web servers will not run unless a digital certificate has been installed. Use the procedure outlined later to set up a digital certificate that can be used by your web server to enable SSL.
One tool that can be used to set up a digital certificate is keytool, a key and certificate management utility that ships with the J2SE SDK. It enables users to administer their own public/private key pairs and associated certificates for use in self-authentication (where the user authenticates himself or herself to other users or services) or data integrity and authentication services, using digital signatures. It also allows users to cache the public keys (in the form of certificates) of their communicating peers. For a better understanding of keytool and public key cryptography, read the keytool documentation at the following URL:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/key-
tool.html
Creating a Server Certificate
A server certificate has already been created for the Application Server. The certificate can be found in the /domains/domain1/config/ directory. The server certificate is in keystore.jks. Thecacerts.jks file contains all the trusted certificates, including client certificates.
If necessary, you can use keytool to generate certificates. The keytool stores the keys and certificates in a file termed a keystore, a repository of certificates used for identifying a client or a server. Typically, a keystore contains one client or one server's identity. The default keystore implementation implements the keystore as a file. It protects private keys by using a password.
The keystores are created in the directory from which you run keytool. This can be the directory where the application resides, or it can be a directory common to many applications. If you don't specify the keystore file name, the keystores are created in the user's home directory.
To create a server certificate follow these steps:
1. Create the keystore.
2. Export the certificate from the keystore.
3. Sign the certificate.
4. Import the certificate into a trust-store: a repository of certificates used for verifying the certificates. A trust-store typically contains more than one certificate. An example using a trust-store for SSL-based mutual authentication is discussed in Example: Client-Certificate Authentication over HTTP/SSL with JAX-RPC.
Run keytool to generate the server keystore, which we will name keystore.jks. This step uses the alias server-alias to generate a new public/private key pair and wrap the public key into a self-signed certificate inside keystore.jks. The key pair is generated using an algorithm of type RSA, with a default password of changeit. For more information on keytool options, see its online help athttp://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html.
________________________________________
Note: RSA is public-key encryption technology developed by RSA Data Security, Inc. The acronym stands for Rivest, Shamir, and Adelman, the inventors of the technology.
________________________________________
From the directory in which you want to create the keystore, run keytool with the following parameters.
1. Generate the server certificate.
\bin\keytool -genkey -alias server-alias
-keyalg RSA -keypass changeit -storepass changeit
-keystore keystore.jks
When you press Enter, keytool prompts you to enter the server name, organizational unit, organization, locality, state, and country code. Note that you must enter the server name in response to keytool'sfirst prompt, in which it asks for first and last names. For testing purposes, this can be localhost. The host specified in the keystore must match the host identified in the host variable specified in the/j2eetutorial14/examples/common/build.properties when running the example applications.
2. Export the generated server certificate in keystore.jks into the file server.cer.
\bin\keytool -export -alias server-alias
-storepass changeit -file server.cer -keystore keystore.jks
3. If you want to have the certificate signed by a CA, read Signing Digital Certificates for more information.
4. To create the trust-store file cacerts.jks and add the server certificate to the trust-store, run keytool from the directory where you created the keystore and server certificate. Use the following parameters:
\bin\keytool -import -v -trustcacerts
-alias server-alias -file server.cer
-keystore cacerts.jks -keypass changeit
-storepass changeit
Information on the certificate, such as that shown next, will display.
/j2eetutorial14/examples/gs 60% keytool -import
-v -trustcacerts -alias server-alias -file server.cer
-keystore cacerts.jks -keypass changeit -storepass changeit
Owner: CN=localhost, OU=Sun Micro, O=Docs, L=Santa Clara, ST=CA, C=US
Issuer: CN=localhost, OU=Sun Micro, O=Docs, L=Santa Clara, ST=CA, C=US
Serial number: 3e932169
Valid from: Tue Apr 08
Certificate fingerprints:
MD5: 52:9F:49:68:ED:78:6F:39:87:F3:98:B3:6A:6B:0F:90
SHA1: EE:2E:2A:A6:9E:03:9A:3A:1C:17:4A:28:5E:97:20:78:3F:
Trust this certificate? [no]:
5. Enter yes, and then press the Enter or Return key. The following information displays:
Certificate was added to keystore
[Saving cacerts.jks]
Signing Digital Certificates
After you've created a digital certificate, you will want to have it signed by its owner. After the digital certificate has been cryptographically signed by its owner, it is difficult for anyone else to forge. For sites involved in e-commerce or any other business transaction in which authentication of identity is important, a certificate can be purchased from a well-known certificate authority such as VeriSign or Thawte.
As mentioned earlier, if authentication is not really a concern, you can save the time and expense involved in obtaining a CA certificate and simply use the self-signed certificate.
Using a Different Server Certificate with the Application Server
Follow the steps in Creating a Server Certificate, to create your own server certificate, have it signed by a CA, and import the certificate into keystore.jks.
Make sure that when you create the certificate, you follow these rules:
• When you press create the server certificate, keytool prompts you to enter your first and last name. In response to this prompt, you must enter the name of your server. For testing purposes, this can belocalhost.
• The server/host specified in the keystore must match the host identified in the host variable specified in the /j2eetutorial14/examples/common/build.properties file for running the example applications.
• Your key/certificate password in keystore.jks should match the password of your keystore, keystore.jks. This is a bug. If there is a mismatch, the Java SDK cannot read the certificate and you get a "tampered" message.
• If you want to replace the existing keystore.jks, you must either change your keystore's password to the default password (changeit) or change the default password to your keystore's password:
To specify that the Application Server should use the new keystore for authentication and authorization decisions, you must set the JVM options for the Application Server so that they recognize the new keystore. To use a different keystore than the one provided for development purposes, follow these steps.
1. Start the Application Server if you haven't already done so. Information on starting the Application Server can be found in Starting and Stopping the Application Server.
2. Start the Admin Console. Information on starting the Admin Console can be found in Starting the Admin Console.
3. Select Application Server in the Admin Console tree.
4. Select the JVM Settings tab.
5. Select the JVM Options tab.
6. Change the following JVM options so that they point to the location and name of the new keystore. There current settings are shown below:
-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks
-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks
7. If you've changed the keystore password from its default value, you need to add the password option as well:
-Djavax.net.ssl.keyStorePassword=your_new_password
8. Logout of the Admin Console and restart the Application Server.
Creating a Client Certificate for Mutual Authentication
This section discusses setting up client-side authentication. When both server-side and client-side authentication are enabled, it is called mutual, or two-way, authentication. In client authentication, clients are required to submit certificates that are issued by a certificate authority that you choose to accept. From the directory where you want to create the client certificate, run keytool as outlined here. When you press Enter,keytool prompts you to enter the server name, organizational unit, organization, locality, state, and country code.
________________________________________
Note: You must enter the server name in response to keytool's first prompt, in which it asks for first and last names. For testing purposes, this can be localhost. The host specified in the keystore must match the host identified in the host variable specified in the /j2eetutorial14/examples/common/build.properties file. If this example is to verify mutual authentication and you receive a runtime error stating that the HTTPS host name is wrong, re-create the client certificate, being sure to use the same host name that you will use when running the example. For example, if your machine name is duke, then enterduke as the certificate CN or when prompted for first and last names. When accessing the application, enter a URL that points to the same location--for example, https://duke:8181/mutualauth/hello. This is necessary because during SSL handshake, the server verifies the client certificate by comparing the certificate name and the host name from which it originates.
________________________________________
To create a keystore named client-keystore.jks that contains a client certificate named client.cer, follow these steps:
1. Generate the client certificate.
\bin\keytool -genkey -alias client-alias -keyalg RSA -keypass changeit
-storepass changeit -keystore keystore.jks
2. Export the generated client certificate into the file client.cer.
\bin\keytool -export -alias client-alias
-storepass changeit -file client.cer -keystore keystore.jks
3. Add the certificate to the trust-store file /domains/domain1/config/cacerts.jks. Run keytool from the directory where you created the keystore and client certificate. Use the following parameters:
\bin\keytool -import -v -trustcacerts
-alias client-alias -file client.cer
-keystore /domains/domain1/config/cacerts.jks
-keypass changeit -storepass changeit
The keytool utility returns this message:
Owner: CN=J2EE Client, OU=Java Web Services, O=Sun, L=Santa Clara, ST=CA, C=US
Issuer: CN=J2EE Client, OU=Java Web Services, O=Sun, L=Santa Clara, ST=CA, C=US
Serial number: 3e39e66a
Valid from: Thu Jan 30 18:58:50 PST 2003 until: Wed Apr 30
19:58:50 PDT 2003
Certificate fingerprints:
MD5: 5A:B0:4C:88:4E:F8:EF:E9:E5:8B:53:BD:D0:AA:8E:5A
SHA1:90:00:36:5B:E0:A7:A2:BD:67:DB:EA:37:B9:61:3E:26:B3:89:46:
32
Trust this certificate? [no]: yes
Certificate was added to keystore
For an example application that uses mutual authentication, see Example: Client-Certificate Authentication over HTTP/SSL with JAX-RPC. For information on verifying that mutual authentication is running, seeVerifying That Mutual Authentication Is Running.
Miscellaneous Commands for Certificates
To check the contents of a keystore that contains a certificate with an alias server-alias, use this command:
keytool -list -keystore keystore.jks -alias server-alias -v
To check the contents of the cacerts file, use this command:
keytool -list -keystore cacerts.jks
Using SSL
An SSL connector is preconfigured for the Application Server. You do not have to configure anything. If you are working with another application server, see its documentation for setting up its SSL connector.
Verifying SSL Support
For testing purposes, and to verify that SSL support has been correctly installed, load the default introduction page with a URL that connects to the port defined in the server deployment descriptor:
https://localhost:8181/
The https in this URL indicates that the browser should be using the SSL protocol. The localhost in this example assumes that you are running the example on your local machine as part of the development process. The 8181 in this example is the secure port that was specified where the SSL connector was created in Using SSL. If you are using a different server or port, modify this value accordingly.
The first time a user loads this application, the New Site Certificate or Security Alert dialog box displays. Select Next to move through the series of dialog boxes, and select Finish when you reach the last dialog box. The certificates will display only the first time. When you accept the certificates, subsequent hits to this site assume that you still trust the content.
Tips on Running SSL
The SSL protocol is designed to be as efficient as securely possible. However, encryption and decryption are computationally expensive processes from a performance standpoint. It is not strictly necessary to run an entire web application over SSL, and it is customary for a developer to decide which pages require a secure connection and which do not. Pages that might require a secure connection include login pages, personal information pages, shopping cart checkouts, or any pages where credit card information could possibly be transmitted. Any page within an application can be requested over a secure socket by simply prefixing the address with https: instead of http:. Any pages that absolutely require a secure connection should check the protocol type associated with the page request and take the appropriate action if https: is not specified.
Using name-based virtual hosts on a secured connection can be problematic. This is a design limitation of the SSL protocol itself. The SSL handshake, where the client browser accepts the server certificate, must occur before the HTTP request is accessed. As a result, the request information containing the virtual host name cannot be determined before authentication, and it is therefore not possible to assign multiple certificates to a single IP address. If all virtual hosts on a single IP address need to authenticate against the same certificate, the addition of multiple virtual hosts should not interfere with normal SSL operations on the server. Be aware, however, that most client browsers will compare the server's domain name against the domain name listed in the certificate, if any (this is applicable primarily to official, CA-signed certificates). If the domain names do not match, these browsers will display a warning to the client. In general, only address-based virtual hosts are commonly used with SSL in a production environment.
Enabling Mutual Authentication over SSL
This section discusses setting up client-side authentication. As mentioned earlier, when both server-side and client-side authentication are enabled, it is called mutual, or two-way, authentication. In client authentication, clients are required to submit certificates that are issued by a certificate authority that you choose to accept. If you regulate it through the application (via the Client-Certificate authentication requirement), the check is performed when the application requires client authentication. You must enter the keystore location and password in the web server configuration file to enable SSL, as discussed in Using SSL.
Here are two ways to enable mutual authentication over SSL:
• PREFERRED: Set the method of authentication to Client-Certificate using deploytool. This enforces mutual authentication by modifying the deployment descriptor of the given application. By enabling client authentication in this way, client authentication is enabled only for a specific resource controlled by the security constraint. Setting client authentication in this way is discussed in Example: Client-Certificate Authentication over HTTP/SSL with JAX-RPC.
• RARELY: Set the clientAuth property in the certificate realm to true. To do this, follow these steps:
a. Start the Application Server if you haven't already done so. Information on starting the Application Server can be found in Starting and Stopping the Application Server.
b. Start the Admin Console. Information on starting the Admin Console can be found in Starting the Admin Console.
c. In the Admin Console tree, expand Configuration, expand Security, then expand Realms, and then select certificate. The certificate realm is used for all transfers over HTTP with SSL.
d. Select Add to add the property of clientAuth to the server. Enter clientAuth in the Name field, and enter true in the Value field.
e. Click Save to save these new properties.
f. Log out of the Admin Console.
When client authentication is enabled in both of these ways, client authentication will be performed twice.
Verifying That Mutual Authentication Is Running
You can verify that mutual authentication is working by obtaining debug messages. This should be done at the client end, and this example shows how to pass a system property in targets.xml so thattargets.xml forks a client with javax.net.debug in its system properties, which could be added in a file such as /j2eetutorial14/examples/security/common/targets.xml.
To enable debug messages for SSL mutual authentication, pass the system property javax.net.debug=ssl,handshake, which will provide information on whether or not mutual authentication is working. The following example modifies the run-mutualauth-client target from the /j2eetutorial14/examples/security/common/targets.xml file by adding sysproperty as shown in bold:
description="Runs a client with mutual authentication over
SSL">



value="${key.store}" />
value="${key.store.password}"/>





XML and Web Services Security
Security can be applied to web services at both the transport-level and the message-level.
In message security, security information travels along with the web services message. WSS in the SOAP layer is the use of XML Encryption and XML Digital Signatures to secure SOAP messages. WSS profiles the use of various security tokens including X.509 certificates, SAML assertions, and username/password tokens to achieve this.
Message layer security differs from transport layer security in that message layer security can be used to decouple message protection from message transport so that messages remain protected after transmission, regardless of how many hops they travel on.
Message-level security is discussed in the following documentation:
• Configuring Message Security chapter of the Application Server Administration Guide. This chapter is for system administrators or others attempting to set up the Application Server for message security.
• Securing Applications chapter of the Application Server Developers' Guide. This chapter is for developers, assemblers, and deployers attempting to implement message security at the application or method level.
Transport-level security is discussed in the following example sections:
• Transport-Level Security
• Example: Basic Authentication with JAX-RPC
• Example: Client-Certificate Authentication over HTTP/SSL with JAX-RPC
Transport-Level Security
Authentication verifies the identity of a user, device, or other entity in a computer system, usually as a prerequisite to allowing access to resources in a system. There are several ways in which this can happen. The following ways are discussed in this section:
One approach is that a user authentication method can be defined for an application in its deployment descriptor. When a user authentication method is specified for an application, the web container activates the specified authentication mechanism when you attempt to access a protected resource. The options for user authentication methods are discussed in Understanding Login Authentication. The example application discussed in Example: Basic Authentication with JAX-RPC shows how to add basic authentication to a JAX-RPC application. The example discussed in Example: Client-Certificate Authentication over HTTP/SSL with JAX-RPC shows how to add client-certificate, or mutual, authentication to a JAX-RPC application.
A second approach is that a transport guarantee can be defined for an application in its deployment descriptor. Use this method to run over an SSL-protected session and ensure that all message content is protected for confidentiality. The options for transport guarantees are discussed in Specifying a Secure Connection. For an example application that demonstrates running over an SSL-protected session, seeExample: Client-Certificate Authentication over HTTP/SSL with JAX-RPC.
When running over an SSL-protected session, the server and client can authenticate one another and negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data.
SSL technology allows web browsers and web servers to communicate over a secure connection. In this secure connection, the data is encrypted before being sent, and then is decrypted upon receipt and before processing. Both the browser and the server encrypt all traffic before sending any data. For more information, see What Is Secure Socket Layer Technology?.
Digital certificates are necessary when running HTTP over SSL (HTTPS). The HTTPS service of most web servers will not run unless a digital certificate has been installed. Digital certificates have already been created for the Application Server.
Example: Basic Authentication with JAX-RPC
In this section, we discuss how to configure JAX-RPC-based web service applications for HTTP basic authentication. With HTTP basic authentication, the web server authenticates a user by using the user name and password obtained from the web client. If the topic of authentication is new to you, please refer to the section titled Understanding Login Authentication. For an explanation of how basic authentication works, seeFigure 32-2.
For this tutorial, we begin with the example application in /j2eetutorial14/examples/jaxrpc/staticstub/ and /j2eetutorial14/examples/jaxrpc/helloservice/ and add user name and password authentication. The resulting application can be found in the directories /j2eetutorial14/examples/security/basicauth/ and/j2eetutorial14/examples/security/basicauthclient/.
In general, the following steps are necessary to add basic authentication to a JAX-RPC application. In the example application included with this tutorial, many of these steps have been completed for you and are listed here to show what needs to be done should you wish to create a similar application.
1. Complete the JAX-RPC application as described in Creating a Simple Web Service and Client with JAX-RPC.
2. If the default port value is changed from 8080, see Setting the Port for information on updating the example files to reflect this change. The WAR files mentioned in this tutorial will not work if the port has been changed.
3. Edit the /j2eetutorial14/examples/common/build.properties file and the admin-password.txt file. These files need to be modified because the properties in these file are specific to your installation. See Building the Examples for information on which properties need to be set in which files. While you are looking at these files, note the value entered for admin.user and check the fileadmin-password.txt for the value of the admin password.
4. Add a user with the name that matches the value set in the build.properties file (admin) for the admin.user property and a password that matches the value set in the admin-password.txt file for theAS_ADMIN_PASSWORD property to the file realm. Refer to the section Managing Users, for instructions for doing this.
5. Set security properties in the client code. For the example application, this step has been completed. The code for this example is shown in Setting Security Properties in the Client Code.
6. Add the appropriate security elements using deploytool. For this example, the security elements are added in the packaging and deployment phase. Refer to Adding Basic Authentication Using deploytoolfor more information.
7. Build, package, deploy, and run the web service. You will use the asant tool to compile the client and service, and deploytool to package and deploy the service. Instructions for this example can be found inBuilding, Packaging, Deploying, and Running the Example for Basic Authentication.
Setting Security Properties in the Client Code
The source code for the client is in the HelloClient.java file of the /j2eetutorial14/examples/security/basicauthclient/src/ directory. For basic authentication, the client code must setusername and password properties. The username and password properties correspond to the admin group (which includes the user name and password combination entered during installation) and the role ofadmin, which is provided in the application deployment descriptor as an authorized role for secure transactions. (See Setting Up Security Roles.)
The client sets the aforementioned security properties as shown in the following code. The code in bold is the code that has been added from the original version of the jaxrpc/staticstub example application.
package basicauthclient;

import javax.xml.rpc.Stub;

public class HelloClient {

public static void main(String[] args) {

if (args.length !=3) {
System.out.println("HelloClient Error: Wrong
number of runtime arguments!");
System.exit(1);
}

String username=args[0];
String password=args[1];
String endpointAddress=args[2];

// print to display for verification purposes
System.out.println("username: " + username);
System.out.println("password: " + password);
System.out.println("Endpoint address = " +
endpointAddress);


try {
Stub stub = createProxy();
stub._setProperty(
javax.xml.rpc.Stub.USERNAME_PROPERTY,
username);
stub._setProperty(
javax.xml.rpc.Stub.PASSWORD_PROPERTY,
password);
stub._setProperty
(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
endpointAddress);

HelloIF hello = (HelloIF)stub;
System.out.println(hello.sayHello("Duke (secure)"));
} catch (Exception ex) {
ex.printStackTrace();
}
}

private static Stub createProxy() {
// Note: MyHelloService_Impl is implementation-specific.
return (Stub)(new
MyHelloService_Impl().getHelloIFPort());
}
}
Read Static Stub Client for more information about JAX-RPC static stub clients.
Building, Packaging, Deploying, and Running the Example for Basic Authentication
To build, package, deploy, and run the security/basicauth example using basic authentication, follow these steps.
Building the Basic Authentication Service
1. Set up your system for running the tutorial examples if you haven't done so already by following the instructions in Building the Examples.
2. From a terminal window or command prompt, go to the /j2eetutorial14/examples/security/basicauth/ directory.
3. Build the JAX-RPC service by entering the following at the terminal window or command prompt in the basicauth/ directory (this and the following steps that use asant assume that you have the executable for asant in your path; if not, you will need to provide the fully qualified path to the executable). This command runs the target named build in the build.xml file.
asant build
Packaging the Basic Authentication Service
You can package the basic authentication example using asant or deploytool, or you can just open the WAR file located in the /j2eetutorial14/examples/security/provided-wars/basicauth.war file.
To package the example using asant, run the following command from the /basicauth directory:
asant create-war
To package the example using deploytool, follow the steps described in Packaging and Deploying the Service with deploytool and Specifying the Endpoint Address. When following these steps, replace the following:
• The path to the example should be replaced with /j2eetutorial14/examples/security/basicauth/.
• Replace helloservice with basicauth throughout.
• Use /basicauth-jaxrpc for the Context Root field.
Adding Basic Authentication Using deploytool
For HTTP basic authentication, the application deployment descriptor, web.xml, includes the information on who is authorized to access the application, which URL patterns and HTTP methods are protected, and what type of user authentication method this application uses. This information is added to the deployment descriptor using deploytool. Its contents are discussed in more detail in Web-Tier Security and in the Java Servlet specification, which can be browsed or downloaded online at http://java.sun.com/products/servlet/.
1. If you packaged the example using deploytool, select the basic authentication example, BasicAuth, in the deploytool tree. If you packaged the example using asant, open the generated WAR file (basicauth.war) in deploytool and then select the basic authentication example.
2. Select the Security tabbed pane.
3. Select Basic in the User Authentication Method field.
4. Select Add Constraints to add a security constraint.
5. Select Add Collections to add a web resource collection.
6. Select the web resource collection from the list, and then select Edit Collections.
7. Select Add URL Pattern. Enter /hello in the text field. Click OK.
8. Select the HTTP GET and POST methods.
9. Click OK to close the Edit Contents dialog box.
10. Select Edit Roles on the Security tabbed pane to specify an authorized role for this application.
11. Click Edit Roles in the Authorized Roles dialog box to add an authorized user to this application. Click Add in the Edit Roles dialog box and add the Name of admin. Click OK to close this dialog box.
12. Select admin under the Roles In field, and then click Add to add it to the list of authorized roles for this application. Click OK to close the dialog box.
Note that the Authorized Roles list specifies admin, a group that was specified during installation. To map this role to a user, follow these steps.
1. Select the General tabbed pane.
2. Click the Sun-specific Settings button.
3. In the Sun-specific Settings dialog box, select User to Role Mappings from the View list.
4. Select admin from the list of roles.
5. Click the Edit button under the Users box.
6. Select admin from the Available Users list, and then click the Add button to map the role of admin (defined for the application) to the user named admin (defined for the Application Server). Click OK.
________________________________________
Note: If you don't see the list of users or groups that you defined using the Admin Console, connect to the Admin Server by double-clicking localhost:4848 in the deploytool tree and entering your admin user name and password. If this is not the current target server, change to this server by selecting it and then selecting File Set Current Target Server.
________________________________________
1. Click Close to return to the General tabbed pane.
2. Select Save from the File menu to save these settings.
Deploying the Basic Authentication Service
To deploy the example using asant, run the following command:
asant deploy-war
To deploy the example using deploytool, follow these steps:
1. Select the BasicAuth application in the deploytool tree. Then select Tools Deploy.
2. Make sure the server is correct, localhost:4848 by default.
3. Enter your admin user name and password.
4. Click OK.
5. Click the Close button after the messages indicating successful completion are finished.
You can view the WSDL file of the deployed service by requesting the URL http://localhost:8080/basicauth-jaxrpc/hello?WSDL in a web browser.
Building and Running the Basic Authentication Client
To build the JAX-RPC client, do the following:
1. Enter the following command at the terminal window or command prompt in the basicauthclient/ directory:
asant build
2. Run the JAX-RPC client by entering the following at the terminal window or command prompt in the basicauthclient/ directory:
asant run
The client should display the following output:
Buildfile: build.xml

run-secure-client:
[java] username: your_name
[java] password: your_pwd
[java] Endpoint address = http://localhost:8080/basicauth-
jaxrpc/hello
[java] Hello Duke (secure)

BUILD SUCCESSFUL
Example: Client-Certificate Authentication over HTTP/SSL with JAX-RPC
In this section, we discuss how to configure a simple JAX-RPC-based web service application for client-certificate authentication over HTTP/SSL. Client-certificate authentication uses HTTP over SSL, in which the server and, optionally, the client authenticate one another using public key certificates. If the topic of authentication is new to you, please refer to the section titled Understanding Login Authentication. For more information on how client-certificate authentication works, see Figure 32-4.
This example application starts with the example application in /j2eetutorial14/examples/jaxrpc/helloservice/ and adds both client and server authentication to the example. In SSL certificate-based basic authentication, the server presents its certificate to the client, and the client authenticates itself to the server by sending its user name and password. This type of authentication is sometimes called server authentication. Mutual authentication adds the dimension of client authentication. For mutual authentication, we need both the client's identity, as contained in a client certificate, and the server's identity, as contained in a server certificate inside a keystore file (keystore.jks). We also need both of these identities to be contained in a mutual trust-store (cacerts.jks) where they can be verified.
To add mutual authentication to a basic JAX-RPC service, complete the following steps. In the example application included with this tutorial, many of these steps have been completed for you and are listed here to show what needs to be done should you wish to create a similar application.
1. Complete the JAX-RPC application as described in Creating a Simple Web Service and Client with JAX-RPC.
2. Create the appropriate certificates and keystores. For this example, the certificates and keystores are created for the server as a generic localhost and are included with the Application Server. See the section Keystores and Trust-Stores in the Mutual Authentication Example for a discussion of how to create the client certificates for this example.
3. If the port value is changed from the default of localhost:8080, see Setting the Port for information on updating the example files to reflect this change. The WAR files mentioned in this tutorial will not work if the port has been changed.
4. Edit the build.properties files to add the location and password to the trust-store, and other properties, as appropriate. For a discussion of the modifications that need to be made to build.properties, see Modifying the Build Properties. While you are looking at this file, note the value entered for admin.user. Also note the value for the admin password as specified in the file admin-password.txt in the field AS_ADMIN_PASSWORD.
5. Add a user to the file realm with the name that matches the value set in the build.properties file (admin) for the admin.user property and a password that matches the value set in the admin-password.txt file for the AS_ADMIN_PASSWORD property. Refer to the section Managing Users, for instructions for doing this.
6. Set security properties in the client code. For the example application, this step has been completed. For a discussion of the security properties that have been set in HelloClient, see Setting Security Properties in the Client Code.
7. Add the appropriate security elements using deploytool. The security elements are discussed in the section Enabling Client-Certificate Authentication for the Mutual Authentication Example.
8. Build, package, and deploy the service, deploy the server, and then build and run the client (see Building, Packaging, Deploying, and Running the Mutual Authentication Example). You will use the asant tool to compile the client and service and to run the client. You will use deploytool to package and deploy the service.
Keystores and Trust-Stores in the Mutual Authentication Example
In this example, the keystore file (keystore.jks) and the trust-store file (cacerts.jks) have been created for the server as a generic localhost and are included with the Application Server in the directory/domains/domain1/config/. You must follow the instructions in Creating a Client Certificate for Mutual Authentication to create a client certificate and add it to the existing trust-store. You must create the client certificates in the directory /domains/domain1/config/, and you must restart the Application Server for the client certificate to be accessed by the application.
Modifying the Build Properties
To build and run the application with mutual authentication, we have set up the example so that some of the values are passed to the application from various build.properties files.
To run any of the examples, you must modify the build.properties file located in the /j2eetutorial14/examples/common/ directory to provide your admin password and the location where the Application Server is installed. If you need more information, see Building the Examples.
For this example, the build.properties file that is specific to this application, /j2eetutorial14/examples/security/common/build.properties, has been modified for you. This file provides specific information about the JAX-RPC examples to the asant targets we will be running later. This information concerns the location of the keystore and trust-store files and their associated passwords.
Make sure that the following properties exist and are correctly defined.
trust.store=${j2ee.home}/domains/domain1/config/cacerts.jks
trust.store.password=changeit
key.store=${j2ee.home}/domains/domain1/config/keystore.jks
key.store.password=changeit
Setting Security Properties in the Client Code
The source code for the client is in the HelloClient.java file of the /j2eetutorial14/examples/security/mutualauthclient/src/ directory. For mutual authentication, the client code must set several security-related properties. These values are passed into the client code when the asant build and run tasks are executed.
• trustStore: The value of the trustStore property is the fully qualified name of the trust-store file: /domains/domain1/config/cacerts.jks.
• trustStorePassword: The trustStorePassword property is the password of the trust-store. The default value of this password is changeit.
• keyStore: The value of the keyStore property is the fully qualified name of the keystore file: /domains/domain1/config/keystore.jks
• keyStorePassword: The keyStorePassword property is the password of the keystore. The default value of this password is changeit.
• ENDPOINT_ADDRESS_PROPERTY: The ENDPOINT_ADDRESS_PROPERTY property sets the endpoint address that the stub uses to access the service.
The client sets the aforementioned security properties as shown in the following code. The code in bold is the code that has been added from the original version of the jaxrpc/staticstub example application.
package mutualauthclient;

import javax.xml.rpc.Stub;

public class HelloClient {

public static void main(String[] args) {

if (args.length !=5) {
System.out.println("HelloClient Error: Need 5
runtime arguments!");
System.exit(1);
}

String keyStore=args[0];
String keyStorePassword=args[1];
String trustStore=args[2];
String trustStorePassword=args[3];
String endpointAddress=args[4];


// print to display for verification purposes
System.out.println("keystore: " + keyStore);
System.out.println("keystorePassword: " +
keyStorePassword);
System.out.println("trustStore: " + trustStore);
System.out.println("trustStorePassword: " +
trustStorePassword);
System.out.println("Endpoint address: " +
endpointAddress);

try {
Stub stub = createProxy();
System.setProperty("javax.net.ssl.keyStore",
keyStore);
System.setProperty("javax.net.ssl.keyStorePassword",
keyStorePassword);
System.setProperty("javax.net.ssl.trustStore",
trustStore);
System.setProperty("javax.net.ssl.trustStorePassword",
trustStorePassword);
stub._setProperty(
javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
endpointAddress);

HelloIF hello = (HelloIF)stub;
System.out.println(hello.sayHello("Duke! ( secure!"));
} catch (Exception ex) {
ex.printStackTrace();
}
}

private static Stub createProxy() {
// Note: MyHelloService_Impl is implementation-specific.
return (Stub)(new
MySecureHelloService_Impl().getHelloIFPort());
}
}
Enabling Client-Certificate Authentication for the Mutual Authentication Example
The two ways of implementing client authentication are discussed in Enabling Mutual Authentication over SSL. You can set client authentication for all applications (by specifying this in the deployment descriptor for the server) or for only a single application (by specifying this in the deployment descriptor for the application). For this example, we are enabling client authentication for this application only, so we specify the login authentication method as being Client-Certificate. The steps for adding client-certificate authentication are shown in Adding Client-Certificate Authentication Using deploytool.
For more information on login configuration options, read Understanding Login Authentication.
The user authentication method specifies a client-certificate method of authentication in this example. For this authentication to run over SSL, you must also specify which type of transport guarantee to use. For this example, we have chosen CONFIDENTIAL, which is specified in the Network Security Requirement field on the Security tabbed pane in deploytool.
For more information on this type of constraint, read Specifying a Secure Connection.
Building, Packaging, Deploying, and Running the Mutual Authentication Example
To build, deploy, and run the JAX-RPC service example with mutual authentication, follow these steps.
Building the Mutual Authentication Example
To compile the application files and copy them to the correct directories, run the asant build task. More information on what happens when the build task is called can be found in Building the Service.
1. If you haven't already done so, follow these steps for setting up the example.
o Using SSL
o Building the Examples
2. Go to the /j2eetutorial14/examples/security/mutualauth/ directory.
3. Build the JAX-RPC service by entering the following at the terminal window or command prompt in the mutualauth/ directory (this and the following steps that use asant assume that you have the executable for asant in your path; if not, you will need to provide the fully qualified path to the asant executable):
asant build
4. Change to the directory /j2eetutorial14/examples/security/mutualauthclient/.
5. Build the JAX-RPC client by entering the following at the terminal window or command prompt:
asant build
Packaging the Mutual Authentication Example
You can package the mutual authentication example using asant or deploytool, or you can open the WAR file located in the /j2eetutorial14/examples/security/provided-wars/mutualauth.war file.
To package the example using asant, run the following command and then skip to the section titled Deploying the Mutual Authentication Example:
asant create-war
To package the example using deploytool, follow the steps described in Packaging and Deploying the Service with deploytool and Specifying the Endpoint Address. When following these steps, replace the following:
• The path to the example should be replaced with /j2eetutorial14/examples/security/mutualauth/.
• Replace helloservice with mutualauth throughout.
• Use /mutualauth-jaxrpc for the Context Root field.
Adding Client-Certificate Authentication Using deploytool
For HTTP client-certificate authentication, the application deployment descriptor, web.xml, includes the information on who is authorized to access the application, which URL patterns and HTTP methods are protected, and what type of user authentication method this application uses. This information is added to the deployment descriptor using deploytool, and its contents are discussed in more detail in Web-Tier Security and in the Java Servlet specification, which can be browsed or downloaded online at http://java.sun.com/products/servlet/.
1. If you packaged the example using deploytool, select the MutualAuth example in the deploytool tree. If you packaged the example using asant, you can ignore this section as these steps were completed by the asant task.
2. Select the Security tabbed pane.
3. Select Client Certificate in the User Authentication Method field.
4. Select Add Constraints to add a security constraint.
5. Select Add Collections to add a web resource collection.
6. Select the web resource collection from the list, and then select Edit Collections.
7. Select Add URL Pattern. Enter /hello in the text field. Click OK.
8. Select the HTTP GET and POST methods.
9. Click OK to close the Edit Contents dialog box.
10. Select CONFIDENTIAL under Network Security Requirement so that the application requires HTTP/SSL.
11. Select Save from the File menu to save these settings.
Deploying the Mutual Authentication Example
To deploy the example using asant, run the following command:
asant deploy-war
To deploy the application using deploytool, follow these steps:
1. Deploy the JAX-RPC service by selecting the MutualAuth example in the deploytool tree. Then select Tools Deploy.
2. Make sure the server is correct. By default, this will be localhost:4848.
3. Enter your admin user name and password.
4. Click OK.
5. Click the Close button after the messages indicating successful completion are finished.
Running the Mutual Authentication Example
Enter the following command from the mutualauthclient/ directory at the terminal window or command prompt to run the JAX-RPC client:
asant run
The client should display the following output:
Buildfile: build.xml

run-mutualauth-client:
[java] keystore: /domains/domain1/config/
keystore.jks
[java] keystorePassword: changeit
[java] trustStore: /domains/domain1/config/
cacerts.jks
[java] trustStorePassword: changeit
[java] Endpoint address = https://localhost:8181/
mutualauth-jaxrpc/hello

[java] Hello Duke (secure)

run:

BUILD SUCCESSFUL