Scott & Alfredo,
Unfortunately, I don't know how to do letter c as described below...I've
played with it for a couple of hours this morning and haven't had any
luck...
a) Install the DCM and it's prerequisites. - done
b) Create a *SYSTEM certificate store. - done
c) Create or install a server certificate - ???
d) Create a new application profile.
e) Assign the server certificate to the application profile.
I've set up a test apache server on our 400 (HTTPSTEST) to try this out
with no luck yet...
Shane Cessna
Senior iSeries Programmer
North American Lighting, Inc.
217.465.6600 x7776
Scott Klement <web400@xxxxxxxxxxxxxxxx>
Sent by: web400-bounces@xxxxxxxxxxxx
06/19/2007 06:17 PM
Please respond to
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
To
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
cc
Subject
Re: [WEB400] SSL & CGIDEV2...
Hi Shane,
Has anyone successfully implemented SSL on apache?
Yes.
If so, can you
send a sample config file with multiple LocationMatch directives?
No. I haven't used the LocationMatch directive, but I don't see any
reason why your existing ones wouldn't work?
Is there a lot of new configuration that has to be done in order
to move from a non-SSL environment to an SSL environment?
Yes and no. Almost all of the work is setting up the Digital
Certificate Manager so that your server can do SSL processing. This has
basically nothing to do with HTTP -- you need it any time you do SSL on
i5/OS (whether it's TELNET, FTP, LDAP, HTTP, etc, doesn't matter...)
You have to:
a) Install the DCM and it's prerequisites.
b) Create a *SYSTEM certificate store.
c) Create or install a server certificate
d) Create a new application profile.
e) Assign the server certificate to the application profile.
If you already have the DCM installed and are already familiar with
setting up an application for SSL, you can skip steps a-c, and just
create the app profile and assign the cert, which obviously is less work
:)
I have an apache server listening on port 80 for requests to pass to
my CGIDEV2 programs. I'd like to be able to enable this without a
ton of work...
The Apache part is very simple... First you have to tell Apache to load
the (IBM-supplied) service program for SSL communications, and to listen
for new connections on port 443 (or whatever port you choose). You do
this by adding the following directives into your httpd.conf file (I
have these as the first two directives in the file):
LoadModule ibm_ssl_module /QSYS.LIB/QHTTPSVR.LIB/QZSRVSSL.SRVPGM
Listen *:443
Then you have to tell it that when a connection is made to port 443, it
should use SSL for that connection. And you have to tell it the name of
the app profile you created in the DCM (above) so that it knows how the
SSL should work. The following directives enable that (I have these as
the last 4 lines in my httpd.conf file):
<VirtualHost *:443>
SSLEnable
SSLAppName KLEMENTS_HTTPS
</VirtualHost>
SSLAppName is the application profile name... in my example, I used
KLEMENTS_HTTPS, but in your case it'd be something else, the name that
you chose when you created the app profile in the DCM.
Then just restart your HTTP server and SSL will be enabled. If you
connect normally (via http to port 80) you'll get a non-SSL connection,
and if you connect with SSL (via https to port 443) you'll get an SSL
connection. In my sample config, above, I did not change the
DocumentRoot, or any of the aliases, so it'll access the exact same
directories via SSL as non-SSL.
There's no need to change anything in CGIDEV2. CGIDEV2 does not do
network communications, the HTTP server does that. So it should be
completely transparent to CGIDEV2. Except, of course, that you might
need to change some of the URLs in your applications to say 'https:'
instead of 'http:'
I didn't understand the bit about LocationMatch... IIRC, LocationMatch
has nothing to do with SSL...
Remember, the SSL encryption is established before ANYTHING is
transmitted over the network -- that's the point, to keep your
communications secure! Since the requested URL has not been sent from
the browser to the server yet, there's no way the server can use the URL
as part of it's SSL negotiation.
Since the LocationMatch directive has to do with matching part of the
URL that's sent, nothing in a LocationMAtch directive will have any
effect on how the SSL works. The SSL has already been established long
before LocationMatch becomes relevant.
hope that makes sense.
midrange.com
