webaccess on apache

Installing GroupWise WebAccess with
Apache/Tomcat on NetWare
By: Jim Michael, Novell Support Connection Sysop
Introduction
This guide describes the necessary steps to get GroupWise WebAccess running with
Apache/Tomcat on NetWare 5.1. Because Tomcat is not a “supported” servlet engine
for WebAccess it is largely a manual configuration, but straightforward nonetheless.
The following instructions assume no knowledge of Tomcat or Apache, and will guide
you step-by-step through getting everything installed. If you are already familiar with
Apache/Tomcat and have them installed and working on your NetWare server, you can
skip forward to the Install WebAccess section. The basic steps are as follows:
1)
2)
3)
4)
5)
Upgrade the NetWare JVM if necessary
Install Tomcat and test
Install Apache, integrate it with Tomcat and test
Install and configure the WebAccess servlets
Run it!
The remainder of this guide will detail each step, but before we dive in I must alert the
reader to one caveat regarding WebAccess on Tomcat: At the time of this writing,
WebAccess on Tomcat is unsupported by Novell, so use it at your own risk. That said, it
is quite stable in my experience.
To avoid confusion, I will be using the following conventions throughout this
guide:
<tomcat> in a path indicates the Tomcat “root”. That is, the directory off of sys:
that Tomcat was extracted to. <server> in a URL indicates either your web
server’s IP address or DNS host name, whichever is appropriate, eg
http://<server> could be http://www.yourcompany.com or http://192.168.1.50.
Upgrade the JVM
Running WebAccess on Tomcat requires the NetWare JVM version 1.2.2 or later, and
has been sucessfully tested with the 1.2.2 through 1.3.1 JVMs. Unfortunately, this
brings up another potential caveat: Upgrading the JVM from 1.1.7x to a newer version
may cause other NetWare applications that rely on Java to malfunction. For example,
ZENworks for Desktops and ZENworks for Servers seem to be particularly sensitive to
the JVM version they run against. Consequently, I don’t recommend installing
WebAccess with Apache/Tomcat to a server on which you have other Java-dependent
applications running without first testing that configuration thoroughly in a nonproduction environment.
1
If you need to upgrade the JVM, download it from http://support.novell.com.
With any of the available NetWare JVMs, installation is as simple as stopping the
current JVM by typing
java –exit
at the server console, then running the JVMxxx.EXE from a Windows workstation and
following the prompts. After the installation completes, type
java
to load the new JVM. Verify the version by typing
modules java
at the console.
Install and Test Tomcat
Tomcat is developed under the umbrella of the “Jakarta” project, which encompasses
many Java-based projects, and is the reference implementation of the Java Servlet and
JavaServer Pages technologies. At the time of this writing Tomcat 3.x is at release
version 3.3.1, and can be downloaded from
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1/bin/
Note that Tomcat version 4.x is also released. This is a completely different
animal than the 3.x codebase, and this document does not cover running
WebAccess on the 4.x versions at all.
Download jakarta-tomcat-3.3.1.zip. If there is a later released 3.x version of Tomcat
on the site, download that. Beware that the Apache and Jakarta web sites have been
known to change their structure periodically. If you can’t get to the above URL, search
your way through http://jakarta.apache.org to find the Tomcat binaries. Oh, and while
you’re at the site, go ahead and download MOD_JK.NLM from
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1/bin/netware/i386/
This is the connector that allows Tomcat to plug into the Apache web server, which we
will cover in the next section.
2
Expand jakarta-tomcat-3.3.1.zip (or whatever version you downloaded) to the root of
the SYS: volume on your NetWare server. Assuming you are installing version 3.3.1, the
file should expand to the following directory structure:
sys:\jakarta-tomcat-3.3.1
\bin
\conf
\docs
\lib
\logs
\modules
\native
\webapps
The \bin directory contains Tomcat startup scripts for Unix and Windows. Since none of
these apply to NetWare, it can be safely ignored.
The \conf directory contains Tomcat configuration files as well as Apache and NES
integration files.
The \docs directory contains Tomcat documentation, and can be safely ignored for the
purposes of running WebAccess.
The \lib directory contains Tomcat .jar files critical to its operation.
The \logs directory contains log files that Tomcat writes out during operation. Tomcat
logging is completely configurable via the \conf files.
The \native directory contains Tomcat web server connector source code, and can be
ignored for the purposes of running WebAccess.
The \webapps directory is where all the action takes place. This is where the
WebAccess servlets will ultimately be installed (to a “container” beneath this directory
to be precise.)
Configure Tomcat
The first order of business is to create a Tomcat startup file, in the form of the familiar
NetWare “ncf” file. Start by creating sys:\system\tomcat.ncf in any text editor, and
add the following commands:
envset TOMCAT_HOME=<tomcat>
envset TOMCAT_CLASSPATH=$TOMCAT_HOME\lib\tomcat.jar
java -nsac -snTomcat -envCWD=$TOMCAT_HOME -classpath $TOMCAT_CLASSPATH Dtomcat.home=$TOMCAT_HOME org.apache.tomcat.startup.Main -f
$TOMCAT_HOME/conf/server.xml %1
You will need to modify the TOMCAT_HOME variable to reflect the correct Tomcat
path. In our example install, this is sys:\jakarta-tomcat-3.3.1. The envset commands
should each be on a single line, not wrapped as they may appear in this text. The Java
load command should be on a single line as well.
This startup file tells Tomcat where to find its class libraries, and loads it into the JVM
with its own NetWare console screen titled “Tomcat.” This will give Tomcat its own
3
home on the server console, and will keep runtime messages from cluttering up the
main console. You should now be able to load Tomcat with the following commands:
java
tomcat
Wondering how to stop or restart Tomcat? This can be done two ways.
To unload just the Tomcat engine use the following command (assuming
your startup file is named tomcat.ncf):
tomcat -stop
To unload Tomcat along with all other Java applications and the JVM,
use the following command:
java –exit
Assuming you did not make any typos in the tomcat.ncf file, the server should look
something like this:
Note the bottom two lines. These indicate that Tomcat is listening for HTTP requests
on port 8080, and for “Ajp12” requests on 8007 (you may also see a line showing an
“Ajp13ConnectionHandler” on port 8009, depending on what version of Tomcat you
installed.) What is Ajp12/13? This is the “Apache Jakarta protocol” that allows Apache
and Tomcat to communicate. These ports can be changed via the Tomcat configuration
files, but the defaults should work for most installations.
4
BorderManager admins will certainly recognize 8080 as the default port for forward
proxy on BorderManager servers. If for some reason you’re going to run WebAccess
with Apache/Tomcat on a BorderManager box, you will need to change Tomcat’s
HTTP port. This is easily done by opening the <tomcat>\conf\server.xml file in a text
editor and searching for the “Connectors” section. Simply change
Http10Interceptor port="8080” tag to a port that doesn’t conflict with any
other services and restart Tomcat.
Alternatively, you can simple disable the HTTP server within Tomcat altogether
(recommended). This HTTP server is not a robust server like Apache, and is
normally only used for testing Tomcat when its not integrated with a “real” web
server such as Apache, and its not necessary at all for WebAccess functionality.
To disable the HTTP server in Tomcat, edit <tomcat>\conf\server.xml and go to the
“Connectors” section and simply comment out the entire HTTP connector section.
Specifically, add <!-- just prior to the new http adapter. Attributes line,
and add --> just after the closing “Http10Interceptor” tag. Save the file and
restart Tomcat, and you should see that the line indicating Tomcat is listening on
8080 is gone.
At this point Tomcat is running, waiting for requests. To find out if it works, fire up
your browser and point it at
http://<server>:8080
Assuming you did not yet disable HTTP in Tomcat, you should see a page similar to this
5
If you successfully get to this page, congratulations! You now have a fully-functioning
Java server running on NetWare. For the curious, go ahead and try out the JSP and
Servlet examples. They are very basic examples of what can be done with a Java
application server. For those of us that just want to get WebAccess running, let’s move
on…
6
Install Apache
The NetWare version of Apache can be found at
http://httpd.apache.org/dist/httpd/binaries/netware/
At the time of this writing, the current version is 1.3.24, found in
apache_1.3.24_netware-mp.zip. If there is a newer version, download that. The
Apache web site has been known to unexpectedly change structure on occasion, so if
you don’t find the NetWare binaries in this location, go to http://www.apache.org/
and search around for the new location of the binaries.
Like Tomcat, there is no installation routine for Apache. Simply extract the zip file to
the root of the SYS: volume, which should create the following directory structure:
sys:\apache
\cgi-bin
\conf
\htdocs
\icons
\logs
\modules
The \cgi-bin directory is where CGI scripts to be executed by the web server are
placed. It can be ignored for the purposes of running WebAccess
The \conf directory contains Apache configuration files.
The \htdocs directory is the default web document root directory for Apache. This is
where we will install the WebAccess static content shortly.
The \icons directory is a standard location used to map to image files. It can be ignored
for the purposes of running WebAccess.
The \logs directory contains access logs Apache writes out during operation.
The \modules directory contains Apache “modules”, which are pieces of code that
extend the functionality of the web server. This is where the Tomcat plug-in will be
installed shortly.
Getting Apache configured and running is surprisingly simple. Open
sys:\apache\conf\httpd.conf in a text editor such as WordPad. While the sheer number
of configuration parameters in this file may seem daunting, only a few are necessary
for our purposes.
1) Search for the ServerRoot "sys:/apache" line. If you extracted Apache to the
default location, no changes are necessary. If you installed Apache to some
other location, modify this line to reflect the correct path.
2) Search for the ServerName line. Edit this to reflect either your server’s DNS
host name or IP address.
3) Save the httpd.conf file and exit
7
4) Add sys:\apache (or whatever location you installed Apache to) to the search
path. At the NetWare console, type
SEARCH ADD SYS:\APACHE
Add this to your sys:\system\autoexec.ncf file so that the search mapping is
added every time the server restarts.
At this point, typing
apache
at the NetWare console should result in a screen similar to this:
While this screen is admittedly sparse, it does tell us that Apache is running and
listening on port 80. Load up a browser and point it at http://<server>. You should
see a page similar to this:
8
You now have Apache successfully running on NetWare. Any content you place under
the \apache\htdocs directory structure can be served up (assuming you did not change
the default document location in httpd.conf). All that’s left to do is get Tomcat
plugged into Apache, and install the WebAccess servlets.
Integrate Tomcat and Apache
Start by copying mod_jk.nlm to the \apache\modules directory. If you did not download
this module previously, it can be found at
http://jakarta.apache.org
in the Tomcat binaries section. By “integrating” Apache with Tomcat, we are talking
about configuring Apache to hand-off requests for servlets or JSP pages to Tomcat,
rather than trying to render this content itself. This is accomplished via URL mappings
that Apache must be made aware of, which is easily done by adding a single command
to the Apache \conf\httpd.conf file:
Include "sys:/<tomcat>/conf/jk/mod_jk.conf"
This line can be added to the very end of the httpd.conf file, and references
“mod_jk.conf” in the Tomcat /jk/conf directory. This file contains the necessary
module load commands and servlet mappings to let Apache know how to handle servlet
and JSP requests. Save the httpd.conf file.
Now open sys:/<tomcat>/jk/conf/mod_jk.conf. Change the LoadModule line to:
LoadModule jk_module modules/mod_jk.nlm
Change the JkWorkersFile line to:
JkWorkersFile sys:/<tomcat>/jk/conf/workers.properties
Change all “ajp12” text to “ajp13”. The reason for this will be explained in the Secure
WebAccess section.
You may have noticed the mod_jk.conf file in the \auto directory, and
wonder why we don’t use that. This file is automatically generated by
Tomcat each time it starts, and Tomcat makes a “best guess” as to which
mappings will be necessary for Apache based on its servlet definitions.
However, using this file can be limiting for doing other things like SSL
(which we will cover later.) In addition, since this file gets regenerated
every time Tomcat starts, its impossible to customize the settings as they
will be overritten at the next reboot, thus I like to avoid the auto-generated
file altogether.
At this point, save the mod_jk.conf file, and restart the web server by typing the
following commands at the server:
unload apache
load apache
9
If all goes well, you should see a screen similar to this:
In addition to the wealth of information provided by the previous Apache console <g>,
we can now see a line showing that Apache has loaded the MOD_JK.NLM module,
indicating that Tomcat is successfully “plugged in” to Apache. To give it a test run,
point your browser at
http://<server>/servlet/SnoopServlet (case is important!)
10
You should see a screen similar to this:
While this page shows some interesting things, the important part is that we’ve
successfully pointed our browser at Apache and requested a servlet (SnoopServlet is
included as an example with Tomcat). Apache handed that request off to Tomcat,
which ran the servlet and passed the resulting HTML back to Apache, which then
returned it to the browser. Whew!
To recap, we now have a functioning web server, integrated with a functioning Java
application server. Now all that’s left is to install and configure the WebAccess servlets
into this environment.
Install WebAccess
As was mentioned at the beginning of this guide, getting WebAccess working with
Apache and Tomcat is largely a manual configuration. Since the installation routine
doesn’t “know” how to install WebAccess to run on Apache/Tomcat, we have to trick it
a little bit here and there. The first step is to start the WebAccess installation by
running
<GroupWise SDD>\software\internet\webaccess\setup.exe
Click through the prompts and select the components of WebAccess you wish to install.
We will choose all three components
11
Click next to bring up the following dialog
Select the appropriate agent OS and installation path. We will be installing the agent
on NetWare in this example. Click Next.
12
On this screen, choose either the IP address or DNS host name of the server. Click Next.
Here we specify the path to the GroupWise domain we’re installing the WebAccess
agent to, as well as the gateway name. Since WebAccess is being installed to a
NetWare server named WEB in this example, I’ll call the gateway directory WA60WEB.
Click Next. If you get a message stating that the directory does not exist, click Yes to
have the installation create it for you.
13
This screen prompts for the name of the WebAccess Agent object to be created in NDS.
We will accept the default, which is the same as the gateway directory name. Click
Next.
In this dialog, enter a NDS username and password that has full file rights to the
GroupWise domain directory. It is recommended that you create a specific NDS user for
this purpose. Click Next.
14
This dialog allows you to enter a username and password to enable HTTP access to the
WebAccess agent. This is an arbitrary userID that is not tied to a GroupWise or NDS
userID. Click Next.
This dialog allows you to enable WebPublisher, and to provide a GroupWise account
and password that will be used for publishing documents. In this example we will
15
enable WebPublisher and specify the Mailbox ID and password for the GroupWise user
“webpublisher.” Click Next.
This dialog allows us to choose the libraries we want to be made available via
WebPublisher. For this example we will choose all libraries in the system. Click Next.
16
This dialog shows a summary of all data that has been entered thus far. If everything
looks OK, click Next.
Up to this point, the WebAccess install has been completely typical, but now we start
to get into the “trick” portion of the install. As was previously mentioned, the
installation routine has no knowledge of Apache/Tomcat on NetWare, so none of the
17
available web server options truly apply. Instead, we must choose the closest “fit” and
configure manually from there.
For our purposes, the best installation option is the Apache Web Server for UNIX
Solaris. This works well because it is the only web server choice that doesn’t attempt
to automate the installation of the WebAccess servlets and static content. Select
Apache Web Server for UNIX Solaris, and enter the path to a temporary directory on
the NetWare server. This directory must be created manually as the installation won’t
do it. In this example, we’re installing to the L:\wa-install directory (drive L: is mapped
to the sys volume of the NetWare server we installed Apache/Tomcat to.)
In this dialog, enter the web server’s IP address or DNS host name, and whether the
server uses SSL or not. Click Next. (Note: Selecting “uses SSL” has nothing to do with
being able to access WebAccess via https! The setting only effects the web clipping
application for WebAccess via Palm devices.)
18
This dialog shows a final summary of all information entered thus far, and what options
will be installed. Click Next to perform the installation.
After the install copies the necessary files and creates the WebAccess objects in NDS,
this dialog should appear. Click Next, then Finish to exit the installation program.
19
Configure WebAccess
At this point, you should have a new gateway object in NDS, a new gateway directory
under \<GroupWise domain>\wpgate, and seven files sitting in the temporary install
directory you created on the web server, in our case sys:\wa-install.
Four of these files are “tar” archives, typically used on Unix/Linux systems, but
Windows programs such as WinZip have no trouble dealing with them. If you cannot
extract a tar file on your system, don’t panic. You can find the same files in ZIP format
under
<GroupWise SDD>\software\internet\webaccess\other.
Extract the various files as follows:
1) Extract webaccess.tar (or zip) to the root of the NetWare server. This will
create the following directory structure:
sys:\novell
\webaccess
\webpublisher
2) Extract webaccessdocs.tar (or zip) to sys:\apache\htdocs. If you changed
the default document directory for Apache, extract the file to that
directory instead. This will create a large directory structure under
sys:\apache\htdocs beginning with \com\novell. These directories contain
all of the static content (images and help files) for WebAccess. Apache will
serve these up directly, without involving Tomcat.
Copy the index.html file in the install directory to sys:\apache\htdocs. Note
that this will replace the default Apache index.html page, so if you don’t
want your existing index page replaced, rename the WebAccess one to
something else like webacc.html, then link to this file from whatever page
you wish.
3) Before going further, we need to stop and take a look at the Tomcat
directory structure. Observant readers may have already noticed that after
running Tomcat for the first time, several new directories magically
appeared under \webapps. Specifically, the following directories are now
present (your list may be slightly different, depending on the version of
Tomcat installed):
\admin
\examples
\ROOT
\test
These are Tomcat “contexts” or “containers” that were automatically
created the first time Tomcat was loaded. A full treatment of Java
applications is well out of the scope of this guide, but at the risk of
oversimplification, just think of these contexts as separate “applications”
that get executed via specific URL mappings. For example, pointing a
browser at
http://<server>/examples
20
will cause Apache to hand off this request to Tomcat, which in turn looks
into the examples context for an application to “run.” In this case, the
“application” is just some example JSP pages and servlets, but that’s the
basic idea. As you can see, Tomcat created several default contexts -- most
self-explanatory -- but we are particularly interested in the ROOT context.
As luck would have it, all URLs referencing /servlet are mapped to the
ROOT context. Since the WebAccess templates reference the servlets via a
/servlet URL, this provides us with a convenient location to place the
servlets and supporting libraries without having to modify a single
WebAccess template. This is very important, because having to modify the
WebAccess templates to look for the servlets in a location other than
/servlet would be a maintenance and upgrade nightmare to say the least.
That said, lets get back to extracting the WebAccess files.
Create a \lib directory under sys:\<tomcat>\webapps\ROOT\WEB-INF
Extract webaccessjars.tar (or zip) to
sys:\<tomcat>\webapps\ROOT\WEB-INF\lib
4) Extract webaccessservlets.tar (or zip) to
sys:\<tomcat>\webapps\ROOT\WEB-INF\classes
Now we need to edit some configuration files. (I did say this was a manual
configuration…)
1) Open sys:\<tomcat>\webapps\ROOT\WEB-INF\web.xml in WordPad, and
add the following text between the <web-app> and </web-app> tags.
<!-- WebAccess servlet -->
<servlet>
<servlet-name>
webacc
</servlet-name>
<servlet-class>
com.novell.webaccess.WebAccessServlet
</servlet-class>
<init-param>
<param-name>Config</param-name>
<param-value>sys:/novell/webaccess/webacc.cfg</param-value>
</init-param>
<load-on-startup/>
</servlet>
<!-- WebAccess SpellCheck servlet -->
<servlet>
<servlet-name>
spellchk
</servlet-name>
<servlet-class>
com.novell.collexion.spell.servlet.SpellServlet
</servlet-class>
<init-param>
<param-name>Config</param-name>
<param-value>sys:/novell/webaccess/spellchk.cfg</param-value>
</init-param>
<load-on-startup/>
</servlet>
(continued on next page…)
21
<!-- WebPublisher servlet -->
<servlet>
<servlet-name>
webpub
</servlet-name>
<servlet-class>
com.novell.webpublisher.WebPublisherServlet
</servlet-class>
<init-param>
<param-name>Config</param-name>
<param-value>sys:/novell/webpublisher/webpub.cfg</param-value>
</init-param>
<load-on-startup/>
</servlet>
<servlet-mapping>
<servlet-name>
webacc
</servlet-name>
<url-pattern>
/webacc/*
</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>
spellchk
</servlet-name>
<url-pattern>
/spellchk/*
</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>
webpub
</servlet-name>
<url-pattern>
/webpub/*
</url-pattern>
</servlet-mapping>
Spacing is not critical in an XML file, but indenting appropriately greatly increases
readability. Be very careful to get everything entered exactly as shown (servlets are
case-sensitive!) and to close all tags. This file is the Tomcat equivalent of the
servlets.properties file used in the old Novell Servlet Gateway, and simply tells Tomcat
what servlets to load for this context, and how to load them. Save this file and
continue.
Open sys:\novell\webaccess\webacc.cfg in a text editor. Edit the Templates.path=
line to reflect the correct location of the templates. In our example, this is
/jakarta-tomcat-3.3.1/webapps/ROOT/WEB-INF/classes/com/novell/web
access/templates
This line should not wrap, as it may appear in this text. Again, pay close attention to
case and use forward slashes. Assuming you did not change the location of the static
files, etc, nothing else should need to be modified in this file at this time. Save the file
and continue.
Now open sys:\novell\webaccess\spellchk.cfg in a text editor. Edit the
Speller.Dictionary.path= line to reflect the correct location of the dictionary files. In
our example, this is
22
/jakarta-tomcat-3.3.1/webapps/ROOT/WEB-INF/classes/com/novell/col
lexion/morphology/data
This line should not wrap, as it may appear in this text. Save the file and continue.
Since we’re also installing WebPublisher in this example, we need to edit its config file
in a similar way. Open sys:\novell\webpublisher\webpub.cfg in a text editor. Edit the
Templates.path= line to reflect the correct location of the templates. In our example,
this is
/jakarta-tomcat-3.3.1/webapps/ROOT/WEB-INF/classes/com/novell/web
publisher/templates
This line should not wrap, as it may appear in this text.
Now scroll to the end of the webpub.cfg file and change the line
Provider.GWDOC.Config.file=/novell/webpublisher/commgr.cfg
to a UNC path like this:
Provider.GWDOC.Config.file=\\web\sys\novell\webpublisher\commgr.c
fg
In this example, the NetWare server is called WEB. Obviously, you’ll need to change
this to whatever your NetWare server is called. Failure to make this change will cause a
“500” error when you attempt to open WebPublisher. Assuming you did not change the
location of the static files, etc, nothing else should need to be modified in this file at
this time. Save the file and continue.
Now copy the commgr.cfg file from the WebAccess gateway directory (under
<domain>\wpgate) to both sys:\novell\webaccess and sys:\novell\webpublisher. This file
contains the encyption key and IP address information the servlets need to
communicate with the WebAccess gateway.
At this point, we’re ready to fire up WebAccess. Restart the server, then reload Java,
Tomcat and Apache. Start the WebAccess gateway by typing the following command at
the server:
strtweb
If all systems are “go”, point your browser at
http://<server>
23
You should see a page that looks like this (assuming you overwrote the Apache default
index.html file with the WebAccess one)
Everything on this page is static content that Apache is serving up. Clicking “go” for
WebAccess causes the browser to point at
http://<server>/servlet/webacc
24
If everything is working, you should be rewarded with a WebAccess login page like this
one:
This content is being generated by the servlet and templates, and indicates that the
WebAccess servlets are indeed executing properly. Log in and enjoy your new
WebAccess gateway running on NetWare with Apache/Tomcat!
Don’t forget to add the Java, Tomcat and Apache load lines to your AUTOEXEC.NCF
file. Depending on the speed of your server, you may have to delay the loading of
Tomcat and/or Apache slightly, so that one has time to load before the next. This can
be done with something like delay.nlm.
Secure WebAccess
Setting up Apache to let WebAccess do SSL is remarkably simple. Before we dive into
the details, it is important to note that Apache is going to be doing all of the SSL work,
and because Tomcat is integrated with Apache it receives the “benefit” of this
security. Configuring Tomcat to do SSL itself is a much more complex endeavor, and
completely unnecessary since Apache can do it better, faster and easier.
25
So… you now have WebAccess working on Apache/Tomcat, and want to allow SSL
access to it. Start by opening the Apache HTTPD.CONF file, and un-commenting this
line:
LoadModule tls_module modules/mod_tls.nlm
Now save the file, restart Apache… and its ready to do SSL. I did say it was remarkably
simple… try it out by going to https://<server>/servlet/webacc
You should get prompted with the familiar “validate certificate” prompt that pops up
when the browser sees a NetWare certificate it can’t validate to a trusted root (which
of course is every NetWare certificate.) Which certificate is Apache using? Again, look
in your Apache HTTPD.CONF file and scroll to the end. There you should see a directive
similar to this:
<IfModule mod_tls.c>
SecureListen 443 "SSL GWMail-Apache"
</IfModule>
In this example, I’m using a KMO certificate I created called GWMail-Apache. By default
you’ll probably see the “SSL CertificateIP” or “SSL CertificateDNS being used. I chose
to create my own certificate specifically for this instance of Apache because we access
our WebAccess via https://gwmail.domain.com, thus I needed a certificate created
with that domain to avoid the “certificate name does not match” error the browser
throws at you when you use a certificate that does not match the domain/i p of the
request.
Another common request is to force users to use https when running WebAccess. In
most cases, disabling port 80 on the web server is not a valid option because the web
server is often used for other non-secure sites. So, what then? You simply need to
exercise the built-in “redirect” directive within Apache.
Say users can get to your WebAccess site by going to http://gwmail.yourdomain.com as
well as https://gwmail.yourdomain.com All you need to do is tell apache to redirect
the browser to the https:// URL whenever it sees the user trying to go to WebAccess.
Open the Apache HTTPD.CONF file and scroll down to the section where it talks about
Redirects (the redirect directive can really go just about anywhere in the file, but it
makes sense to put it in the standard place.) Now simply add this line and save the file:
Redirect /servlet/webacc https://<server>/servlet/webacc
That’s all there is to it. Now users will be forced to the https:// URL for webaccess,
and will simply not be able to access it via http:// any longer. This redirect only
effects URLs containing /servlet/webacc, so the the Apache server can safely keep
on handling port 80 requests for other URLs.
End.
26
27