You now have to think about the Config files for the site. A sample Config file will be found at .../apache_1.3.XX/SSLconf/conf, which tells you all you need to know about Apache-SSL.
It is possible that this Config file tells you more than you want to know right away, so a much simpler one can be found at site.ssl/apache_1.3. (Apache v2 is sufficiently different, so we have started over at site.ssl/apache_2.) This illustrates a fairly common sort of site where you have an unsecured element for the world at large, which it accesses in the usual way by surfing to http://www.butterthlies.com,and a secure part (here, notionally, for the salesmen) which is accessed through https://sales.butterthlies.com,followed by a username and password — which, happily, is now encrypted. In the real world, the encrypted part might be a set of maintenance pages, statistical reports, etc. for access by people involved with the management of the web site, or it might be an inner sanctum accessible only by subscribers, or it might have to do with the transfer of money, or whatever should be secret...
User webserv
Group webserv
LogLevel notice
LogFormat "%h %l %t \"%r\" %s %b %a %{user-agent}i %U" sidney
SSLCacheServerPort 1234
SSLCacheServerPath /usr/src/apache/apache_1.3.19/src/modules/ssl/gcache
SSLCertificateFile /usr/src/apache/apache_1.3.19/SSLconf/conf/new1.cert.cert
SSLCertificateKeyFile /usr/src/apache/apache_1.3.19/SSLconf/conf/privkey.pem
SSLVerifyClient 0
SSLFakeBasicAuth
SSLSessionCacheTimeout 3600
SSLDisable
Listen 192.168.123.2:80
Listen 192.168.123.2:443
<VirtualHost 192.168.123.2:80>
SSLDisable
ServerName www.butterthlies.com
DocumentRoot /usr/www/APACHE3/site.virtual/htdocs/customers
ErrorLog /usr/www/APACHE3/site.ssl/apache_1.3/logs/error_log
CustomLog /usr/www/APACHE3/site.ssl/apache_1.3/logs/butterthlies_log sidney
</VirtualHost>
<VirtualHost 192.168.123.2:443>
ServerName sales.butterthlies.com
SSLEnable
DocumentRoot /usr/www/APACHE3/site.virtual/htdocs/salesmen
ErrorLog /usr/www/APACHE3/site.ssl/apache_1.3/logs/error_log
CustomLog /usr/www/APACHE3/site.ssl/apache_1.3/logs/butterthlies_log sidney
<Directory /usr/www/APACHE3/site.virtual/htdocs/salesmen>
AuthType Basic
AuthName darkness
AuthUserFile /usr/www/APACHE3/ok_users/sales
AuthGroupFile /usr/www/APACHE3/ok_users/groups
Require group cleaners
</Directory>
</VirtualHost>Notice that SSL is disabled before any attempt is made at virtual hosting, and then it’s enabled again in the secure Sales section. While SSL is disabled, the secure version of Apache, httpsd, behaves like the standard version httpd. Notice too that we can’t use name-based virtual hosting because the URL the visitor wants to see (and hence the name of the virtual host) isn’t available until the SSL connection is established.
SSLFakeBasicAuth pretends the client logged in
using basic auth, but gives the DN of the client cert instead of his
login name, and a fixed password: password. Consequently, you can use
all the standard directives: Limit,
Require, Satisfy.
Ports 443 and 80 are the defaults for secure (https) and insecure (http) access, so visitors do not have to specify them. We could have put SSL’s bits and pieces elsewhere — the certificate and the private key in the .../conf directory, and gcache in /usr/local/bin — or anywhere else we liked. To show that there is no trickery and that you can apply SSL to any web site, the document roots are in site.virtual. To avoid complications with client certificates, we specify:
SSLVerifyClient 0
This automatically encrypts passwords over an HTTPS connection and so mends the horrible flaw in the Basic Authentication scheme that passwords are sent unencrypted.
Remember to edit go so it invokes httpsd (the secure version); otherwise, Apache will rather puzzlingly object to all the nice new SSL directives:
httpsd -d /usr/www/APACHE3/site.ssl
When you run it, Apache starts up and produces a message:
Reading key for server sales.butterthlies.com:443 Launching... /usr/www/apache/apache_1.3.19/src/modules/sslgcache pid=68598
(The pid refers to gcache,
not httpsd.) This message shows that the right
sort of thing is happening. If you had opted for a passphrase, Apache
would halt for you to type it in, and the message would remind you
which passphrase to use. However, in this case there
isn’t one, so Apache starts up.[9] On the client side,
log on to http://www.butterthlies.com.The postcard site should appear as usual.
When you browse to
https://sales.butterthlies.com,you are asked for a username and password
as usual — Sonia and theft will do.
Remember the “s” in
https. It might seem rather bizarre that the
client is expected to know in advance that it is
going to meet an SSL server and has to log on securely, but in
practice you would usually log on to an unsecured site with
http and then choose or be steered to a link that
would set you up automatically for a secure transaction.
If you forget the “s” in
https,various things can
happen:
If you pass these perils, you find that your browser vendor’s product-liability team has been at work, and you are taken through a rigmarole of legal safeguards and “are you absolutely sure?” queries before you are finally permitted to view the secure page.
We started running with SSLVerifyClient
0, so Apache made no inquiry concerning our own
credibility as a client. Change it to 2, to force
the client to present a valid certificate. Netscape now says:
No User Certificate The site 'www.butterthlies.com' has requested client authentication, but you do not have a Personal Certificate to authenticate yourself. The site may choose not to give you access without one.
Oh, the shame of it! The simple way to fix this smirch is to get a personal certificate from one of the companies listed shortly.