[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] Problems with SSL/TLS
From: |
Christian Grothoff |
Subject: |
Re: [libmicrohttpd] Problems with SSL/TLS |
Date: |
Thu, 18 Feb 2010 12:37:47 +0100 |
User-agent: |
KMail/1.12.4 (Linux/2.6.31-14-generic; KDE/4.3.5; i686; ; ) |
Jesse,
My best guess is that the reason for your trouble is that the configure script
does not support
"--with-libcurl=/home/jesse/tmp/libLinux"
Try stuff like
export CFLAGS=-I/home/jesse/tmp/libLinux/include
export LDFLAGS=-L/home/jesse/tmp/libLinux/lib
to help the compiler find libcurl. In any case, you should be able to find
the cause by inspecting "config.log" (grep for 'curl' and see what it tries to
do and why it fails).
Best,
Christian
On Thursday 18 February 2010 12:53:19 am Jesse Anderton wrote:
> Christian,
>
> I've finally found time to get back to TLS support in my web server. I'm
> having trouble getting it working either in Linux on an x86 or in Solaris
> on a SPARC. I decided to start tackling the problem by making sure the
> curl TLS tests all pass, so I downloaded and installed openssl and
> libcurl. However, I seem to have done something wrong: MHD's configure
> can't find libcurl.
>
> I'm working in Linux, and have built all these libraries with --prefix
> /home/jesse/tmp/libLinux. If I run:
>
> $ ./configure --prefix /home/jesse/tmp/libLinux --enable-messages
> --enable-curl --with-libgcrypt-prefix=/home/jesse/tmp/libLinux
> --with-libcurl=/home/jesse/tmp/libLinux
>
>
> I get:
>
> ...
> checking for /home/jesse/tmp/libLinux/bin/curl-config... no
> checking whether libcurl is usable... no
> ...
> configure: Configuration Summary:
> Operating System: linux-gnu
> Target directory: /home/jesse/tmp/libLinux
> Messages: yes
> libgcrypt: yes
> libcurl (testing): no, many unit tests will not run
> HTTPS support: yes
>
> configure: HTTPS subsystem configuration:
> Client code dep.: disabled. running some test cases won't be possible
> License : LGPL only
>
>
> Curl is installed, however:
>
> $ /home/jesse/tmp/libLinux/bin/curl-config --version
> libcurl 7.19.7
>
>
> $ /home/jesse/tmp/libLinux/bin/curl-config --feature
> SSL
> IPv6
> libz
> NTLM
>
>
> Any idea what I should check to make configure see the library? For
> reference, I am using libmicrohttpd-0.4.5.
>
> Thanks,
>
> Jesse
>
> On Tue, Jan 5, 2010 at 2:46 PM, Jesse Anderton <address@hidden> wrote:
> > Christian,
> >
> > Thanks a lot for checking this out for me! I'm not sure what I'm doing
> > differently, but now I know that the code should work. I was a little
> > concerned since the documentation for MHD_USE_SSL at
> > http://www.gnu.org/software/libmicrohttpd/microhttpd.html#SEC2 indicates
> > that SSL is not yet supported. Most likely that comment just needs to be
> > updated.
> >
> > Here's what happens when I attempt to duplicate your test:
> >
> > 1. I copied the server.* files you sent along with the latest
> > tlsauthentication.c from svn HEAD into a folder. I added MHD_USE_DEBUG
> > in order to get the output below (it fails either way).
> >
> > 2. I compiled the program like so (using g++ 3.3.3):
> >
> > gcc -o fs tlsauthentication.c -Iinclude -lmicrohttpd -lgcrypt -lgpg-error
> >
> >> -lsocket -lpthread -L~/dev/ext/lib/solaris_gcc3/static
> >
> > Note that I am linking statically, so I had to add a couple more
> > libraries. I am also not using make install (because of company policies)
> > so I have to provide an explicit path to these libraries.
> >
> > 3. I start the program and browse to
> > https://testhost:8888/something.html. The browser appears to wait
> > indefinitely to complete the SSL handshake.
> >
> > 4. I press Enter on the terminal running fs to stop it. The browser
> > immediately gives up. fs outputs the following:
> >
> > Error: Handshake has failed (-28)
> >
> >
> > I tried this with MHD_USE_THREAD_PER_CONNECTION and with
> > MHD_USE_SELECT_INTERNALLY and got the same results in both modes.
> >
> > Perhaps I'm missing a library? I ran ldd on fs so you could compare it
> > to yours and got:
> >
> > $ldd fs
> >
> > libsocket.so.1 => /usr/lib/libsocket.so.1
> >
> > libpthread.so.1 => /usr/lib/libpthread.so.1
> >
> > libc.so.1 => /usr/lib/libc.so.1
> >
> > libnsl.so.1 => /usr/lib/libnsl.so.1
> >
> > libdl.so.1 => /usr/lib/libdl.so.1
> >
> > libmp.so.2 => /usr/lib/libmp.so.2
> >
> > libthread.so.1 => /usr/lib/libthread.so.1
> >
> > /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1
> >
> >
> > In case it's relevant, I'm compiling with g++ 3.3.3.
> >
> > Kind regards,
> >
> > Jesse
> >
> > On Tue, Jan 5, 2010 at 10:37 AM, Christian Grothoff <
> >
> > address@hidden> wrote:
> >> Dear Jesse,
> >>
> >> I've just tried this myself, and it worked as expected. I first used
> >> openssl
> >> to generate the KEY, PEM and CERT files:
> >>
> >> $ cd svn/libmicrohttpd/doc/examples/
> >> $ openssl genrsa 1024 > server.key
> >> $ openssl req -new -x509 -nodes -sha1 -days 365 -key server.key >
> >> server.cert
> >> $ cat server.cert server.key > server.pem
> >>
> >> Then I compiled the example
> >>
> >> $ gcc -o fs tlsauthentication.c -I ~/include/ -I ../../src/include/ -I
> >> ../.. -
> >> I ../daemon/https/ -lmicrohttpd
> >>
> >> Started fs
> >>
> >> $ ./fs
> >>
> >> and then accessed https://localhost:8888/ using firefox (3.5.6). It
> >> "warned"
> >> me about the self-signed cert (also attached for your reference), I
> >> confirmed
> >> that I knew what I was doing, then was prompted for username & password
> >> (entered those from the source code) and then got the "secret" page.
> >>
> >> So I cannot confirm your problem. This was on Ubuntu GNU/linux (karmic)
> >> using
> >> the example as given in SVN HEAD.
> >>
> >> I hope this helps...
> >>
> >> Best,
> >>
> >> Christian
>