faq

mediastreamer2是开源的网络传输媒体流的库

the loader ('ld') in MacOS X has a misfeature that's quite difficult to
go around and has linked the programs "openssl" and the test programs
with /usr/lib/libcrypto.dylib and /usr/lib/libssl.dylib instead of the
libraries you just built.
Look in the file PROBLEMS for a more detailed explanation and for possible
solutions.

* Why does the OpenSSL test suite fail in BN_sqr test [on a 64-bit platform]?

Failure in BN_sqr test is most likely caused by a failure to configure the
toolkit for current platform or lack of support for the platform in question.
Run './config -t' and './apps/openssl version -p'. Do these platform
identifiers match? If they don't, then you most likely failed to run
./config and you're hereby advised to do so before filing a bug report.
If ./config itself fails to run, then it's most likely problem with your
local environment and you should turn to your system administrator (or
similar). If identifiers match (and/or no alternative identifier is
suggested by ./config script), then the platform is unsupported. There might
or might not be a workaround. Most notably on SPARC64 platforms with GNU
C compiler you should be able to produce a working build by running
'./config -m32'. I understand that -m32 might not be what you want/need,
but the build should be operational. For further details turn to
<[e-mail]>.

* Why does OpenBSD-i386 build fail on des-586.s with "Unimplemented segment type"?

As of 0.9.7 assembler routines were overhauled for position independence
of the machine code, which is essential for shared library support. For
some reason OpenBSD is equipped with an out-of-date GNU assembler which
finds the new code offensive. To work around the problem, configure with
no-asm (and sacrifice a great deal of performance) or patch your assembler
according to <URL: http://www.openssl.org/~appro/gas-1.92.3.OpenBSD.patch>.
For your convenience a pre-compiled replacement binary is provided at
<URL: http://www.openssl.org/~appro/gas-1.92.3.static.aout.bin>.
Reportedly elder *BSD a.out platforms also suffer from this problem and
remedy should be same. Provided binary is statically linked and should be
working across wider range of *BSD branches, not just OpenBSD.

* Why does the OpenSSL test suite fail in sha512t on x86 CPU?

If the test program in question fails withs SIGILL, Illegal Instruction
exception, then you more than likely to run SSE2-capable CPU, such as
Intel P4, under control of kernel which does not support SSE2
instruction extentions. See accompanying INSTALL file and
OPENSSL_ia32cap(3) documentation page for further information.

* Why does compiler fail to compile sha512.c?

OpenSSL SHA-512 implementation depends on compiler support for 64-bit
integer type. Few elder compilers [ULTRIX cc, SCO compiler to mention a
couple] lack support for this and therefore are incapable of compiling
the module in question. The recommendation is to disable SHA-512 by
adding no-sha512 to ./config [or ./Configure] command line. Another
possible alternative might be to switch to GCC.

[PROG] ========================================================================

* Is OpenSSL thread-safe?

Yes (with limitations: an SSL connection may not concurrently be used
by multiple threads).  On Windows and many Unix systems, OpenSSL
automatically uses the multi-threaded versions of the standard
libraries.  If your platform is not one of these, consult the INSTALL
file.

Multi-threaded applications must provide two callback functions to
OpenSSL.  This is described in the threads(3) manpage.


* I've compiled a program under Windows and it crashes: why?

This is usually because you've missed the comment in INSTALL.W32.
Your application must link against the same version of the Win32
C-Runtime against which your openssl libraries were linked.  The
default version for OpenSSL is /MD - "Multithreaded DLL".

If you are using Microsoft Visual C++'s IDE (Visual Studio), in
many cases, your new project most likely defaulted to "Debug
Singlethreaded" - /ML.  This is NOT interchangeable with /MD and your
program will crash, typically on the first BIO related read or write
operation.

For each of the six possible link stage configurations within Win32,
your application must link  against the same by which OpenSSL was
built.  If you are using MS Visual C++ (Studio) this can be changed
by:

1.  Select Settings... from the Project Menu.
2.  Select the C/C++ Tab.
3.  Select "Code Generation from the "Category" drop down list box
4.  Select the Appropriate library (see table below) from the "Use
    run-time library" drop down list box.  Perform this step for both
    your debug and release versions of your application (look at the
    top left of the settings panel to change between the two)

    Single Threaded           /ML        -  MS VC++ often defaults to
                                            this for the release
                                            version of a new project.
    Debug Single Threaded     /MLd       -  MS VC++ often defaults to
                                            this for the debug version
                                            of a new project.
    Multithreaded             /MT
    Debug Multithreaded       /MTd
    Multithreaded DLL         /MD        -  OpenSSL defaults to this.
    Debug Multithreaded DLL   /MDd

Note that debug and release libraries are NOT interchangeable.  If you
built OpenSSL with /MD your application must use /MD and cannot use /MDd.

As per 0.9.8 the above limitation is eliminated for .DLLs. OpenSSL
.DLLs compiled with some specific run-time option [we recommend the
default /MD] can be deployed with application compiled with different
option or even different compiler. But there is a catch! Instead of
re-compiling OpenSSL toolkit, as you would have to with prior versions,
you have to compile small C snippet with compiler and/or options of
your choice. The snippet gets installed as
<install-root>/include/openssl/applink.c and should be either added to
your project or simply #include-d in one [and only one] of your source
files. Failure to do either manifests itself as fatal "no
OPENSSL_Applink" error.

* How do I read or write a DER encoded buffer using the ASN1 functions?

You have two options. You can either use a memory BIO in conjunction
with the i2d_*_bio() or d2i_*_bio() functions or you can use the
i2d_*(), d2i_*() functions directly. Since these are often the
cause of grief here are some code fragments using PKCS7 as an example:

 unsigned char *buf, *p;
 int len;

 len = i2d_PKCS7(p7, NULL);
 buf = OPENSSL_malloc(len); /* or Malloc, error checking omitted */
 p = buf;
 i2d_PKCS7(p7, &p);

At this point buf contains the len bytes of the DER encoding of
p7.

The opposite assumes we already have len bytes in buf:

 unsigned char *p;
 p = buf;
 p7 = d2i_PKCS7(NULL, &p, len);

At this point p7 contains a valid PKCS7 structure of NULL if an error
occurred. If an error occurred ERR_print_errors(bio) should give more
information.

The reason for the temporary variable 'p' is that the ASN1 functions
increment the passed pointer so it is ready to read or write the next
structure. This is often a cause of problems: without the temporary
variable the buffer pointer is changed to point just after the data
that has been read or written. This may well be uninitialized data
and attempts to free the buffer will have unpredictable results
because it no longer points to the same address.


* OpenSSL uses DER but I need BER format: does OpenSSL support BER?

The short answer is yes, because DER is a special case of BER and OpenSSL
ASN1 decoders can process BER.

The longer answer is that ASN1 structures can be encoded in a number of
different ways. One set of ways is the Basic Encoding Rules (BER) with various
permissible encodings. A restriction of BER is the Distinguished Encoding
Rules (DER): these uniquely specify how a given structure is encoded.

Therefore, because DER is a special case of BER, DER is an acceptable encoding
for BER.


* I've tried using <M_some_evil_pkcs12_macro> and I get errors why?

This usually happens when you try compiling something using the PKCS#12
macros with a C++ compiler. There is hardly ever any need to use the
PKCS#12 macros in a program, it is much easier to parse and create
PKCS#12 files using the PKCS12_parse() and PKCS12_create() functions
documented in doc/openssl.txt and with examples in demos/pkcs12. The
'pkcs12' application has to use the macros because it prints out 
debugging information.


* I've called <some function> and it fails, why?

Before submitting a report or asking in one of the mailing lists, you
should try to determine the cause. In particular, you should call
ERR_print_errors() or ERR_print_errors_fp() after the failed call
and see if the message helps. Note that the problem may occur earlier
than you think -- you should check for errors after every call where
it is possible, otherwise the actual problem may be hidden because
some OpenSSL functions clear the error state.


* I just get a load of numbers for the error output, what do they mean?

The actual format is described in the ERR_print_errors() manual page.
You should call the function ERR_load_crypto_strings() before hand and
the message will be output in text form. If you can't do this (for example
it is a pre-compiled binary) you can use the errstr utility on the error
code itself (the hex digits after the second colon).


* Why do I get errors about unknown algorithms?

This can happen under several circumstances such as reading in an
encrypted private key or attempting to decrypt a PKCS#12 file. The cause
is forgetting to load OpenSSL's table of algorithms with
OpenSSL_add_all_algorithms(). See the manual page for more information.


* Why can't the OpenSSH configure script detect OpenSSL?

Several reasons for problems with the automatic detection exist.
OpenSSH requires at least version 0.9.5a of the OpenSSL libraries.
Sometimes the distribution has installed an older version in the system
locations that is detected instead of a new one installed. The OpenSSL
library might have been compiled for another CPU or another mode (32/64 bits).
Permissions might be wrong.

The general answer is to check the config.log file generated when running
the OpenSSH configure script. It should contain the detailed information
on why the OpenSSL library was not detected or considered incompatible.


* Can I use OpenSSL's SSL library with non-blocking I/O?

Yes; make sure to read the SSL_get_error(3) manual page!

A pitfall to avoid: Don't assume that SSL_read() will just read from
the underlying transport or that SSL_write() will just write to it --
it is also possible that SSL_write() cannot do any useful work until
there is data to read, or that SSL_read() cannot do anything until it
is possible to send data.  One reason for this is that the peer may
request a new TLS/SSL handshake at any time during the protocol,
requiring a bi-directional message exchange; both SSL_read() and
SSL_write() will try to continue any pending handshake.


* Why doesn't my server application receive a client certificate?

Due to the TLS protocol definition, a client will only send a certificate,
if explicitly asked by the server. Use the SSL_VERIFY_PEER flag of the
SSL_CTX_set_verify() function to enable the use of client certificates.


* 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().


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