(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
nonein you ssl config section.
http-ssl.conffile. ("/web/vintners.net/logs/httpd-ssl_request_log2018q1" on my server).
apachectl start- real helpful!
/var/log/http-error.logI see the error:
Init:Session Cache is not configured
http.confI've tried each:
LoadModule socache_shmcb_module libexec/apache24/mod_socache_shmcb.so
LoadModule socache_dbm_module libexec/apache24/mod_socache_dbm.so
Include/http-ssl.confenable the line:
man pwfor help with this.)
htmlas the default is
/home/*/public_html-- be sure to change that too if you're commetning it in to use.
SSLEngine on, and
SSLCertificateFile /usr/local/etc/apache/ssl.crt/your-cert-file.crt. Be sure to 'chmod' this dir appropriately (see above).
apache-restartscript and get used to using it instead of directly using
/usr/local/sbin/apachectl stop /usr/local/sbin/apachectl startsslThe 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...
/usr/local/etc/rc.d/. See my Autostart hints page for more info.
/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:
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.
cp openssl.cnf.sample openssl.cnf
cp Configuration.tmpl Configuration
make |& tee make.log
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
SSLCertificateKeyFile directive in the
/usr/local/etc/apache/httpd.conf file to these new
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.
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>
[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 startssl. Be warned that
apachectl startdoes 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.
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
To test it, in Netscape, visit the server (using https://... note
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.
AuthName "whomever's private dir" AuthType Basic AuthUserFile /usr/local/etc/apache/users require valid-user
htpasswdto create the pseudo user with passwd
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.