MikeL's FreeBSD howto - Apache setup

MikeL's FreeBSD howto - Apache setup

(21-Sep-2001)

(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:

When you get your certificate you will specify a hostname that it will use for keeps -- you cannot change it. For this reason, I would strongly recommend using a generic hostname, and adding that to your DNS info. This way you can move the certificate services to another machine with no problems. For example, my main website machine happens to be named 'brix.vintners.net', however I had the certificate set up for 'secure.vintners.net'.
Warning! Before ordering that certificate, be sure you can get your server to answer to that generic name -- if you were to order it, and can't get your config to answer to that name, you've just thrown away that money.
It is possible to have a single certificate handle multiple domains, if you're really creative and don't mind spending time dorking around; the drawback is that the URL will change to the base provider during secure transactions.
I would recommend creating a uid/gid specifically for Apache to run as. As far as I can tell, Apache starts up as superuser, then changes to the uid/gid specified in the /usr/local/etc/apache/httpd.conf file.
The reason to do this is so that you can have CGI/scripts write data and you can control whom they can be written to via file permissions. (Do a man pw for help with this.)
Be sure to set tight permissions on the certificate/key dirs.
- chmod 600
- chown root
As Apache seems to start up as root, it can read these files.
I would recommend limiting the 'Options'.
'ServerAlias = *.domain' tells this Apache to answer any reference to that domain, eg. "http://www.domain.com", "http://ftp.domain.com", "http://test.domain.com", etc. Without it we'll only answer to "http://domain.com/". This is much better than having multiple domain blocks, for a given domain, although that does work too.
I arbitrarily chose to have a '/web' dir with all my domains in it, their entire name spelled out.
In each dir I arbitrarily chose to have an 'html', 'data' and 'logs' dir. The customer puts the website HTML code in the html dir, and Apache puts it's files in the 'logs' dir, where the file space is in their dir tree. This also allows them to download and run analyzer apps on them.
If you go with the above, you'll have to change the UserDir directive to html as the default is public_html.
Immediately following, you'll find a Directory directive for /home/*/public_html -- be sure to change that too if you're commetning it in to use.
To use modssl, you'll have an additional block just like the above, except it will have a ':443' tacked on to the this machines IP addr. You can also use the magic word '_default_' instead of an IP address if you want all ssl domains to go here. It'll have the additional fields SSLEngine on, and SSLCertificateFile /usr/local/etc/apache/ssl.crt/your-cert-file.crt. Be sure to 'chmod' this dir appropriately (see above).
I recommend making yourself a apache-restart script and get used to using it instead of directly using apachectl:
```
/usr/local/sbin/apachectl stop
/usr/local/sbin/apachectl startssl
```
The reason is that if you do an "apachectl restart", it will not restart modssl. I can't tell you how many times I forgot this...

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:

  cd /usr/ports/www/apache13
  make
  su
  make install


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.




cd /usr/ports/www/apache13-modssl

make

(As root) make install
 Be warned that henceforth,
    when you boot your system, when starting the other deamons, it
    will appear to hang at Apache -- it is asking for the passphrase
    you entered during the following "make certificate".  This can be
    gotten around, see the SSL FAQ at modssl URL (above).



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.




make certificate

cd /usr/local/openssl

cp openssl.cnf.sample openssl.cnf

    Edit if you wish.

http://apache-ssl.raver.net/

cd /usr/ports/www/apache13-modssl/work/apache_1.3.9/src

cp Configuration.tmpl Configuration

cd ..

make install



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.




cd to each /usr/ports{www/apache13-modssl,security/rsaref,security/openssl,devel/mm} and rm -r work/

cd /usr/ports/security/rsaref

make

As root, make install

cd /usr/ports/security/openssl

make USA_RESIDENT=YES

As root, make install

cd /usr/ports/devel/mm

make

As root, make install

cd /usr/ports/www/apache13-modssl

make |& tee make.log

make certificate

    Should be obvious, be sure to use FQDN when asked.

As root, make install




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
</VirtualHost>




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:

mkdir the dir to be protected within their existing html dir
Add a '.htaccess' file to this newly made private dir:
  AuthName "whomever's private dir"
  AuthType Basic
  AuthUserFile /usr/local/etc/apache/users
  require valid-user

use htpasswd to create the pseudo user with passwd



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:

  /etc/virtusertable

  /etc/aliases.customer


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-2010

Mike Lempriere