pkg install php83
pkg install php83-session
Note! If you miss the latter session install, your code will appear to need a 'global' decl for subroutines to get at the $_SESSION variable. What's really happening, is that the session var is not actually present, so you're creating a var yourself, and it's NOT a "super-global". I really, really, really hate PHP.

I got Apache running with the default installation. I then brought over all the config files for Apache, corrected the ServerName, and tried starting. No startup, and a core file. I went back to the default installation file, and painstakingly merged a few lines at a time from the old httpd.conf. I eventually determined the line that was breaking everything was the include of PHP. PHP is installed, as v 8.3.0alpha2. I'm pretty sure I've done a pkg install mod_php8 -- do it again, yes it's already installed. Doing a find / -name libphp.so -print yields files in /usr/local/lib/ and /usr/local/libexec/apache24/ directories -- looks good.

In desperation, I tried rebooting -- fixed it!

Google search found this nice article: FAMP stack FreeBSD

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

• [20180824] - Found on "ServerFault.com: Change SSLVerifyClient require to none in you ssl config section."
  
• [20180812] - MOST IMPORTANT! Startup error info is in the error log specified in the "CustomLog" directive at the end of the http-ssl.conf file. ("/web/vintners.net/logs/httpd-ssl_request_log2018q1" on my server).
  
• [20180812] Note that I could not get apache to start with the ssl config included - got error "failed to start" from apachectl start - real helpful!
  Looking into /var/log/http-error.log I see the error:
  Init:Session Cache is not configured
  In http.conf I've tried each:
  LoadModule socache_shmcb_module libexec/apache24/mod_socache_shmcb.so
  and LoadModule socache_dbm_module libexec/apache24/mod_socache_dbm.so
  and in Include/http-ssl.conf enable the line:
  SSLSessionCache "dbm:/var/run/ssl_scache"
  or the other line for "shmcb".
  Note that these changes require a stop/start, restart will not do it.
  No combination allows me to start Apache so I'm still running no SSL.
  I'm still getting the SessionCache warning - I'm not really not sure if that's progress or not...
  
• [20180812] You might want to add the "server-status" page. See following for directions:
  http://wiki.apache.org/httpd/SSLSessionCache
  and hardcode the IP of the computer you're running the browser on inthe "Allow" statement.
  Note also that after making these changes you must do an apache stop and start, restart doesn't do it.
  Look in this output for a block of data following the line:
  SSL/TLS Session Cache Status:
  if not present, SSL is not configured. (Yeah, we already knew that.)
  
• [20111201] When attempting to add a new certificate (old had expired), I changed SSLCertificate* directives in http-ssl.conf to point to the new files. When restarting Apache, I'd get the error "Failed to enable the 'httpready' Accept Filter". Confusingly, this only happened with the new certs, not the old. I have no explanation why, I can guess it might be related to the fact that new certs from NetSol since 2011 are minimum length 2048, the old ones were 1024. A google search found this problem (the error msg), and had me do a 'kldload' immediately, which seemed to fix it. It also said I'd need to add
  accf_http_load="YES"
  to my /boot/loader.conf
  file. My file was empty (zero bytes) when I added this line. I have not rebooted the system yet, so don't know if this part is going to work. MyDigitalLife page
  [20180812] For Apache24 I had to also add
  accf_data_load="YES"
  
• 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...

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

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).

• 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

• 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

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>

[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!?

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.

• 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

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.