Re: mod_ssl cores in RSA library
On Fri, 4 Dec 1998, Ralf S. Engelschall wrote: : NOTE: RSAref has some portability problems. Especially it assumes that : an `unsigned long int' represents a four byte word. One result of : this bad assumption is that it fails under run-time (not : compile-time) on platforms/CPUs, like Alphas, where larger integer : sizes are used by the compiler. Hm. I've had ssleay failures on Alpha, but not RSAREF related. The RSA tests succeed. In fact, I'm typing this through an ssh connection authenticated via RSA (RSAREF code) on a 32-bit machine on the remote side. :) -- -- Todd Vierling (Personal [EMAIL PROTECTED]; Bus. [EMAIL PROTECTED]) __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [BugDB] Port vs. Listen : (PR#60)
> > > mod_ssl 2.1.x doesn't pick up the primary port number for the server > > > from the Listen directive the way 2.0.x appears to have done. Using > > > the Port directive solves the problem, but I'm wondering if this may > > > have been an oversight. > > > > Hmmm... no changes were made in this direction. So how do you know that the > > Port setting is not inherited? What's the effect, i.e. where do you see that > > the port is not correct? And what particular config file are you using? > > I'm using a custom set of heirarchical config files: [snip] I've confirmed that this behavior can be duplicated with the normal httpd.conf that's gets made from Apache + mod_ssl. All you have to do is try using 'Listen 10.1.2.3:443' (substitute in the real IP, of course) instead of 'Listen 443' (which is in the /IfDefine) or it's alter-ego 'Port 443'. > [info] Init: 1st startup round (still not detached) > [info] Init: Initializing SSLeay library > [info] Init: Loading certificate & private key of SSL-aware server host:0 > ^^ > [trace] Init: (host:0) unencrypted private key - pass phrase not required > [info] Init: 2nd startup round (already detached) > [info] Init: Initializing SSLeay library > [info] Init: Generating temporary (512 bit) RSA private key > [info] Init: Initializing (virtual) servers for SSL > [info] Init: Configuring server host:0 for SSL protocol > ^^ > [trace] Init: (host:443) Creating new SSL context > [trace] Init: (host:443) Configuring permitted SSL ciphers > [trace] Init: (host:443) Configuring server certificate > [error] Init: (host:443) Ops, can't find server certificate?! > > It was saving the certificate and key in the table as host:0 and then > trying to read it back later as host:443! > > I decided to take a gamble and add one line to my ssl.conf file right > after my Listen directive: "Port 443". Problem solved... -- Jake Buchholz http://www.execpc.com/~jake ExecPC Senior Systems Administrator [EMAIL PROTECTED] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: mod_ssl cores in RSA library
> > Platform is gcc 2.8.1 on an SGI Indigo2 (irix-gcc). > Have you noticed this paragraph in mod_ssl's INSTALL file? > Perhaps your SGI box has a similar problem? I don't know anything about this problem, but this hint may help: I heard that the SGI cc compiler is useing some "workarounds" to avoid some hardware bugs. For instance it's impossible to compile squid, a proxy-server, with gcc. We tried native cc compiler, and it run. You may have the same problem. Of course the builders of gcc cannot know about the "tricks" the native compiler uses, since SGI doesn't support it or even documentate bug of course... oki, Steffen ps.: Sorry for my bad english... __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Nice writeup of mod_rewrite
Kind of off topic, but I just read a nice article using Ralf's mod_rewrite. Good thing I checked the mail this afternoon (USA time), eh? :) It starts on pp. 10 of the Jan. 1999 Web Techniques magazine. ( http://www.webtechniques.com/ ) Though their web site appears a bit behind on getting the current articles up (the one on Ralf's software isn't up yet) Just an FYI.Best, John. (mod_ssl mirror at ftp://glock.missouri.edu/pub/mod_ssl/ ) __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Will this kill this project? http://www.newsbytes.com/pubNews/122463.html
What impact will this have on the mod_ssl project if it is indeed accurate? http://www.newsbytes.com/pubNews/122463.html - William X. Walsh (WXW7/WW1506)| TJ Network Services - The .TJ NIC Network Operations| http://tjns.tj / http://nic.tj [EMAIL PROTECTED][EMAIL PROTECTED]| Domain Names, DNS, Email, +1-(209)-493-6144 | DynamicDNS & Web Hosting Services - Date: 04-Dec-98 / Time: 22:50:00 __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Nice writeup of mod_rewrite
On Sat, Dec 05, 1998, John Leveron wrote: >Kind of off topic, but I just read a nice article using Ralf's > mod_rewrite. Good thing I checked the mail this afternoon (USA time), > eh? :) Great. Who's the author? Lincoln? I ask because some time ago someone informed me that a mod_rewrite article occurs, but I forgot who it was... >It starts on pp. 10 of the Jan. 1999 Web Techniques magazine. ( > http://www.webtechniques.com/ ) > Though their web site appears a bit behind on getting the current > articles up (the one on Ralf's software isn't up yet) Shit, here in Munich/Germany WEBTEchnique magazines are no longer available (all local kiosks dropped it because of too less readers AFAIK) since a few months. I had already great problems to get a few extra copies of the April'98 issue (where my "Load Balancing Web Sites" article occured) last time. So, perhaps someone can scan the article pages in and forward them to me (any format is possible, I've Photoshop and all other tools; just upload the files to ftp://ftp.engelschall.com/incoming/ when it's too large for email). I'm very interested in the print-version of this article Thanks. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Will this kill this project? http://www.newsbytes.com/pubNews/122463.html
On Fri, Dec 04, 1998, William X. Walsh wrote: > What impact will this have on the mod_ssl project if it is indeed accurate? > > http://www.newsbytes.com/pubNews/122463.html A few facts from my point of view: 1. Although the article said "Germany is among the countries that agreed to make their controls more strict at the Wassenaar meeting" AFAIK this is still only a press information IMHO. Nothing really happended until now AFAIK. And because since a few weeks we've a new government I'm not convinced that this will really happen. At least the new government is less conservative than the old, so such crypto laws have less chance. 2. mod_ssl is distributed from _Switzerland_ and not from Germany, because www.engelschall.com is located in Zurich, Switzerland at the ETHZ. So even when our German law should change we can distribute/export mod_ssl from there unless I've do my development on this machine, too. 3. Really good pieces of software never get lost: there is always one who takes it over and develops it further for the community. So even when I personally would no longer be allowed to develop mod_ssl I'm sure we find someone who can take it over. At least I currently try hard to make mod_ssl the cleanest SSL solution for Apache, so I'm convinced that a new developer can be found when all should go finally bad with the laws. So, don't panic. I'm sure mod_ssl will survive those law issues... Greetings, Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
BorderManager
Hi! I got a user who says: > We are running Novell's BorderManager to control user access to the > internet, and I can't seem to set up correct rights to a https (secure > address) as the main page. I would like to know if there is a link page > prior to your site's main page?. I know this would work as we also use > BCOnline and link to a page prior to the sign on page which is a https > type page. Is there an inherent problem with using mod_sll from behind a firewall or is there a configuration problem somewhere? Many thanks. -- Jean Meloche __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: BorderManager
On Sat, Dec 05, 1998, Jean Meloche wrote: > I got a user who says: > > > We are running Novell's BorderManager to control user access to the > > internet, and I can't seem to set up correct rights to a https (secure > > address) as the main page. I would like to know if there is a link page > > prior to your site's main page?. I know this would work as we also use > > BCOnline and link to a page prior to the sign on page which is a https > > type page. > > Is there an inherent problem with using mod_sll from behind a firewall > or is there a configuration problem somewhere? No, usually all you have to do on a Firewall is to allow remote ports 443 (HTTPS) to be accessible by your Intranet clients in addition to port 80 (HTTP). There is only one exception: There are some Firewalls out there who provide a content filter for HTTP and some Firewall admins enable this filter for both the HTTP and HTTPS remote port connections. Obviously for the HTTPS connection this cannot work this way such easily. So the Firewall admin should make sure this BorderManager box doesn't try such things. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [BugDB] Port vs. Listen : (PR#60)
On Fri, Dec 04, 1998, Jake Buchholz wrote: > > > > mod_ssl 2.1.x doesn't pick up the primary port number for the server > > > > from the Listen directive the way 2.0.x appears to have done. Using > > > > the Port directive solves the problem, but I'm wondering if this may > > > > have been an oversight. > > > > > > Hmmm... no changes were made in this direction. So how do you know that the > > > Port setting is not inherited? What's the effect, i.e. where do you see that > > > the port is not correct? And what particular config file are you using? > > > > I'm using a custom set of heirarchical config files: > > [snip] > > I've confirmed that this behavior can be duplicated with the normal > httpd.conf that's gets made from Apache + mod_ssl. All you have to do > is try using 'Listen 10.1.2.3:443' (substitute in the real IP, of course) > instead of 'Listen 443' (which is in the /IfDefine) or it's alter-ego > 'Port 443'. > > > [info] Init: 1st startup round (still not detached) > > [info] Init: Initializing SSLeay library > > [info] Init: Loading certificate & private key of SSL-aware server host:0 > > ^^ > > [trace] Init: (host:0) unencrypted private key - pass phrase not required > > [info] Init: 2nd startup round (already detached) > > [info] Init: Initializing SSLeay library > > [info] Init: Generating temporary (512 bit) RSA private key > > [info] Init: Initializing (virtual) servers for SSL > > [info] Init: Configuring server host:0 for SSL protocol > > ^^ > > [trace] Init: (host:443) Creating new SSL context > > [trace] Init: (host:443) Configuring permitted SSL ciphers > > [trace] Init: (host:443) Configuring server certificate > > [error] Init: (host:443) Ops, can't find server certificate?! > > > > It was saving the certificate and key in the table as host:0 and then > > trying to read it back later as host:443! > > > > I decided to take a gamble and add one line to my ssl.conf file right > > after my Listen directive: "Port 443". Problem solved... That's a really interesting problem. I've installed a fresh version with the default config: works fine. I've now changed the "Listen 443" to "Listen 192.76.162.40:443" and it still works fine. In other words: I cannot reproduce this problem on my box. You can send me your _exact_ and _complete_ server config files (the ones you derived from the default config)? There has to be still a subtle difference, I think. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Nice writeup of mod_rewrite
"Ralf S. Engelschall" wrote: > Great. Who's the author? Lincoln? I ask because some time ago someone informed > me that a mod_rewrite article occurs, but I forgot who it was... Ja, Lincoln D. Stein is the author. > Shit, here in Munich/Germany WEBTEchnique magazines are no longer available > (all local kiosks dropped it because of too less readers AFAIK) since a few > months. I had already great problems to get a few extra copies of the April'98 > issue (where my "Load Balancing Web Sites" article occured) last time. So, > perhaps someone can scan the article pages in and forward them to me (any > format is possible, I've Photoshop and all other tools; just upload the files > to ftp://ftp.engelschall.com/incoming/ when it's too large for email). I'm > very interested in the print-version of this article Thanks. Will do Ralf! Best, John. __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Will this kill this project? http://www.newsbytes.com/pubNews/122463.html
The biggest thing to remember in amidst all this legal light show crap is that the longer these countries hold down strong encryption, the longer they hold back widespread Net commerce... commerce that adds jobs, increases the taxable income of companies and, in the long term, increases the government's income from both corporate and personal taxes. All of which comes right around again to fight terrorists and all the people they're worried about using the strong encryption. The bottom line: strong encryption is no different that any other weapon - if it's illegal, then only criminals will have it (exactly the opposite of what the law tries to prevent). In this case, keeping it illegal also stunts the growth of the world economy at the same time. So, when you take away all the rhetoric and utterly inane arguments, keeping strong encryption bottled is really a very silly thing to do. Regards, dsp [EMAIL PROTECTED] -+-<|>-+- [EMAIL PROTECTED] #include What's a nose for? It's for aerodynamics, like running. Get it? Nose .. running? -- my wife On Saturday, December 05, 1998 4:23 AM, Ralf S. Engelschall [SMTP:[EMAIL PROTECTED]] wrote: > On Fri, Dec 04, 1998, William X. Walsh wrote: > > > What impact will this have on the mod_ssl project if it is indeed accurate? > > > > http://www.newsbytes.com/pubNews/122463.html > > A few facts from my point of view: > > 1. Although the article said "Germany is among the countries that agreed to >make their controls more strict at the Wassenaar meeting" AFAIK this is >still only a press information IMHO. Nothing really happended until now >AFAIK. And because since a few weeks we've a new government I'm not >convinced that this will really happen. At least the new government is >less conservative than the old, so such crypto laws have less chance. > > 2. mod_ssl is distributed from _Switzerland_ and not from Germany, because >www.engelschall.com is located in Zurich, Switzerland at the ETHZ. So >even >when our German law should change we can distribute/export mod_ssl from >there unless I've do my development on this machine, too. > > 3. Really good pieces of software never get lost: there is always one >who takes it over and develops it further for the community. So even when >I >personally would no longer be allowed to develop mod_ssl I'm sure we find >someone who can take it over. At least I currently try hard to make >mod_ssl >the cleanest SSL solution for Apache, so I'm convinced that a new >developer >can be found when all should go finally bad with the laws. > > So, don't panic. I'm sure mod_ssl will survive those law issues... > > Greetings, >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > __ > Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ > Official Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
suexec on RH 5.1, Ap 1.3.3, mod_ssl-2.0.15-1.3.3
I'm becoming exasperated :)
I have successfully installed the above combination on a RH 5.2 machine,
so I'm baffled as to why it doesn't work on another machine.
Both machines use virtual hosts, due to the nature of mod_ssl (and the
fact that there are multiple domains on both).
The one thing that tells me there's something wrong with the "problem"
machine: no suexec_log is generated. When I try to compile all of it
together, via :
(ssl already made, etc.)
cd /tmp/mod_ssl-2.0.15-1.3.3/
SSL_BASE=/tmp/SSLeay-0.9.0b
./configure --with-apache=../apache_1.3.3 && cd ../apache_1.3.3
./configure --prefix=/usr/local/apache \
--enable-module=ssl --enable-module=most --enable-suexec
--suexec-caller=httpd \
--suexec-userdir=www --suexec-uidmin=500 --suexec-gidmin=100
make && make install
it goes fine.
If I try to include
--suexec-logfile=/usr/local/apache/var/log/suexec.log it throws an
error, which I don't understand, since this is documented at
http://www.apache.org/docs/suexec.html#install
But from what I've understood, it should work, and default to placing a
log file under my log subdir . . . examined the Makefile, and that's
what it showed, too.
Permissions all the way into the /usr/local/apache/var/log/ subdir are
at least 700 . . . owner and group of root.
Trying to run server as user httpd, group nobody (or httpd) both users
and groups exist.
I've been unable to find any usenet posts, web pages, etc. detailing a
problem of not having the log available at all. I have confirmed that
suexec is starting w/ apache, via my general error log.
Also, if I shut apache down, rename sbin/suexec to something else,
restart apache then the .cgi's in user subdirs will work again (
~frankie/test.cgi etc.) but a dump shows that the uid/gid are what is
defined in my unified httpd.conf . . .
Any pointers appreciated. I think if I could see any log errors
("Premature end of script headers: /home/frank/www/test.cgi" doesn't
tell me enough, so I don't count this) I could probably figure it out.
Best, John.
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[BugDB] dbm cache doesn't work (PR#62)
Full_Name: Andreas Karajannis Version: 2.1.x OS: Linux (RH 4.2, 5.1) Submission from: kara.gmd.de (129.26.240.27) There seem to be problems with the dbm support. mod_ssl isn't able to write to the database. Directory Permissions are correct, the files ssl_scache_data.dir and ssl_scache_data.pag are created on first server start, but not ssl_cache_data. Excerpt from ssl_engine.log follows: [04/Dec/1998 16:57:54] [error] Cannot open SSLSessionCache DBM file `/usr/local/apache/var/run/ssl_scache_data' for writing (store) (System error follows) [04/Dec/1998 16:57:54] [error] System: Permission denied (errno: 13) __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
mod_ssl: Cannot open SSLSessionCache DBM file `/usr/local/apache/var/run/ssl_scache'
Hi, I use mod_ssl-2.1.2-1.3.3 and apache_1.3.3 on Red Hat 5.1 (Kernel 2.0.34 on an i686) box. After compiling and installing apache I have started apache with /usr/local/apache/sbin/apachectl startssl. The file /usr/local/apache/var/run/ssl_scache does not exist;-) The server (http,https) function well but the error_log file says: [Sat Dec 5 14:04:20 1998] [error] System: Permission denied (errno: 13) [Sat Dec 5 14:04:20 1998] [error] mod_ssl: Cannot open SSLSessionCache DBM file `/usr/local/apache/var/run/ssl_scache' for writing (store) (System error follows) Waht is the problem? Fredj __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: mod_ssl: Cannot open SSLSessionCache DBM file `/usr/local/apache/var/run/ssl_scache'
On Sat, Dec 05, 1998, Fredj Dridi wrote: > I use mod_ssl-2.1.2-1.3.3 and apache_1.3.3 on Red Hat 5.1 (Kernel 2.0.34 > on an i686) box. After compiling and installing apache I have started > apache with /usr/local/apache/sbin/apachectl startssl. The file > /usr/local/apache/var/run/ssl_scache does not exist;-) The server > (http,https) function well but the error_log file says: > > [Sat Dec 5 14:04:20 1998] [error] System: Permission denied (errno: 13) > [Sat Dec 5 14:04:20 1998] [error] mod_ssl: Cannot open SSLSessionCache > DBM file `/usr/local/apache/var/run/ssl_scache' for writing (store) > (System error follows) > > Waht is the problem? The problem is that you're using an old config file. In mod_ssl 2.1 SSLSessioCache's arg now is a path to a DBM file and no longer a path to a program (as in mod_ssl 2.0.x). Just change the argument to point to a reasonable file inside your logs or runtime dirs. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ANNOUNCE: mod_ssl 2.1.3 (Global ID, APXS)
Beside a few bugfixes and documentation cleanups, this version brings you two
new interesting features: First support for client-initiated SSL renegotation
and this way support for Verisign's Global Server ID facility. And second
support for APXS (Apache's extension tool for the DSO situation) which can be
used to easily upgrade the libssl.so.
Greetings,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
Changes with mod_ssl 2.1.3 (03-Nov-1998 to 05-Dec-1998)
*) Added APXS support: By using the --with-apxs option you can now easily
upgrade the libssl.so file through a stand-alone build process as long
as you actually use DSO and EAPI doesn't change. In other words, a
simple `./configure --with-apxs=/path/to/apache/sbin/apxs
--with-ssleay=/path/to/your/ssleay; make install' can be used to upgrade
the /path/to/apache/libexec/libssl.so.
*) Added support documenation, programs and scripts for the `Global Server
ID' facility as README.GlobalID, pkg.contrib/gid-mkcert.sh,
pkg.contrib/gid-tagcert.c and pkg.contrib/loadcacert.cgi. This way
people can setup their own private `Global Server ID' stuff :)
*) Allowed SSL renegotiations initiated by the client.
This especially adds support for Verisign's `Global Server ID' facility
where Netscape Communicator does a renegotiation to upgrade the SSL
connection parameters (the cipher) from 40-bit to 128-bit encryption.
*) Fix typo in httpd.conf-dist: `' -> `'
*) Added new README.dsov.{fig,ps} files: They are intended for those people
who want to hack theirself inside the mod_ssl source. The figure
provides two diagrams which show the lifetime and chaining of the
various Apache, mod_ssl and SSLeay data structures which are used inside
mod_ssl.
*) Cleaned up some documents.
*) Cleaned up ssl_engine_compat.c a little bit more...
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [BugDB] dbm cache doesn't work (PR#62)
On Sat, Dec 05, 1998, [EMAIL PROTECTED] wrote:
> Full_Name: Andreas Karajannis
> Version: 2.1.x
> OS: Linux (RH 4.2, 5.1)
> Submission from: kara.gmd.de (129.26.240.27)
>
> There seem to be problems with the dbm support. mod_ssl isn't able
> to write to the database. Directory Permissions are correct, the files
> ssl_scache_data.dir and ssl_scache_data.pag are created on first
> server start, but not ssl_cache_data.
>
> Excerpt from ssl_engine.log follows:
>
> [04/Dec/1998 16:57:54] [error] Cannot open SSLSessionCache DBM file
> `/usr/local/apache/var/run/ssl_scache_data' for writing (store)
> (System error follows)
> [04/Dec/1998 16:57:54] [error] System: Permission denied (errno: 13)
ssl_cache_data will be _never_ created. That's the nature of DBM libraries:
When you open a file "XXX" or write to "XXX" always just XXX.{pag,dir} are
accessed and "XXX" is not used. At least for the usual NDBM libs out there I
know of. So, it's more a permission problem on the .pag/.dir files itself.
Make sure they're owned by the user under which Apache runs (e.g. nobody), not
the user which starts Apache (root) and that this user can write to it. On my
FreeBSD system (there .pag/.dir are not used, only a single .db because
FreeBSD uses DB/1.85) the permissions on the DBM file look like this:
-rw-r--r-- 1 nobody wheel 16384 Dec 2 10:39 apache.ssl_cache.db
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
