Hi,

I wonder if this has to do with the re-use of the existing connection.
I have seen it fail for SLC5.8, CentOS5.6 and CentOS 5.9. From the code
it's not clear to me why the connection is being reused.

On my (not-failing) OpenSUSE I see in the middle:
<!-- Cached page generated 20-01-13 17:20. Expires 21-01-13 17:20 -->
* Connection #0 to host www.nikhef.nl left intact
<!-- Parsetime: 0ms -->Initial request: 200
* Re-using existing connection! (#0) with host www.nikhef.nl
* Connected to www.nikhef.nl (192.16.199.166) port 443 (#0)
So it re-uses the existing connection, while the CentOS based machine
starts the second time with:
<!-- Cached page generated 20-01-13 17:20. Expires 21-01-13 17:20 -->
* Connection #0 to host www.nikhef.nl left intact
<!-- Parsetime: 0ms -->Initial request: 200
* About to connect() to www.nikhef.nl port 443
* Trying 192.16.199.166... * connected
* Connected to www.nikhef.nl (192.16.199.166) port 443
* SSL certificate problem, verify that the CA cert is OK. Details:
So no NOT reusing the connection, although it is kept open...
For plain HTTP, the CentOS is also re-using the connection instead of
opening a new one.

     Mischa

On Sun, Jan 20, 2013 at 3:14 PM, Oscar Koeroo <okoeroo_at_nikhef.nl> wrote:

> On 20-01-13 13:17, Michael Barton wrote:
> > Hi!
> >
> > I'm having a problem with libcurl that so far seems to only happen on
> > CentOS/RHEL 5.8 (libcurl 7.15.5 and openssl 0.9.8e). The first https
> > request I make on a curl handle succeeds, but all subsequent requests
> give
> > me a cert verification failure. If I disable CURLOPT_SSL_VERIFYHOST or
> > make a new curl handle for each request, everything works fine. But
> > obviously I'd prefer to avoid those. If anyone has ideas on fixing this,
> > I'd love to hear them.
> >
> > This is enough to reproduce the problem:
> > http://pastebin.com/D7PpUdnP
> >
> > Output:
>
> [...snip...]
>
> >
> > - Mike
> >
>
>
> Hi Mike,
>
> This site is a bad example. I'm getting a 404 when I try that link. I
> believe the first call worked, the other 5 subsequent calls didn't. This
> could be a side effect of this URL.
>
> I change to my work's URL being "https://www.nikhef.nl/" and it worked on
> my
> laptop. So your code should've worked too, but my libcurl is 7.28-1 and
> using DarwinSSL at the moment.
>
> I moved it to my CentOS 5 VM and observe the exact same problem. I'm using
> the same stock libcurl version there and indeed something is not right. My
> second call to my URL failed.
>
> I believe the OpenSSL context is not reset properly or something along
> those
> lines in the version curl-7.15.5-15.el5.
>
> My intermediate conclusion is that this problem is solved in a future
> version of libcurl.
>
>
> Oscar
>
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-- 
Maasstraat 162-III
1079 BK Amsterdam
The Netherlands
Tel. (+31/0)20-4043782

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-01-20