FAQ

* Why does compilation fail due to an undefined symbol NID_uniqueIdentifier?

For OpenSSL 0.9.7 the OID table was extended and corrected. In earlier
versions, uniqueIdentifier was incorrectly used for X.509 certificates.
The correct name according to RFC2256 (LDAP) is x500UniqueIdentifier.
Change your code to use the new name when compiling against OpenSSL 0.9.7.


* I think I've detected a memory leak, is this a bug?

In most cases the cause of an apparent memory leak is an OpenSSL internal table
that is allocated when an application starts up. Since such tables do not grow
in size over time they are harmless.

These internal tables can be freed up when an application closes using various
functions.  Currently these include following:

Thread-local cleanup functions:

  ERR_remove_state()

Application-global cleanup functions that are aware of usage (and therefore
thread-safe):

  ENGINE_cleanup() and CONF_modules_unload()

"Brutal" (thread-unsafe) Application-global cleanup functions:

  ERR_free_strings(), EVP_cleanup() and CRYPTO_cleanup_all_ex_data().


* Why does Valgrind complain about the use of uninitialized data?

When OpenSSL's PRNG routines are called to generate random numbers the supplied
buffer contents are mixed into the entropy pool: so it technically does not
matter whether the buffer is initialized at this point or not.  Valgrind (and
other test tools) will complain about this. When using Valgrind, make sure the
OpenSSL library has been compiled with the PURIFY macro defined (-DPURIFY)
to get rid of these warnings.


* Why doesn't a memory BIO work when a file does?

This can occur in several cases for example reading an S/MIME email message.
The reason is that a memory BIO can do one of two things when all the data
has been read from it.

The default behaviour is to indicate that no more data is available and that
the call should be retried, this is to allow the application to fill up the BIO
again if necessary.

Alternatively it can indicate that no more data is available and that EOF has
been reached.

If a memory BIO is to behave in the same way as a file this second behaviour
is needed. This must be done by calling:

   BIO_set_mem_eof_return(bio, 0);

See the manual pages for more details.


* Where are the declarations and implementations of d2i_X509() etc?

These are defined and implemented by macros of the form:


 DECLARE_ASN1_FUNCTIONS(X509) and IMPLEMENT_ASN1_FUNCTIONS(X509)

The implementation passes an ASN1 "template" defining the structure into an
ASN1 interpreter using generalised functions such as ASN1_item_d2i().

* When debugging I observe SIGILL during OpenSSL initialization: why?

OpenSSL adapts to processor it executes on and for this reason has to
query its capabilities. Unfortunately on some processors the only way
to achieve this for non-privileged code is to attempt instructions
that can cause Illegal Instruction exceptions. The initialization
procedure is coded to handle these exceptions to manipulate corresponding
bits in capabilities vector. This normally appears transparent, except
when you execute it under debugger, which stops prior delivering signal
to handler. Simply resuming execution does the trick, but when debugging
a lot it might feel counterproductive. Two options. Either set explicit
capability environment variable in order to bypass the capability query
(see corresponding crypto/*cap.c for details). Or configure debugger not
to stop upon SIGILL exception, e.g. in gdb case add 'handle SIGILL nostop'
to your .gdbinit.

===============================================================================