MikeL's FreeBSD howto - Apache setup


(Note -- I know, this is a poorly organized page -- be sure to step down through it, as what you're looking for may be buried down near the end.)

Setup Apache by following the handbook at http://www.apache.org/docs/install.html.

Misc suggestions/Configuration
In no particular order:
Basic Apache server
In my old installation (FreeBSD 2.2.7), the install did not set it up to autostart at boottime, and they did not tell me how. See autostart hints if needed.
A more modern Apache installation (FreeBSD 4.2, Apache 1.3) seems to take care of this properly at install time. It does it by adding an apache.sh file in /usr/local/etc/rc.d/. See my Autostart hints page for more info.
Note! In my older installation (FreeBSD 2.2.7), some of the Perl scripts used by the openssl install required a Perl installation in /usr/local/bin. If it's not there, you will need to make a symbolic link in that dir to your existing Perl installation. If you don't have Perl at all, you'll need to get it. This was not a problem in a modern install (FreeBSD 4.2, Apache 1.3.)

My basic Apache1.3 installation seemed to have mostly worked the first time. The standard FreeBSD modus operandi worked well:

At some point, (FreeBSD 4.0?), the Apache server changed over to a single config file from 3 sperate ones. At that time suddenly everything also changed over to "apache" instead of "httpd". This seems to be back to "httpd" with FreeBSD 4.2, Apache 1.3. (It's possible this was an installation error on my part.)

Apache with MODSSL
Reference material: http://www.thawte.com/, http://www.modssl.org/.

When I wrote this doc originally (FreeBSD was at 3.2? at that time), VeriSign cost $349 for the first website for the first year. Thawte is $125 for the exact same thing. As far as I can tell, there are no other reason to choose one over the other. Which one do you think I used? Since then, Thawte has been bought out by Verisign, or Network Solutions or some such, which legitimizes it even further!

Warning! If you have an existing Apache installation, I would recommend doing a make deinstall as superuser before beginning this part. I do not know if it is necessary, but at some point I did find I had several files out of synch, and ended up having to do an 'rm -r', 'cvsup', and start over.

From here on down is where I flopped around trying to get the certificate built. I have no idea what part of this is bogus and what is real. Once I got mine working, I have not gone back.
The following is another list of junk I had to do back in that old FreeBSD 2.2.7 rendition. I did not have to go through any of this pain in FreeBSD 4.2, Apache 1.3.

MOD_SSL Certificate update
I did not update my notes a year ago when I first got mod-ssl working, sorry. Basically I floundered around using the 'openssl' command from the modssl.org FAQ (see above).

Now this year, I had to update it. I got an email from Thawte with about 1 month notice. I went to their website (URL in their email), and did the "renewal" option. I first tried the non-"real-time" option. This refused several different credit cards. Then I tried the "real-time" flavor, that worked. It sent me an email with a URL where to get my new certificate, which I visited, then did a file save, naming it a .txt.

(Basically, this is your new .crt file.) I cut out all the junk, leaving the "----begin ..." and end lines, and saved it as mycert.crt. I was able to view it by:
    openssl x509 -noout -text -in mycert.crt | more

The original key you used to establish the certificate will be used again for this new one.

Enter your passphrase and don't forget it!

Now create an unencoded version of it:
    mv mycert.key ../ssl.key
    cp mycert.key mycert.key.orig
    openssl rsa -in mycert.key.orig -out mycert.key
I was then able to simply point the SSLCertificateFile and SSLCertificateKeyFile directive in the /usr/local/etc/apache/httpd.conf file to these new files.

Don't forget to chmod/chown these files so that they can only be read by the apache user account, whatever you're using (see below).

Thawte has a logo and magic URL that will verify your certificate for the user. I highly recommend adding this to your secure pages, or at least the entry page to the secure environment -- see their website for details.

VirtualHost block
Now you must add a new virtualhost block to the config file. You'll have one of these for your own domain, and an additional for each additional domain.

<VirtualHost this machines IP addr>
  ServerAdmin webmaster@domain
  Options Indexes FollowSymLinks ExecCGI Includes
  DocumentRoot /web/domain/html/
  ServerName domain
  ServerAlias *.domain
  ErrorLog /web/domain/logs/error_log
  CustomLog /web/domain/logs/access_log common

Note that the ServerName directive must match, or be a superset of the hostname specified in your certificate. If not, you'll get an error like:
[28/Jan/2001 14:50:25 00411] [warn]  Init: (brix.vintners.net:443) RSA server certificate CommonName (CN) `secure.vintners.net' does NOT match server name!?
Then do an apachectl stop and apachectl startssl. Be warned that apachectl start does start the Apache server, but does not start the SSL portion -- incoming HTTP requests will be processed, but incoming HTTPS requests will time out. This can be very disconcerting if you don't know about it.

Now use ps ax | grep httpd to see if it's running. If so, skip on to browser certificate test (below).

If not running, best of luck! One important thing to note is that the SSL related errors will be in the file pointed to by the SSLLog directive (default is /var/log/ssl_engine_log).

To test it, in Netscape, visit the server (using https://... note that's https, not just http), and click on the little padlock icon on the bottom left corner. Then click on the "View Certificate" button and check that the new parms show up.

Private dirs
To make a private (username/password protected) dir, simply:
running perl scripts as root under apache
I've never been happy about how this works. I've spent uncountable hours over a several year span trying to do this right, and there's always some 'nother problem.

I've tried using suidperl and got that F***ing "fix your kernel" message. Eventually gave up on that and went with the crude C wrapper for my script. (Of course this is after manually chmod'ing suidperl to allow setuid since the perl install doesn't, even when you make it with the switches to use suidperl...)

For example, I have a script that allows customers to modify the email aliases for their domain. This is a simple Perl script running via mod_perl or CGI to edit one or more of the following files:
The difficult part is that sendmail will refuse to run if any of these files is not owned by root.

The way I got around this is to add the user under which apache runs ("www") to the "wheel" entry in /etc/group. I'm sure this is a vile security hole, but it got things such that my customers can manage their own accounts.

Copyright © 1995-2017 Mike Lempriere