Dave, Thanks for the suggestion! I took a look at the low-hanging fruit first - my SSL ctx object. So I modified the code a little bit by checking the SSL CTX first:
ctx = SSL_CTX_new(SSLv23_method()); // handle only SSL v2 and v3 if (!ctx) { int_error("Error in creating SSL ctx\n"); return 0; } fprintf(stderr,"Loading server certificate\n"); if (SSL_CTX_use_certificate_chain_file(ctx,SERVER_CERT) != 1) { int_error("Error loading server certificate"); } This time it complained about: ssl_server.c 27, Error in creating SSL ctx 139658508588992:error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers:ssl_lib.c:1770: So obviously my SSL_CTX object wasn't created properly. Now I have to figure out what it means by "library has no ciphers". David On Tue, May 20, 2014 at 11:47 AM, Dave Thompson <dthomp...@prinpay.com>wrote: > > From: owner-openssl-us...@openssl.org [mailto: > owner-openssl-us...@openssl.org] On Behalf Of David Li > > Sent: Tuesday, May 20, 2014 13:05 > <snip> > > I am using SSL_CTX_use_certificate_chain_file() to load my server > certificate files at initialization. > > The PEM file is created by concatenating server cert, server key and CA > cert together. > > I used the following command line to check its format and it seemed OK. > > > $ openssl s_server -cert servercert.pem -www > > Using default temp DH parameters > > Using default temp ECDH parameters > > ACCEPT > > Note s_server does use_certificate_file (and also use_PrivateKey_file) not > the _chain_ version, > so that really only checks that the server (first) cert and privatekey are > good, not the rest > of the file. However, even if the CA cert is somehow bad it should at > worst give an error return > (and maybe just discard it) not a SEGV. However, if the CA cert is a root > (possibly your own > DIY root) it doesn't matter if it's in the file and good or not, because > servers aren't required > to send the root of their chain -- because clients can never trust a root > (or in general anchor) > sent by the server and must already have it local anyway. > > > And I can use openssl s_client command line to connect to the above > server without any issues. > > What did you use for s_client's trust store (-CAfile and/or -CApath)? > > > Now when I started my server, the code crashed inside the > SSL_CTX_use_certificate_chain_file(): > <snip> > > There wasn't any detailed errors printed out but only:Segmentation fault > (core dumped) > > When you get an unhandled signal -- and SEGV usually isn't and often can't > be handled -- > a C program aborts without outputting anything that wasn't output (and > where applicable > flushed) before the signal. This is unlike 'voluntary' error handling > where the code gets > a return value indicating an error (such as -1 from SSL_connect or NULL > from fopen) > and can -- and should -- print information about the problem. And unlike > some other > languages that (more or less reliably) catch exceptions and give details > for them. > > > Can anyone suggest how to debug this issue? > > The same way you debug SEGV in any C program. In this case you got a core > dump file; > open it with the debugger of your choice -- gdb is common and popular -- > and try to > look at the stack (bt in gdb). Sometimes the stack is clobbered by the > same bug that > caused the SEGV, but usually it shows where -- or nearly where -- the code > was > executing and called from and sometimes (often?) the function arguments at > each level. > > Alternatively, (re)run the program under control of a debugger like gdb to > start with. > Set breakpoints before or at the call that fails, and look to make sure > the arguments > are good -- for use_cert_chain, ctx points to a validly allocated and > initialized SSL_CTX > (to a first approximation if p *ctx doesn't give a gdb error and isn't all > zero or obvious > garbage, it's likely okay) and *file is the correct filename (and null > terminated). > If they look okay and you either built openssl from source or have the > source from which > it was built installed, step in and see where it fails; but that's only > needed if the bug is > in the openssl code which is unlikely as thousands or millions of other > people use it > without problem. (Though not completely impossible.) > > Or if you don't like the debugger, try taking out parts of your code that > don't appear > to be related to the problem to see if it still occurs. While it does, > keep reducing until > you either find the problem or get to a small self-contained example that > exhibits > the problem and post it. Unless you are using a good revision control > system, it's > usually best to 'remove' code by putting #if 0 and #endif lines around it > instead of > actually deleting it, so that you can easily put it back correctly if > necessary. > > Unfortunately if the symptom stops when you remove some code, that doesn't > reliably > prove that code was the problem (or the only problem); problems at the > machine level > are usually due to 'undefined behavior' in C where your code is wrong in a > way that > isn't required to be caught, like using an invalid pointer, and the actual > results vary > depending on seemingly irrelevant factors like the size of code before and > after the > location of the actual bug in a complicated way that won't make any sense > unless > you understand in detail the machine code generated for your source code -- > and to be frank if you knew that you wouldn't be asking a question like > this. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >