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
>
