Re: [john@cavaliers.org: proxy_http1.1_chunking.patch]

2002-05-02 Thread Graham Leggett

Martin Kraemer wrote:

 Ralf, do you have a mod_ssl patch for the current 1.3.25-dev proxy? Or
 could you make one?

Is 1.3.25 not due for release already?

Regards,
Graham
-- 
-
[EMAIL PROTECTED]There's a moon
over Bourbon Street
tonight...


smime.p7s
Description: S/MIME Cryptographic Signature


Re: HTTP fails, HTTPS works

2000-04-18 Thread Graham Leggett

Dan Kuykendall wrote:

 So at this point I have to choose between HTTP and HTTPS. The two just
 wont work together. Apache doesnt even log connection attempts, because
 it doesnt even seem to have the port open.
 
 Does anyone know why this is happening?

HTTP and HTTPS definitely do work on the same server - we are doing it
here.

Make sure that your server is configured correctly. You need to
configure two different virtual hosts, one for normal bound to port 80,
the second for SSL, bound to port 443. The normal virtualhost should
have "SSLEngine off", and the SSL virtualhost should have "SSLEngine on"
along with other config directives giving the certificate names, etc.
Make sure that in your global config, SSLEngine is off.

Regards,
Graham
--
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



SSL Proxy support - backend through a proxy?

2000-04-12 Thread Graham Leggett

Hi all,

After switching on the experimental code in mod_ssl, it becomes possible
to connect to an SSL webserver on the backend using mod_proxy and
ProxyPass.

I need though to connect to a backend SSL server through an HTTP proxy -
is mod_ssl's mod_proxy integration capable of using the CONNECT method?

An example:

ProxyRemote connect http://s-proxy.somewhere.com:3128
ProxyPass   /   https://www.webserver.com:443/

Is this possible?

Regards,
Graham
--
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: Name based virtual hosts

2000-03-16 Thread Graham Leggett

Martin Helie wrote:

 I seem to have read something about apache and modssl not being too friendly
 towards name based virtual hosts, but was wondering if anyone had more
 info...

It's not specifically apache and modssl, but also other webserver
software as well.

The trouble is the way name based virtual hosts work - a connection is
made, then the Host: header is used to determine which site you are
talking about. When you make an SSL connection, the decision on whether
the connection should be allowed or not is done when the connection is
made. At this point, the webserver does not know yet what server you are
trying to access, and so cannot make a proper decision on whether the
connection should proceed or not.

 So far, I have been able to allow _one_ virtual host to access port 443, but
 if I enable SSL for any other vhosts, things get kind of weird.
 
 Are my only options to get IP addresses for each host, or run multiple
 instances of httpd configured differently? Any other ideas?

Use one IP address for each host. There is no need to run multiple httpd
daemons, just one installation can serve multiple secure hosts and
multiple Ip addresses.

Regards,
Graham
--
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: [error] mod_ssl: Init: Failed to generate temporary 512 bit RSA private key

2000-03-09 Thread Graham Leggett

"Ralf S. Engelschall" wrote:

  [Tue Mar  7 17:42:46 2000] [error] mod_ssl: Init: Failed to generate
  temporary 512 bit RSA private key
 
 FAQ: http://www.modssl.org/docs/2.6/ssl_faq.html#entropy

Cool thanks - didn't realise it'd be this easy :)

Regards,
Graham
--
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



[error] mod_ssl: Init: Failed to generate temporary 512 bit RSA private key

2000-03-07 Thread Graham Leggett

Hi all,

I just upgraded an Apache v1.3.9 + mod_ssl v2.4.10 installation to
Apache v1.3.12 and mod_ssl v2.6.2. I stopped the server, and then
restarted it again, but the new server would not start up - it gave the
error:

[Tue Mar  7 17:42:46 2000] [error] mod_ssl: Init: Failed to generate
temporary 512 bit RSA private key

Does anyone know why this might be the case?

I also upgraded OpenSSL from v0.9.4 to 0.9.5, would this have broken
anything?

Regards,
Graham
--
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: Certificates

2000-02-16 Thread Graham Leggett

Robert Richart wrote:

 I'm a librarian in charge of a Solaris server. The library wants to
 offer some services requiring ssl (e.g. forms requiring social security
 numbers). I have installed an Apache web server with mod-ssl and created
 my own certificate, but we will need an official certificate to make
 this work properly. The University IS Dept. tells me that SSL
 Certificates are a big hassle and it would be a mistake for the library
 to try to maintain one. They have had major problems with certificates.
 They are a totally NT shop. The library has the only UNIX server on
 campus. So my question is, are there problems with maintaining an SSL
 Certificate on a Solaris box? Or are these problems only related to
 Microsoft incompatibilities? Does anyone have recommendation about
 signing authorities? Verisign or Thawte? Thanks.

From a technical point of view, certificates require zero maintenance,
and their generation is pretty straitforward if you follow the
instructions.

In our experience the difficult part about certificates is the
administration issue - you need to prove to the cert authority that a)
you are who you say you are, b) that you own the domain name that you
want a cert for, and c) you are authorised by the company to get the
cert. This generally involves a whole lot of bureaucracy and red tape
and is rather frustrating, but fortunately it only needs to be done
once.

When we bought certs from Thawte, we followed the step by step process
they offer on their website that isn't that complicated. Your IT
department seems to be making a bigger issue out of it than necessary.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: Question:Child could not open SSLMutex...

2000-02-15 Thread Graham Leggett

Hankyu Joo wrote:

 I just installed mod_ssl.
 When I started the httpd server(./apachectl startssl),
 there was error messages in error_log saying
 "Child could not open SSLMutex lockfile logs/ssl_mutex.17472".
 
 Would you tell me how to fix it?

The first things to check are whether the directory exists, and that the
Apache user (usually nobody) can write to that directory.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: I want to have my cake and eat it!

2000-01-26 Thread Graham Leggett

"Airey, John" wrote:

 1. I want to be able to have users who access to systems over the internet
 authenticated using TACACS+. I've been down the route of trying to get a
 Cisco router to authenticate, but these only support http, ftp and telnet. I
 want to authenticate them using https for security purposes.

You want a TACACS+ auth module for Apache.

A search at http://module.apache.org for "tacacs" gives this:

http://duke.adesium-services.fr/pub/mod_auth_tacacs/

 2. I also want to be able to integrate NT and Samba on several Linux servers
 so that users who have access to change files can be administered as part of
 the NT domain. I have a Samba book that explains how to do this, however I
 would like a way of combining this with a TACACS+ server.
 
 Does anyone know of a way I can integrate either of these? I realise the
 second is off-topic for this mailing list, however I'm looking to use
 Apache-mod_ssl to reduce the number of user databases that I need to support
 and increase security.

A far easier way of doing this would be to standardise on LDAP. Apache
can authenticate against LDAP (using the relevant module), not sure if
the cisco stuff can, but I would be surprised if it can't. Samba can
support LDAP, or even support PAM with a PAM LDAP module.

There are many ways of doing this, though I would suggest choosing your
base level authentication database carefully so that you don't find
incompatibility problems down the line.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: php problems

1999-12-17 Thread Graham Leggett

Blair Lowe wrote:

 I got the latest apache mod_ssl mod_php mod_perl to compile and run cleanly.
 
 Here comes my problem.
 
 php scripts don't work.
 
 So I tried to add a Load Module directive as per the php instructions:
 
 /etc/rc.d/init.d/httpd start
 Starting httpd: Syntax error on line 208 of /etc/httpd/conf/httpd.conf:
 Invalid command 'LoadModule', perhaps mis-spelled or defined by a
 module not included in the server configuration
 [FAILED]
 
 I added the AddTypes directove and the AddModule httpd.conf
 directives with no luck, and when I run httpd without the Loadmodule
 everything works except php *I haven't tried perl either*.

I could be wrong, but from the compilation script you gave it looks like
you are not compiling Apache with module support, but are rather
building everything into a monolithic Apache binary.

If this is the case then there is no such config option as LoadModule,
because there is no module support.

Drop the "LoadModule" option and try the feature to see if it works.
Otherwise modify your build script to compile everything with DSO
support.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: intermediate CA status?

1999-12-10 Thread Graham Leggett

Hakan Tandogan wrote:

 We are designing a Web-bases application that will use client
 certificates as an alternate possibility of authentification. There seem to be
 xxx options.
 
 First, we could create our own CA and assign the users self-generated
 certificates. This has the drawback that the user get all those warning dialogs
 (our user will most likely be the non-technical, easy-to-panic type).

You mixing up server certificates with client certificates.

If you give yourself a self-generated certificate and install it on your
server, then yes - your easy-to-panic client browsers will throw
warnings all over the show, as they should, because their browsers do
not trust you or the authority (also you) that signed your certificate.

In the case of the client certificates it's all the other way round. If
any warnings will be thrown, it will be your server that starts to shout
and scream (in the form of denying access to clients). But then your
server is completely under your control and your trust, and you will
tell your server to trust all certificates signed by you anyway, so
there is no problem.

 Another possibility would be to have them get certificates from, say,
 thawte. We would map those certificates to our internal database. Downside: the
 users will have to go to another server they possibly know nothing about.
 Remember that they are most likely non-technical people.

Companies like Thawte offer to issue client certificates for people who
do not want to do the job themselves, either because they don't want to
understand the process, or because they don't trust themselves to do the
job properly.

It is quite possible (and recommended if you're paranoid) to generate
and issue the certs yourself. You trust yourself, after all. It's the
most secure way.

But - it's only secure if you approach the issuing of the certificates
properly. If you cert-generating equipment is left unprotected, or if
you do not verify the identity of the people you hand your certs out to,
then all security is lost.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Adding mod_jserv to Apache+mod_ssl

1999-12-09 Thread Graham Leggett

Hi all,

I am tasked with adding mod_jserv to my previously baked installation of
Apache+mod_ssl+mod_perl. After following the DSO instructions for
mod_jserv, the installation is successful, but a configtest says this:

[root@force ApacheJServ-1.1b3]# /opt/local/apache/bin/apachectl
configtest
[Thu Dec  9 14:39:42 1999] [warn] Loaded DSO libexec/mod_jserv.so uses
plain Apache 1.3 DSO, this module might crash under EAPI!
Syntax OK

It seems EAPI needs to be added to mod_jserv. Is there a way to do this?

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: Adding mod_jserv to Apache+mod_ssl

1999-12-09 Thread Graham Leggett

"Ralf S. Engelschall" wrote:

  It seems EAPI needs to be added to mod_jserv. Is there a way to do this?
 
 I don't know how the JServ people compile their stuff,
 but seems like they aren't using apxs or messing up something.
 Make sure -DEAPI is present on the compile commands.

The claim to be using apxs:

checking for apxs... /opt/local/apache/bin/apxs, assume Apache 1.3 with
DSO support

But there is no evidence of the -DEAPI:

/bin/sh ../../libtool --mode=compile gcc -DPACKAGE=\"ApacheJServ\"
-DVERSION=\"1.1b3\" -DSTDC_HEADERS=1 -DTIME_WITH_SYS_TIME=1
-DSTDC_HEADERS=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_HTTPD_H=1
-DHAVE_HTTP_CONFIG_H=1 -DHAVE_HTTP_CORE_H=1 -DHAVE_HTTP_LOG_H=1
-DHAVE_HTTP_MAIN_H=1 -DHAVE_HTTP_PROTOCOL_H=1 -DHAVE_UTIL_SCRIPT_H=1
-DHAVE_UTIL_MD5_H=1 -DHAVE_OS_INLINE_C=1  -I. -I.   
-I/opt/local/apache/include  -g -O2 -c jserv_protocols.c

Their build system is pretty broken, make install only works once, and
make distclean doesn't work at all. Adding the Apache source code to the
build as documented breaks make.

Oh well... off to their list.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: [BugDB] mod_ssl dumps core with auth_ldap (PR#319)

1999-11-02 Thread Graham Leggett

[EMAIL PROTECTED] wrote:

 When we installed mod_ssl it worked fine until we loaded in Dave Carrigan's
 auth_ldap (found at http://www.rudedog.org).  I'd tested the auth_ldap without
 mod_ssl and it works and I've tested it with and it doesn't.  For the record, we
 are compiling the auth_ldap for ssl support over ldaps.

I had something like this, if memory serves moving auth_ldap to the
first module in the list was a workaround, I haven't had a chance yet to
pinpoint the problem though, so I don't have a fix.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: RSE back / 2.4.6 prepared / feedback appreciated

1999-10-19 Thread Graham Leggett

"Ralf S. Engelschall" wrote:

 So, while I'm busy with moving this week, please take the chance and fetch the
 latest snapshot from ftp://ftp.modssl.org/snapshot/ and try it out. It should
 be very stable. Please give feedback whether it works fine or fails horrible
 until Friday.

I just went through the compilation process, and tried to start the
server up after upgrading. The server startup complained that I did not
have shared memory support compiled in, and I should change the shm:
references.

I thought I did compile in shared memory support - can anyone see if I
did anything stupid here?

I issued the following configure command to mod_ssl:

[7:52pm] root@infobase:~/apache-tmp/mod_ssl-SNAP-19991019# ./configure
--with-apache=../apache_1.3.9 --with-ssl=../openssl-0.9.4
--with-mm=../mm-1.0.9 
Configuring mod_ssl/2.4.6 for Apache/1.3.9
 + Apache location: ../apache_1.3.9 (Version 1.3.9)
 + OpenSSL location: ../openssl-0.9.4
 + MM location: ../mm-1.0.9
 + Auxiliary patch tool: ./etc/patch/patch (local)
 + Applying packages to Apache source tree:
   o Extended API (EAPI)
   o Distribution Documents
   o SSL Module Source
   o SSL Support
   o SSL Configuration Additions
   o SSL Module Documentation
   o Addons
Done: source extension and patches successfully applied.

Configuring for Apache, Version 1.3.9
 + using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
 + configured for Solaris 260 platform
 + setting C compiler to gcc
 + setting C pre-processor to gcc -E
 + checking for system header files
 + adding selected modules
o ssl_module uses ConfigStart/End
  + SSL interface: mod_ssl/2.4.6
  + SSL interface build type: OBJ
  + SSL interface compatibility: enabled
  + SSL interface experimental code: disabled
  + SSL interface vendor extensions: disabled
  + SSL interface plugin: Vendor DBM (libc)
  + SSL library path:
/home/infobase/dsngrle/apache-tmp/openssl-0.9.4
  + SSL library version: OpenSSL 0.9.4 09 Aug 1999
  + SSL library type: source tree only (stand-alone)
  + SSL library plugin mode: none
 + enabling Extended API (EAPI)
   using MM library: ../../mm-1.0.9 (source-tree only)
 + checking sizeof various data types
 + doing sanity check on compiler and options
Creating Makefile in src/support
Creating Makefile in src/os/unix
Creating Makefile in src/ap
Creating Makefile in src/main
Creating Makefile in src/lib/expat-lite
Creating Makefile in src/modules/standard
Creating Makefile in src/modules/ssl

Because I am trying to install mod_perl as well, I follow the
instructions given in the mod_ssl INSTALL file for apache + mod_ssl +
mod_perl and I need to run the Apache ./configure again, like so:

[7:59pm] root@infobase:~/apache-tmp/apache_1.3.9# ./configure
--prefix=/opt/local/apache --enable-module=most --enable-shared=max
--enable-module=ssl --activate-module=src/modules/perl/libperl.a
--enable-module=perl
Configuring for Apache, Version 1.3.9
 + using installation path layout: Apache (config.layout)
 + activated perl module (modules/perl/libperl.a)
Creating Makefile
Creating Configuration.apaci in src
 + enabling mod_so for DSO support
Creating Makefile in src
 + configured for Solaris 260 platform
 + setting C compiler to gcc
 + setting C pre-processor to gcc -E
 + checking for system header files
 + adding selected modules
o rewrite_module uses ConfigStart/End
  enabling DBM support for mod_rewrite
o dbm_auth_module uses ConfigStart/End
o ssl_module uses ConfigStart/End
  + SSL interface: mod_ssl/2.4.6
  + SSL interface build type: DSO
  + SSL interface compatibility: enabled
  + SSL interface experimental code: disabled
  + SSL interface vendor extensions: disabled
  + SSL interface plugin: Vendor DBM (libc)
  + SSL library path: /usr/local/ssl
  + SSL library version: OpenSSL 0.9.4 09 Aug 1999
  + SSL library type: installed package (stand-alone)
  + SSL library plugin mode: none
 + enabling Extended API (EAPI)
 + using -ldl for vendor DSO support
 + checking sizeof various data types
 + doing sanity check on compiler and options
Creating Makefile in src/support
Creating Makefile in src/os/unix
Creating Makefile in src/ap
Creating Makefile in src/main
Creating Makefile in src/lib/expat-lite
Creating Makefile in src/modules/standard
Creating Makefile in src/modules/extra
Creating Makefile in src/modules/proxy
Creating Makefile in src/modules/ssl

Is there something else I should be doing?

I am trying to remember what I did when I configured v2.4.5...

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   

ModSSL core dumps

1999-10-13 Thread Graham Leggett

Hi all,

I am getting a few core dumps like so:

[Wed Oct 13 13:45:35 1999] [notice] child pid 14426 exit signal
Segmentation Fault (11)
[Wed Oct 13 14:24:25 1999] [notice] child pid 14977 exit signal
Segmentation Fault (11)
[Wed Oct 13 14:30:27 1999] [notice] child pid 19431 exit signal
Segmentation Fault (11)

There have been a number of bugfixes for various core dumps coming
across the wire recently, anyone know when these fixes will become
available?

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: Apache + mod_ssl exits cleanly on startup

1999-09-01 Thread Graham Leggett

Magnus Stenman wrote:

 I have had similar problems when I tried to load
 mod_perl as a DSO.
 
 My strace showed that my apache exited in a similar manner.
 
 Removing the mod_perl module load from the httpd.conf
 cured the problem, and I have not had time to investigate
 it further since.
 
 Mod_php loads fine, so in my case the problem is mod_perl/DSO
 related (DSO with mod_perl is considered alpha, I believe)

I have just investigated further. The workaround is to place the SSL
module first in the list, then Apache does not die on startup. This
workaround is the exact same workaround recommended by the author of an
auth_ldap module who had the same problem.

This looks to be a general Apache problem.

From the auth_ldap PROBLEMS file it says this:

"On Solaris 2.5.1 and Netscape's LDAP SDK with SSL (libldapssl30.so)
Apache doesn't start, but nothing seems to get logged to the error log.

   Apache is dumping core after a call to dlclose. This only occurs on
   Solaris 2.5.1 when using Netscape's libraries. It appears to be a bug
   with dld on Solaris 2.5.1. One solution is to upgrade to Solaris 2.6
   or later. If that isn't possible, another workaround is to ensure
   that auth_ldap is the first module loaded using the LoadModule
   directive. This can cause problems if you would prefer that auth_ldap
   takes precedence over other auth modules, since normally the last
   module loaded gets called first. You can solve this by adding a
   ClearModuleList directive, then issuing AddModule directives for
   every loaded module, in reverse order that you want them called. Do
   this after the last LoadModule directive."

I've seen this behaviour on Solaris v2.5.1 and Linux v2.2.5 (glibc
v2.1). Anyone have any further ideas on what is causing this?

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Apache + mod_ssl exits cleanly on startup

1999-08-31 Thread Graham Leggett

Hi all,

I am having some hassles with Apache v1.3.9 + mod_ssl v2.4.1 under
Redhat v6.0 (Intel).

When the server is started, the server exits cleanly straight away.
Nothing is logged, or output to stderr or stdout.

An strace reveals that httpd is making a clean exit just after it's
initialised. Anyone know what's wrong?

The strace is attached.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...

execve("./httpd", ["./httpd", "2"], [/* 32 vars */]) = 0
brk(0)  = 0x80b05b8
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat(3, {st_mode=033462, st_size=0, ...}) = 0
mmap(0, 14685, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 114680, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40018000
mprotect(0x40033000, 4088, PROT_NONE)   = 0
mmap(0x40033000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1a000) = 
0x40033000
close(3)= 0
open("/lib/libcrypt.so.1", O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 182972, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40034000
mprotect(0x40039000, 162492, PROT_NONE) = 0
mmap(0x40039000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x4000) = 
0x40039000
mmap(0x4003a000, 158396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x4003a000
close(3)= 0
open("/lib/libdb.so.3", O_RDONLY)   = 3
fstat(3, {st_mode=S_IFCHR|S_ISUID|S_ISGID|0536, st_rdev=makedev(5, 167), ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 234588, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40061000
mprotect(0x40099000, 5212, PROT_NONE)   = 0
mmap(0x40099000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x37000) = 
0x40099000
close(3)= 0
open("/lib/libdl.so.2", O_RDONLY)   = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 11532, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4009b000
mprotect(0x4009d000, 3340, PROT_NONE)   = 0
mmap(0x4009d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 
0x4009d000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4009e000
mmap(0, 974392, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4009f000
mprotect(0x40185000, 32312, PROT_NONE)  = 0
mmap(0x40185000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe5000) = 
0x40185000
mmap(0x4018a000, 11832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 
0) = 0x4018a000
close(3)= 0
munmap(0x40014000, 14685)   = 0
personality(PER_LINUX)  = 0
getpid()= 3491
brk(0)  = 0x80b05b8
brk(0x80b25e0)  = 0x80b25e0
brk(0x80b3000)  = 0x80b3000
brk(0x80b6000)  = 0x80b6000
brk(0x80b9000)  = 0x80b9000
brk(0x80bc000)  = 0x80bc000
brk(0x80be000)  = 0x80be000
shmget(IPC_PRIVATE, 1052672, IPC_CREAT|0x180|0600) = 7936
shmat(7936, 0, 0)   = 0x4018d000
shmctl(7936, IPC_STAT, 0xbaa8)  = 0
getuid()= 0
getgid()= 0
shmctl(7936, IPC_SET, 0xbaa8)   = 0
shmctl(7936, IPC_RMID, 0)   = 0
unlink("/opt/local/apache/logs/httpd.mm.sem") = 0
open("/opt/local/apache/logs/httpd.mm.sem", O_RDWR|O_CREAT, 0600) = 3
getpid()= 3491
stat("/opt/local/apache/bin/suexec", 0xba60) = -1 ENOENT (No such file or 
directory)
open("/opt/local/apache/conf/httpd.conf", O_RDONLY) = 4
fstat(4, {st_mode=030053, st_size=0, ...}) = 0
fstat(4, {st_mode=030053, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
read(4, "##\n## httpd.conf -- Apache HTTP"..., 4096) = 4096
stat("/opt/local/apache", {st_mode=030400, st_size=0, ...}) = 0
read(4, "Config conf/srm.conf\n#AccessCon"..., 4096) = 4096
gettimeofday({936117679, 20980}, NULL)  = 0
getpid()= 3491
open("/etc/resolv.conf", O_RDONLY)  = 5
fstat(5, {st_mode=0410, st_size=0, ...}) = 0
mmap(0, 4096, 

mod_ssl v2.4.1 cores at startup

1999-08-31 Thread Graham Leggett

Hi all,

I have just completed an installation of Apache v1.3.9 + mod_ssl v2.4.1
under Redhat v6.0. 

Enabling the module caused Apache to segfault at startup. Nothing is
logged, no output to stdout, no core file.

Is there a way of telling Apache to produce a core file when it dies so
that I can run a backtrace on this? Or am I looking for the core file in
the wrong place (serverroot/*) or under the wrong name (core)?

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: No common encryption algorithims

1999-08-26 Thread Graham Leggett

"Ralf S. Engelschall" wrote:

 This cipher works only with a DSA server cert, and that's
 what you're using:

Ok.

 So it's clear that you cannot connect with Netscape.  But... e why to
 the hell are people using the DSA certs?  You _HAVE_ to pressed "D" or used
 ALGO=DSA on the "make certificate" procedure. Because else the RSA snakeoil
 cert is used, of course.
 
 Can someone explain me why people with the "no shared cipher" problem are
 using DSA certs? Is there an error in one of our scripts or why do they all
 select the DSA certs?

The "make certifacate" procedure produces both dsa and rsa certs at the
same time. I pointed my installation at the dsa certs as nothing told me
that I shouldn't have done so. Perhaps by default the installation
should not produce the dsa certs, if there was a warning it is possible
that I missed it.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



No common encryption algorithims

1999-08-25 Thread Graham Leggett

Hi all,

I searched the mailing list archive and uncovered some problems in the
past with this, there doesn't seem to be any evidence of a solution.

I installed modssl into Apache by following the instructions inside
INSTALL. The Apache server starts up without a problem. I point Netscape
at my newly configured test SSL enabled virtual host using the default
www.snakeoil.dom certificate. I expect to see a message from Netscape
complaining that the cert isn't recognised as signed by a valid CA and
that it doesn't match the servername, but instead I get an error message
that Netscape cannot negotiate a common encryption algorithm.

My config looks like this:

global:

SSLMutex file:/tmp/apache.ssl.mutex  
SSLPassPhraseDialog builtin   
#SSLSessionCache shm:/opt/local/apache/logs/ssl_gcache_data(512000)
SSLSessionCache dbm:/opt/local/apache/logs/ssl_gcache_data
SSLEngine off
SSLProtocol all
SSLLog /opt/local/apache/logs/ssl_engine_log
SSLLogLevel warn

virtual host:

  SSLEngine on
  SSLCertificateFile /opt/local/apache/conf/ssl.crt/snakeoil-dsa.crt
  SSLCertificateKeyFile /opt/local/apache/conf/ssl.key/snakeoil-dsa.key
SSLVerifyClient none
  SSLVerifyDepth 1
  SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

An attempt to connect to the secure server using s_client looks like
this:

[9:18pm] root@infobase:/opt/local/apache/conf#
/opt/local/ssl/bin/s_client -connect 193.78.100.33:443
CONNECTED(0003)
depth=0 /C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Webserver
[EMAIL PROTECTED]
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Webserver
[EMAIL PROTECTED]
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Webserver
[EMAIL PROTECTED]
   i:/C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Certificate
Authority/CN=Snake Oil [EMAIL PROTECTED]
---
Server certificate
-BEGIN CERTIFICATE-
MIIDnzCCA1ygAwIBAgIBFTALBgcqhkjOOAQDBQAwgakxCzAJBgNVBAYTAlhZMRUw
EwYDVQQIEwxTbmFrZSBEZXNlcnQxEzARBgNVBAcTClNuYWtlIFRvd24xFzAVBgNV
BAoTDlNuYWtlIE9pbCwgTHRkMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3Jp
dHkxFTATBgNVBAMTDFNuYWtlIE9pbCBDQTEeMBwGCSqGSIb3DQEJARYPY2FAc25h
a2VvaWwuZG9tMB4XDTk5MDIyNTEzMjgzMloXDTAwMDIyNTEzMjgzMlowgacxCzAJ
BgNVBAYTAlhZMRUwEwYDVQQIEwxTbmFrZSBEZXNlcnQxEzARBgNVBAcTClNuYWtl
IFRvd24xFzAVBgNVBAoTDlNuYWtlIE9pbCwgTHRkMRcwFQYDVQQLEw5XZWJzZXJ2
ZXIgVGVhbTEZMBcGA1UEAxMQd3d3LnNuYWtlb2lsLmRvbTEfMB0GCSqGSIb3DQEJ
ARYQd3d3QHNuYWtlb2lsLmRvbTCCAbYwggErBgcqhkjOOAQBMIIBHgKBgQDqP04J
h4QoUWqPJZftxsgLdO54hGmvEYr2o2nqMjO/DbVuujr8QDnVWNRveEuVdrx6AftC
chgIvdJS4LTqfvgOmIwsGYylADmycIRlBVHd5q1ocGldkeEBiY+cS5yv8ro1x4DR
Cd0axmhBvTu2BRbippaK7PNALw5xs8eQch0KLQIVAJ8rT8F7NqIRASUjy1Bwx701
zSIfAoGAT5RMEmjJ4HXOJ0GyIKAesFQhOy3gXXUfV4zXTpSMz8cQWfTqxLgVjkvZ
Ct6SYcNmpaRnJyrmUdGD2uSwBcMkXj3G/NI/7n1C6ZuBTt1x6TCQA72nYh0xQaj/
kbmhT2wNyONMx/sZO/WPUr0qvu/012FS2YlKtq3wRM4+XHz7jY0DgYQAAoGAHX6Q
e2/rMmZewuBxGtyyzzRt7UJcc4c8y2JNRctygdxwGsZD06i6reR8l6wIaLFhZl8b
3DkLNvzssTXsOcR7x82bv9vmknLvjQk3FRJvmfpSAPcNRBUk/1L8UKHkfAP6B31A
h7tRlG36W/iBw1cighqTnDxnNDqv6Wgbd7REtxSjFTATMBEGCWCGSAGG+EIBAQQE
AwIAQDALBgcqhkjOOAQDBQADMAAwLQIUTpfmWwLjKYJFFX5p8fvra8No7CwCFQCL
0q3LdCx1EsUtmsgakN6Yru18Fw==
-END CERTIFICATE-
subject=/C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Webserver
[EMAIL PROTECTED]
issuer=/C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil,
Ltd/OU=Certificate Authority/CN=Snake Oil [EMAIL PROTECTED]
---
No client certificate CA names sent
---
SSL handshake has read 1406 bytes and written 293 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol  : TLSv1
Cipher: EDH-DSS-DES-CBC3-SHA
Session-ID:
4F183CB19529E3A19031FF7FA8EEC2790A6997A3139A9B3ED5C3E64C1A5F4CC3
Session-ID-ctx: 
Master-Key:
1D56208BDCC74A34D683292E1B2D0DDDE778D6A9B7246F5A5C33256EE201E36A8D169D129FC587304D9EFB9C1F00A810
Key-Arg   : None
Start Time: 935608696
Timeout   : 300 (sec)
---

Does anyone have any idea what's wrong?

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]



Re: Daemon question - https

1999-01-02 Thread Graham Leggett

"Stephen H. Kapit" wrote:

 My problem has been with getting http and https running at the same time.  I thought 
that installing :80 and
 :443 for each virtual host would do it. But it isn;t working.

That's only part of the setup. Apache will quite happily listen on port
443 if you ask it to, but if you want that port to do SSL as well you
need to specifically tell Apache to enable it on that virtual host.
Apache won't decide that for you.

For example:

SSLEngine off

VirtualHost www.foo.co.uk:80
  DocumentRoot /Web/www.foo.co.uk/web-docs/
  ServerName www.foo.co.uk
/VirtualHost

VirtualHost www.foo.co.uk:443
  SSLEngine on
  SSLCertificateFile
/opt/local/apache/conf/ssl.crt/www.foo.co.uk-rsa.crt
  SSLCertificateKeyFile
/opt/local/apache/conf/ssl.key/www.foo.co.uk-rsa.key
  SSLVerifyClient none
  SSLVerifyDepth 1
  SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
  DocumentRoot /Web/www.foo.co.uk/web-docs/
  ServerName www.foo.co.uk
/VirtualHost

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight...
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]