Mailing List Archive

On Mon, May 24, 2004 at 09:21:05PM -0400, Nikolaos Papavassiliou wrote:
> # ./conserver -d
> [Mon May 24 19:45:13 2004] conserver (7111): conserver.com version 8.1.5
> [Mon May 24 19:45:13 2004] conserver (7111): started as `root' by `niko'
> [Mon May 24 19:45:13 2004] conserver (7111): ERROR: SetupSSL(): could
> not load SSL certificate from `/opt/conserver/ssl-cred'
>
> The manual page for conserver says that if encryption is built into the
> code then encrypted connections
> (without certificate exchanges) happen by default. What am I missing here?
> Do I really have to create those certificates? Has anyone made this work
> without certificates?

does your conserver.cf have an 'sslcredentials' entry pointing to
/opt/conserver/ssl-cred? almost has to, based on what it's showing. if
you include that option, the file needs to exist, be valid, etc. if you
comment that line out, then, yes, ssl should encrypt the connections
without certs.

hopefully that explains things.

Bryan

On Mon, 24 May 2004, Nikolaos Papavassiliou wrote:

> Do I really have to create those certificates? Has anyone made this work
> without certificates?
>

I can confirm now that it works fine with SSL and no certs.

OTOH, I did discover that if you run ./configure --with-openssl and
./configure can't seem to make openssl work, it will happily continue to
build, removing the openssl option and issue no errors :( Is there any
way we can have ./configure either emit a loud warning or simply die if
--with-openssl is specified but the configure tests don't pass?

FWIW, if you're building on Red Hat Enterprise Linux, you'll need to pass:
CFLAGS=-I/usr/kerberos/include to configure in order to make it build with
openssl (as well as have the krb5-devel package installed). For the
people who really care, this is already bugzilla'ed:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119500

-n

--
-------------------------------------------
nathan hruby <nhruby@uga.edu>
uga enterprise information technology services
production systems support
metaphysically wrinkle-free
-------------------------------------------

On Tue, May 25, 2004 at 08:43:55AM -0400, nathan r. hruby wrote:
> OTOH, I did discover that if you run ./configure --with-openssl and
> ./configure can't seem to make openssl work, it will happily continue to
> build, removing the openssl option and issue no errors :( Is there any
> way we can have ./configure either emit a loud warning or simply die if
> --with-openssl is specified but the configure tests don't pass?

personally, i'm a fan of having it continue if it can't find the
necessary files (and my experience with other configure-based apps says
that's the "normal" way of behaving, though i have seen some abort. the
whole idea for using configure is to auto-detect what it can and just
live with the results). but, i do believe it would be nice to see what
happened in a nice, concise way. so, how about a summary at the end of
the configure run:

config.status: creating contrib/chat/Makefile
config.status: creating conserver/conserver.rc
config.status: creating config.h
config.status: config.h is unchanged
==============================================================
Feature Summary

Unix domain sockets (--with-uds) : YES
TCP wrappers (--with-libwrap): NO
OpenSSL (--with-openssl): NO
dmalloc (--with-dmalloc): NO
PAM support (--with-pam) : YES

==============================================================

Bryan

On Tue, 25 May 2004, Bryan Stansell wrote:

> On Tue, May 25, 2004 at 08:43:55AM -0400, nathan r. hruby wrote:
> > OTOH, I did discover that if you run ./configure --with-openssl and
> > ./configure can't seem to make openssl work, it will happily continue to
> > build, removing the openssl option and issue no errors :( Is there any
> > way we can have ./configure either emit a loud warning or simply die if
> > --with-openssl is specified but the configure tests don't pass?
>
> personally, i'm a fan of having it continue if it can't find the
> necessary files (and my experience with other configure-based apps says
> that's the "normal" way of behaving, though i have seen some abort. the
> whole idea for using configure is to auto-detect what it can and just
> live with the results). but, i do believe it would be nice to see what
> happened in a nice, concise way. so, how about a summary at the end of
> the configure run:
>
[snip]

Looks great, works for me!

-n
--
-------------------------------------------
nathan hruby <nhruby@uga.edu>
uga enterprise information technology services
production systems support
metaphysically wrinkle-free
-------------------------------------------

Bryan Stansell wrote:

>does your conserver.cf have an 'sslcredentials' entry pointing to
>/opt/conserver/ssl-cred? almost has to, based on what it's showing. if
>you include that option, the file needs to exist, be valid, etc. if you
>comment that line out, then, yes, ssl should encrypt the connections
>without certs.
>
>hopefully that explains things.
>
>Bryan
>
>
Many thanks Bryan. You were quite correct about it. I had this defined
in the
conserver.cf file, not realizing that it will complain if they are not
there. After I
removed it it seemed to start the server withno errors. However, I fell
into another
problem... Now the client (console) refuses to connect to a console and
fails
with SSL connection negotiation errors.

=======
% console nycilab12
console: SSL negotiation failed
%
=======

Looking at the debug info from the serverlog I see the following:

=======
DEBUG: [cutil.c:2019] FileSSLAccept(): about to SSL_accept() for fd 6
DEBUG: [main.c:301] TmpDHCallback(): asked for a DH key length 1024
ERROR: FileSSLAccept(): SSL error on fd 6
=======

Any clues on this?

Thanks!!!
Niko

>_______________________________________________
>users mailing list
>users@conserver.com
>https://www.conserver.com/mailman/listinfo/users
>
>
>
>




-----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.

On Tue, May 25, 2004 at 03:12:45PM -0400, Nikolaos Papavassiliou wrote:
> removed it it seemed to start the server withno errors. However, I fell
> into another
> problem... Now the client (console) refuses to connect to a console and
> fails
> with SSL connection negotiation errors.
>
> =======
> % console nycilab12
> console: SSL negotiation failed
> %
> =======

are there any other things produced after the "SSL negotiation failed"
message? there's a call to ERR_print_errors_fp() right after that in
the code that should dump the SSL layer error stack (though i can't
verify that). if it's not printing anything, then i guess there are no
errors to report (which is weird...since it failed to connect properly).

>
> Looking at the debug info from the serverlog I see the following:
>
> =======
> DEBUG: [cutil.c:2019] FileSSLAccept(): about to SSL_accept() for fd 6
> DEBUG: [main.c:301] TmpDHCallback(): asked for a DH key length 1024
> ERROR: FileSSLAccept(): SSL error on fd 6
> =======
>
> Any clues on this?

except for the last line, all looks normal. all the real magic happens
inside the openssl package. makes me wonder if your openssl library is
configured properly or if the host is missing something (like entropy).
but, it could be conserver as well. i'm lacking on clues, however.

if things fail with 'ERROR: FileSSLAccept(): SSL error on...' every
time, i suggest adding a 'ERR_print_errors_fp(stderr);' to
conserver/cutil.c - right between lines 2032 and 2033 (which means,
right after the line of code that produces the error above). that
should dump more openssl clues to stderr (or the logfile if it's been
redirected to a file). *maybe* it'll tell us something useful.

i'm on a sun (ultra 2) running solaris 9 with openssl 0.9.7d, so, in
theory, we're pretty much the same. it "just works" for me. i'm using
gcc 3.3.3 compiling 32-bit binaries. you doing the same? if there's no
basic openssl setup problem, maybe it's a compilation thing.

those are my current thoughts...if anyone else has ideas, please yell!

Bryan

Hi Bryan,

Thanks for all the pointers and help. I was finally able to make this
work by recompiling
the ssl package, and then recompiling conserver. I have no idea what
went wrong with the
first ssl installation, but it seems to be much better now.

In the process, I also discovered an error in the makefile for conserver
(again, Solaris 9
on an Ultra1, and gcc-2.95.3). This error was reproduced on both 8.1.5
qnd 8.1.6 versions
of conserver. If I am doing something wrong please let me know. Here is
the situation:

If I configure conserver to include tcpwrappers with libwrap, the
linking of "convert" breaks.
It appears that the inclusion of -lwrap on the LIBS line in the
Makefile in the conserver
directory, does not agree with convert and, as you can see from the
output that follows
it breaks during linking. To fix this I assumed that -lwrap is not
needed for convert and
edited the makefile to include a second LIBS line (LIBS2) without the
-lwrap, and fixed the
convert line to include LIBS2 intead of LIBS. I am cutting and pasting
below:

========================= Configure proceeds correctly
==============================

./configure --prefix=/opt/conserver --with-pam
--with-openssl=/opt/local/ssl --with-libwrap=/usr/sfw --with-trustrevdns

========================= Make causes an Error
===================================
% make all
for n in conserver console conserver.cf; do \
( cd $n && make all ) || exit 1; \
done
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o access.o access.c
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o client.o client.c
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o consent.o consent.c
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o group.o group.c
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o main.o main.c
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o master.o master.c
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o readcfg.o readcfg.c
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o fallback.o fallback.c
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o cutil.o cutil.c
gcc -O -L/opt/local/ssl/lib -L/usr/sfw/lib -o conserver access.o
client.o consent.o group.o main.o master.o readcfg.o fallback.o cutil.o
-lbsm -lnsl -lsocket -lssl -lcrypto -lwrap -lpam
gcc -O -I.. -I.. -I. -DHAVE_CONFIG_H
-DSYSCONFDIR=\"/opt/conserver/etc\" -I/opt/local/ssl/include
-I/usr/sfw/include -c -o convert.o convert.c
gcc -O -L/opt/local/ssl/lib -L/usr/sfw/lib -o convert convert.o cutil.o
-lbsm -lnsl -lsocket -lssl -lcrypto -lwrap -lpam
Undefined first referenced
symbol in file
deny_severity /usr/sfw/lib/libwrap.so
allow_severity /usr/sfw/lib/libwrap.so
ld: fatal: Symbol referencing errors. No output written to convert
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `convert'
Current working directory
/home/niko/Software/Downloads/Solaris/t_ser/conserver-8.1.6/conserver
*** Error code 1
make: Fatal error: Command failed for target `all'

=========================== Make Fix
========================================================

.....
LIBS = -lbsm -lnsl -lsocket -lssl -lcrypto -lwrap -lpam
LIBS2 = -lbsm -lnsl -lsocket -lssl -lcrypto -lpam
....
convert: convert.o cutil.o
$(CC) $(CFLAGS) $(LDFLAGS) -o convert convert.o cutil.o $(LIBS2)

========================== End
============================================================


I have been using conserver since version 6.1.7 which I stumbled upon
when looking for something
like this on the web, about 4 years ago. I think it is a great package
and I appreciate all the effort you
are putting into this.

Thanks again.

Niko



Bryan Stansell wrote:

>On Tue, May 25, 2004 at 03:12:45PM -0400, Nikolaos Papavassiliou wrote:
>
>
>>removed it it seemed to start the server withno errors. However, I fell
>>into another
>>problem... Now the client (console) refuses to connect to a console and
>>fails
>>with SSL connection negotiation errors.
>>
>>=======
>>% console nycilab12
>>console: SSL negotiation failed
>>%
>>=======
>>
>>
>
>are there any other things produced after the "SSL negotiation failed"
>message? there's a call to ERR_print_errors_fp() right after that in
>the code that should dump the SSL layer error stack (though i can't
>verify that). if it's not printing anything, then i guess there are no
>errors to report (which is weird...since it failed to connect properly).
>
>
>
>>Looking at the debug info from the serverlog I see the following:
>>
>>=======
>>DEBUG: [cutil.c:2019] FileSSLAccept(): about to SSL_accept() for fd 6
>>DEBUG: [main.c:301] TmpDHCallback(): asked for a DH key length 1024
>>ERROR: FileSSLAccept(): SSL error on fd 6
>>=======
>>
>>Any clues on this?
>>
>>
>
>except for the last line, all looks normal. all the real magic happens
>inside the openssl package. makes me wonder if your openssl library is
>configured properly or if the host is missing something (like entropy).
>but, it could be conserver as well. i'm lacking on clues, however.
>
>if things fail with 'ERROR: FileSSLAccept(): SSL error on...' every
>time, i suggest adding a 'ERR_print_errors_fp(stderr);' to
>conserver/cutil.c - right between lines 2032 and 2033 (which means,
>right after the line of code that produces the error above). that
>should dump more openssl clues to stderr (or the logfile if it's been
>redirected to a file). *maybe* it'll tell us something useful.
>
>i'm on a sun (ultra 2) running solaris 9 with openssl 0.9.7d, so, in
>theory, we're pretty much the same. it "just works" for me. i'm using
>gcc 3.3.3 compiling 32-bit binaries. you doing the same? if there's no
>basic openssl setup problem, maybe it's a compilation thing.
>
>those are my current thoughts...if anyone else has ideas, please yell!
>
>Bryan
>_______________________________________________
>users mailing list
>users@conserver.com
>https://www.conserver.com/mailman/listinfo/users
>
>
>-----------------------------------------------------------------
> Visit our Internet site at http://www.reuters.com
>
>Get closer to the financial markets with Reuters Messaging - for more
>information and to register, visit http://www.reuters.com/messaging
>
>Any views expressed in this message are those of the individual
>sender, except where the sender specifically states them to be
>the views of Reuters Ltd.
>
>


-----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.

On Wed, May 26, 2004 at 07:23:55PM -0400, Nikolaos Papavassiliou wrote:
> the ssl package, and then recompiling conserver. I have no idea what
> went wrong with the
> first ssl installation, but it seems to be much better now.

that's pretty wild. glad you got it to work, though!

> In the process, I also discovered an error in the makefile for conserver
> (again, Solaris 9
> on an Ultra1, and gcc-2.95.3). This error was reproduced on both 8.1.5
> qnd 8.1.6 versions
> of conserver. If I am doing something wrong please let me know. Here is
> the situation:

yep...that's a bug. thanks for catching it and providing all the
details (sure helps, since i don't use that). i'll make sure the fix is
in 8.1.7.

> I have been using conserver since version 6.1.7 which I stumbled upon
> when looking for something
> like this on the web, about 4 years ago. I think it is a great package

wow! so you've definitely suffered through some of the good, the bad,
and the ugly versions. i hope you find 8.1.6 nice and stable now that
the kinks have been worked out.

Bryan