Re: libcurl with client ssl certificate
On Sun, 19 Aug 2012, Chris Baylis wrote: static const char *pCertFile = cert.pem; static const char *pCACertFile=cert.pem; This seems like a highly unlikely scenario. The same file, really? -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Unable to get content when using libcurl as staticlibrary in dll
Ah, yes! I forgot to to return in writefunction. Solved! And need to change my development environment! That damn compiler didnt warned me. Anyway, i like that joke from Guenter! Thanks, Saravana Kumar.A On 8/19/12, Guenter li...@gknw.net wrote: Am 18.08.2012 23:31, schrieb Daniel Stenberg: First, didn't your compiler warn you about not returning anything from this function? A guy is sitting on the couch and coding some program while smoking one cigarette after another. His girlfriend doesnt like the smoke and says Hey, don't you know that those things can kill you? Didn't you read the giant warning on the box?! That's OK, says the guy, puffing casually, You know I'm a computer programmer. So? What's that got to do with anything? We don't care about warnings. We only care about errors. (sorry, couldnt resist to joke a bit :-P ) Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: libcurl with client ssl certificate
On Sun, Aug 19, 2012 at 7:26 AM, Daniel Stenberg dan...@haxx.se wrote: On Sun, 19 Aug 2012, Chris Baylis wrote: static const char *pCertFile = cert.pem; static const char *pCACertFile=cert.pem; This seems like a highly unlikely scenario. The same file, really? A self-signed cert would be its own CA cert, so it's possible. He also has: pKeyName = cert.pem; so the key would need to be in the same file too. The one thing that I'm not sure about is the compiled program reporting: * found 142 certificates in /etc/ssl/certs/ca-certificates.crt when it *should* be looking for CA certs in the file designated by pCACertFile. Does libcurl automatically look in ca-certificates as well as any file you designate? Ralph Mitchell --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: libcurl with client ssl certificate
On Sun, Aug 19, 2012 at 1:57 PM, Daniel Stenberg dan...@haxx.se wrote: On Sun, 19 Aug 2012, Ralph Mitchell wrote: static const char *pCertFile = cert.pem; static const char *pCACertFile=cert.pem; This seems like a highly unlikely scenario. The same file, really? A self-signed cert would be its own CA cert, so it's possible. But the pCertFile is the SSL _client_ cert. It would mean that he uses the client cert file to verify the server cert and still also use that to authenticate to the server. It might be possible, but my money is on a mistake or misunderstanding somewhere. Yes, true!! The *server* would need to have the client's CA chain to validate the client cert, and the *client* would need the server's CA chain to validate the server cert. If the OP has a self-signed CA cert that signed both the client and server certs, the chain file would be the same for both ends.. However, command-line curl must have successfully validated the server using just the CApath: * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs so pCACertFile doesn't need setting to cert.pem. so the key would need to be in the same file too. The one thing that I'm not sure about is the compiled program reporting: * found 142 certificates in /etc/ssl/certs/ca-**certificates.crt when it *should* be looking for CA certs in the file designated by pCACertFile. Does libcurl automatically look in ca-certificates as well as any file you designate? Very good remark there! No, libcurl will in that case only use the single file specified in the setopt. It would indicate that he actually has 142 certificates in the file. That also hints that it isn't a client cert at all... In command-line curl, -E filename specifies a file containing both key and matching certificate. Is libcurl going to bail out if it finds multiple unrelated certificates in that file, as well as the expected key/cert entries? Does the order of the entries matter? Personally, I'd prefer to keep the key, cert and chain files separate, so I know what's where, but I can see there might be reasons for keeping the pem files in one big lump. Ralph Mitchell --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Building for Win64...
I tried searching around and didn't see anything relevant… Yesterday I tried building the latest curl libcurl code for Win64 (X86-64, not Itanium) mainly to see how Schannel worked. I performed the build using Visual Studio's command prompt configured for building Win64 executables. I ran into two things: 1. I kept getting linker errors about linking to 32-bit libraries until I noticed the undocumented MACHINE build setting, which had to be manually set to x64 in order to get it to link. Was this done on purpose? If so, then this is probably a dumb question, but why was this done? Could this be documented somewhere? It seems to me it should inherit the build setting from the command line… (Of course, on OS X, the opposite is true: To build for 32-bit, one must manually set the CFLAGS and LDFLAGS environmental variables to include -arch i386.) 2. I also got the following compiler warning: ..\lib\curl_schannel.c(693) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned long', possible loss of data It looks like the code is doing a 64-to-32-bit conversion, and on Win64, size_t is 64 bits wide, and I know Microsoft kept longs 32 bits wide in Win64. What's the best way to go about fixing this? I thought about just casting that warning out of existence, but then I thought that might cause other problems… Nick Zitzmann http://www.chronosnet.com/ --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
