openssl_openssl github_openssl是什么

The current version is available from https://.openssl.org.

In addition to the current stable release, you can also access dailysnapshots of the OpenSSL development version at https://.openssl.org/source/snapshot/, or get it by anonymous Git access.

OpenSSL is a library that provides cryptographic functionality toapplications such as secure web servers. Be sure to read thedocumentation of the application you want to use. The INSTALL fileexplains how to install this library.

OpenSSL includes a command line utility that can be used to perform avariety of cryptographic functions. It is described in the openssl(1)manpage. Documentation for developers is currently being written. Manymanual pages are available; overviews over libcrypto andlibssl are given in the crypto(3) and ssl(3) manpages.

The OpenSSL manpages are installed in /usr/local/ssl/man/ (or adifferent directory if you specified one as described in INSTALL).In addition, you can read the most current versions athttps://.openssl.org/docs/. Note that the online documents referto the very latest development versions of OpenSSL and may include featuresnot present in released versions. If in doubt refer to the documentationthat came with the version of OpenSSL you are using. The pod formatdocumentation is included in each OpenSSL distribution under the docsdirectory.

The README file describes how to submit bug reports and patches toOpenSSL. Information on the OpenSSL mailing lists is available fromhttps://.openssl.org/community/mailinglists.html.

You can finder pointers to binary distributions inhttps://.openssl.org/community/binaries.html .

Some applications that use OpenSSL are distributed in binary form.When using such an application, you don't need to install OpenSSLyourself; the application will include the required parts (e.g. DLLs).

If you want to build OpenSSL on a Windows system and you don't havea C compiler, read the "Mingw32" section of INSTALL.W32 for informationon how to obtain and install the free GNU C compiler.

A number of Linux and *BSD distributions include OpenSSL.

A number of these tools are great and wonderful, but are usuallycentered around one or a few platforms. 'autoconf' and 'libtool' areUnix centric. 'cmake' is a bit more widely spread, but not enough tocover the platforms we support.

For OpenSSL 1.1, we decided to base our build system on perl,information files and build file (Makefile) templates, therebycovering all the systems we support. Perl was the base language ofchoice because we already use it in diverse scripts, and it's one ofthe most widely spread scripting languages.

With version 0.9.6 OpenSSL was extended to intece to external cryptohardware. This was realized in a special release '0.9.6-engine'. Withversion 0.9.7 the changes were merged into the main development line,so that the special release is no longer necessary.

We provide PGP signatures and a variety of digests on each release.For example, one of the following might work on your system:

   sha1sum TARBALL | awk '{print $1;}' | cmp - TARBALL.sha1
   sha256sum TARBALL | awk '{print $1;}' | cmp - TARBALL.sha256

You can check authenticity using pgp or gpg. You need the OpenSSL teammember public key used to sign it (download it from a key server, see alist of keys at https://.openssl.org/community/team.html). Thenjust do:

   pgp TARBALL.asc

After the release of OpenSSL 1.0.0 the versioning scheme changed. Letterreleases (e.g. 1.0.1a) can only contain bug and security fixes and nonew features. Minor releases change the last number (e.g. 1.0.2) andcan contain new features that retain binary compatibility. Changes tothe middle number are considered major releases and neither source norbinary compatibility is guaranteed.

Therefore the answer to the common question "when will feature X bebackported to OpenSSL 1.0.0/0.9.8?" is "never" but it could appearin the next minor release.

It was decided after the release of OpenSSL 0.9.8y the next version shouldbe 0.9.8za then 0.9.8zb and so on.

For information on intellectual property rights, please consult a lawyer.The OpenSSL team does not offer legal advice.

You can configure OpenSSL so as not to use IDEA, MDC2 and RC5 by using

 ./config no-idea no-mdc2 no-rc5

On many systems including the major Linux and BSD distributions, yes (theGPL does not place restrictions on using libraries that are part of thenormal operating system distribution).

Cryptographic software needs a source of unpredictable data to workcorrectly. Many open source operating systems provide a "randomnessdevice" (/dev/urandom or /dev/random) that serves this purpose.All OpenSSL versions try to use /dev/urandom by default; starting withversion 0.9.7, OpenSSL also tries /dev/random if /dev/urandom is notavailable.

On other systems, applications have to call the RAND_add() orRAND_seed() function with appropriate data before generating keys orperforming public key encryption. (These functions initialize thepseudo-random number generator, PRNG.) Some broken applications donot do this. As of version 0.9.5, the OpenSSL functions that needrandomness report an error if the random number generator has not beenseeded with at least 128 bits of randomness. If this error occurs andis not discussed in the documentation of the application you areusing, please contact the author of that application; it is likelythat it never worked correctly. OpenSSL 0.9.5 and later make theerror visible by refusing to perform potentially insecure encryption.

If you are using Solaris 8, you can add /dev/urandom and /dev/randomdevices by installing patch 112438 (Sparc) or 112439 (x86), which areavailable via the Patchfinder at (Solaris 9 includes these devices by default). For /dev/random supportfor earlier Solaris versions, see Sun's statement at?doc=fsrdb/27606&zone_32=SUNWski(the SUNWski package is available in patch 105710).

On systems without /dev/urandom and /dev/random, it is a good idea touse the Entropy Gathering Demon (EGD); see the RAND_egd() manpage fordetails. Starting with version 0.9.7, OpenSSL will automatically lookfor an EGD socket at /var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and/etc/entropy.

Most components of the openssl command line utility automatically tryto seed the random number generator from a file. The name of thedefault seeding file is determined as follows: If environment variableRANDFILE is set, then it names the seeding file. Otherwise ifenvironment variable HOME is set, then the seeding file is $HOME/.rnd.If neither RANDFILE nor HOME is set, versions up to OpenSSL 0.9.6 willuse file .rnd in the current directory while OpenSSL 0.9.6a uses nodefault seeding file at all. OpenSSL 0.9.6b and later will behavesimilarly to 0.9.6a, but will use a default of "C:\" for HOME onWindows systems if the environment variable has not been set.

If the default seeding file does not exist or is too short, the "PRNGnot seeded" error message may occur.

The openssl command line utility will write back a new state to thedefault seeding file (and create this file if necessary) unlessthere was no sufficient seeding.

Pointing $RANDFILE to an Entropy Gathering Daemon socket does not work.Use the "-rand" option of the OpenSSL command line tools instead.The $RANDFILE environment variable and $HOME/.rnd are only used by theOpenSSL command line tools. Applications using the OpenSSL libraryprovide their own configuration options to specify the entropy source,please check out the documentation coming the with application.

Sometimes the openssl command line utility does not abort witha "PRNG not seeded" error message, but complains that it is"unable to write 'random state'". This message refers to thedefault seeding file (see previous answer). A possible reasonis that no default filename is known because neither RANDFILEnor HOME is set. (Versions up to 0.9.6 used file ".rnd" in thecurrent directory in this case, but this has changed with 0.9.6a.)

Check out the CA.pl(1) manual page. This provides a wrapper roundthe 'req', 'verify', 'ca' and 'pkcs12' utilities. For finer control checkout the manual pages for the individual utilities and the certificateextensions documentation (in ca(1), req(1), x509v3_config(5) )

You typically get the error:

unable to find 'distinguished_name' in config problems making Certificate Request

This is because it can't find the configuration file. Check out theDIAGNOSTICS section of req(1) for more information.

This problem is usually indicated by log messages saying something like"unable to get local issuer certificate" or "self signed certificate".When a certificate is verified its root CA must be "trusted" by OpenSSLthis typically means that the CA certificate must be placed in a directoryor file and the relevant program configured to read it. The OpenSSL program'verify' behaves in a similar way and issues similar error messages: checkthe verify(1) program manual page for more information.

This is almost certainly because you are using an old "export grade" browserwhich only supports weak encryption. Upgrade your browser to support 128 bitciphers.

Check the CA.pl(1) manual page for a DSA certificate example.

Typically you'll see a message saying there are no shared ciphers whenthe same setup works fine with an RSA certificate. There are two possiblecauses. The client may not support connections to DSA servers most webbrowsers (including Netscape and MSIE) only support connections to serverssupporting RSA cipher suites. The other cause is that a set of DH parametershas not been supplied to the server. DH parameters can be created with thedhparam(1) command and loaded using the SSL_CTX_set_tmp_dh() for example:check the source to s_server in apps/s_server.c for an example.

Firstly you should be really *really* sure you want to do this. Leavinga private key unencrypted is a major security risk. If you decide thatyou do have to do this check the EXAMPLES sections of the rsa(1) anddsa(1) manual pages.

What will typically happen is that when a server requests authenticationit will either not include your certificate or tell you that you haveno client certificates (Netscape) or present you with an empty list box(MSIE). The reason for this is that when a server requests a clientcertificate it includes a list of CAs names which it will accept. Browserswill only let you select certificates from the list on the grounds thatthere is little point presenting a certificate which the server willreject.

The solution is to add the relevant CA certificate to your servers "trustedCA list". How you do this depends on the server software in uses. You canprint out the servers list of acceptable CAs using the OpenSSL s_client tool:

openssl s_client -connect :443 -prexit

If your server only requests certificates on certain URLs then you may needto manually issue an HTTP GET command to get the list when s_client connects:

GET /some/page/needing/a/certificate.html

If your CA does not appear in the list then this confirms the problem.

Browsers expect the server's hostname to match the value in the commonName(CN) field of the certificate. If it does not then you get a warning.

The usual way is to send the DER encoded certificate to the browser asMIME type application/x-x509-ca-cert, for example by clicking on an appropriatelink. On MSIE certain extensions such as .der or .cacert may also work, or youcan import the certificate using the certificate import wizard.

You can convert a certificate to DER form using the command:

openssl x509 -in ca.pem -outform DER -out ca.der

Occasionally someone suggests using a command such as:

openssl pkcs12 -export -out cacert.p12 -in cacert.pem -inkey cakey.pem

DO NOT DO THIS! This command will give away your CAs private key andreduces its security to zero: allowing anyone to forge certificates inwhatever name they choose.

The ways to print out the oneline format of the DN (Distinguished Name) havebeen extended in version 0.9.7 of OpenSSL. Using the new X509_NAME_print_ex()intece, the "-nameopt" option could be introduced. See the manualpage of the "openssl x509" command line tool for details. The old behaviourhas however been left as default for the sake of compatibility.

The term "128 bit certificate" is a highly misleading marketing term. It does*not* refer to the size of the public key in the certificate! A certificatecontaining a 128 bit RSA key would have negligible security.

There were various other names such as "magic certificates", "SGCcertificates", "step up certificates" etc.

You can't generally create such a certificate using OpenSSL but there is noneed to any more. Nowadays web browsers using unrestricted strong encryptionare generally available.

When there were tight restrictions on the export of strong encryptionsoftware from the US only weak encryption algorithms could be freely exported(initially 40 bit and then 56 bit). It was widely recognised that this wasinadequate. A relaxation of the rules allowed the use of strong encryption butonly to an authorised server.

Two slightly different techniques were developed to support this, one used byNetscape was called "step up", the other used by MSIE was called "Server GatedCryptography" (SGC). When a browser initially connected to a server it wouldcheck to see if the certificate contained certain extensions and was issued byan authorised authority. If these test succeeded it would reconnect usingstrong encryption.

Only certain (initially one) certificate authorities could issue thecertificates and they generally cost more than ordinary certificates.

Although OpenSSL can create certificates containing the appropriate extensionsthe certificate would not come from a permitted authority and so would notbe recognized.

The export laws were later changed to allow almost unrestricted use of strongencryption so these certificates are now obsolete.

It doesn't: this extension is often the cause of confusion.

Consider a certificate chain A->B->C so that A signs B and B signs C. Supposecertificate C contains AKID.

The purpose of this extension is to identify the authority certificate B. Thiscan be done either by including the subject key identifier of B or its issuername and serial number.

In this latter case because it is identifying certificate B it must contain theissuer name and serial number of B.

It is often wrongly assumed that it should contain the subject name of B. If itdid this would be redundant information because it would duplicate the issuername of C.

The OpenSSL software is shipped without any root CA certificate as theOpenSSL project does not have any policy on including or excludingany specific CA and does not intend to set up such a policy. Decidingabout which CAs to support is up to application developers oradministrators.

Other projects do have other policies so you can for example extract the CAbundle used by Mozilla and/or modssl as described in this article:https://.mail-archive.com/modssl-users@modssl.org/msg16980.html

OpenSSL 1.0.1 is the first release to support TLS 1.2, among other things,this increases the size of the default ClientHello message to more than255 bytes in length. Some software cannot handle this and hangs. For moredetails and workarounds see:https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=2771

You need to build with -DPEDANTIC to run sanitized tests, otherwiseyou will get optimized assembler versions of some functions.

Maybe the compilation was interrupted, and make doesn't notice thatsomething is missing. Run "make clean; make".

If you used ./Configure instead of ./config, make sure that youselected the right target. File formats may differ slightly betweenOS versions (for example sparcv8/sparcv9, or a.out/elf).

In case you get errors about the following symbols, use the configoption "no-asm", as described in INSTALL:

 BF_cbc_encrypt, BF_decrypt, BF_encrypt, CAST_cbc_encrypt,
 CAST_decrypt, CAST_encrypt, R, RC5_32_cbc_encrypt, RC5_32_decrypt,
 RC5_32_encrypt, bn_add_words, bn_div_words, bn_mul_add_words,
 bn_mul_comba4, bn_mul_comba8, bn_mul_words, bn_sqr_comba4,
 bn_sqr_comba8, bn_sqr_words, bn_sub_words, des_decrypt3,
 des_ede3_cbc_encrypt, des_encrypt, des_encrypt2, des_encrypt3,
 des_ncbc_encrypt, md5_block_asm_host_order, sha1_block_asm_data_order

If none of these helps, you may want to try using the current snapshot.If the problem persists, please submit a bug report.

You didn't install "bc", the Unix calculator. If you want to run thetests, get GNU bc from ftp://ftp.gnu.org or from your OS distributor.

On some SCO installations or versions, bc has a bug that gets triggeredwhen you run the test suite (using "make test"). The message returned is"bc: 1 not implemented".

The best way to deal with this is to find another implementation of bcand compile/install it. GNU bc (see https://.gnu.org/software/software.htmlfor download instructions) can be safely used, for example.

On some DG/ux versions, bc seems to have a too small stack for calculationsthat the OpenSSL bntest throws at it. This gets triggered when you run thetest suite (using "make test"). The message returned is "bc: stack empty".

The best way to deal with this is to find another implementation of bcand compile/install it. GNU bc (see https://.gnu.org/software/software.htmlfor download instructions) can be safely used, for example.

On some Alpha installations running Tru64 Unix and Compaq C, the compilationof crypto/sha/sha_dgst.c fails with the message 'Fatal: Insufficient virtualmemory to continue compilation.' As far as the tests have shown, this may bea compiler bug. What happens is that it eats up a lot of resident memoryto build something, probably a table. The problem is clearly in theoptimization code, because if one eliminates optimization completely (-O0),the compilation goes through (and the compiler consumes about 2MB of residentmemory instead of 240MB or whatever one's limit is currently).

There are three options to solve this problem:

1. set your current data segment size soft limit higher. Experience showsthat about 241000 kbytes seems to be enough on an AlphaServer DS10. You dothis with the command 'ulimit -Sd nnnnnn', where 'nnnnnn' is the number ofkbytes to set the limit to.

2. If you have a hard limit that is lower than what you need and you can'tget it changed, you can compile all of OpenSSL with -O0 as optimizationlevel. This is however not a very nice thing to do for those who expect toget the best result from OpenSSL. A bit more complicated solution is thefollowing:

  make DIRS=crypto SDIRS=sha "`grep '^CFLAG=' Makefile.ssl | \
       sed -e 's/ -O[0-9] / -O0 /'`"
  rm `ls crypto/*.o crypto/sha/*.o | grep -v 'sha_dgst\.o'`
  make

This will only compile sha_dgst.c with -O0, the rest with the optimizationlevel chosen by the configuration process. When the above is done, do thetest and installation and you're set.

3. Reconfigure the toolkit with no-sha0 option to leave out SHA0. Itshould not be used and is not used in SSL/TLS nor any other recognizedprotocol in either case.

Getting this message is quite usual on Solaris 2, because Sun has hiddenaway 'ar' and other development commands in directories that aren't in$PATH by default. One of those directories is '/usr/ccs/bin'. Thequickest way to fix this is to do the following (it assumes you use shor any sh-compatible shell):

  PATH=${PATH}:/usr/ccs/bin; export PATH

and then redo the compilation. What you should really do is make sure'/usr/ccs/bin' is permanently in your $PATH, for example through your'.profile' (again, assuming you use a sh-compatible shell).

Sometimes, you may get reports from VC++ command line (cl) that itcan't find standard include files like stdio.h and other weirdnesses.One possible cause is that the environment isn't correctly set up.To solve that problem for VC++ versions up to 6, one should runVCVARS32.BAT which is found in the 'bin' subdirectory of the VC++installation directory (somewhere under 'Program Files'). For VC++version 7 (and up?), which is also called VS.NET, the file is calledVSVARS32.BAT instead.This needs to be done prior to running NMAKE, and the changes are onlyvalid for the current DOS session.

Red Hat Linux (release 7.0 and later) include a preinstalled limitedversion of OpenSSL. Red Hat has chosen to disable support for IDEA, RC5 andMDC2 in this version. The same may apply to other Linux distributions.Users may therefore wish to install more or all of the features left out.

To do this you MUST ensure that you do not overwrite the openssl that is in/usr/bin on your Red Hat machine. Several packages depend on this file,including sendmail and ssh. /usr/local/bin is a good alternative choice. Thelibraries that come with Red Hat 7.0 onwards have different names and so arenot affected. (eg For Red Hat 7.2 they are /lib/libssl.so.0.9.6b and/lib/libcrypto.so.0.9.6b with symlinks /lib/libssl.so.2 and/lib/libcrypto.so.2 respectively).

Please note that we have been advised by Red Hat attempting to recompile theopenssl rpm with all the cryptography enabled will not work. All otherpackages depend on the original Red Hat supplied openssl package. It is alsoworth noting that due to the way Red Hat supplies its packages, updates toopenssl on each distribution never change the package version, only thebuild number. For example, on Red Hat 7.1, the latest openssl package hasversion number 0.9.6 and build number 9 even though it contains all therelevant updates in packages up to and including 0.9.6b.

A possible way around this is to persuade Red Hat to produce a non-USversion of Red Hat Linux.

If the failure happens when trying to build the "openssl" binary, witha large number of undefined symbols, it's very probable that you haveOpenSSL 0.9.6b delivered with the operating system (you can find out byrunning '/usr/bin/openssl version') and that you were trying to buildOpenSSL 0.9.7 or newer. The problem is that the loader ('ld') inMacOS X has a misfeature that's quite difficult to go around.Look in the file PROBLEMS for a more detailed explanation and for possiblesolutions.

If the failure happens when running 'make test' and the R test fails,it's very probable that you have OpenSSL 0.9.6b delivered with theoperating system (you can find out by running '/usr/bin/openssl version')and that you were trying to build OpenSSL 0.9.6d. The problem is thatthe loader ('ld') in MacOS X has a misfeature that's quite difficult togo around and has linked the programs "openssl" and the test programswith /usr/lib/libcrypto.dylib and /usr/lib/libssl.dylib instead of thelibraries you just built.Look in the file PROBLEMS for a more detailed explanation and for possiblesolutions.

Failure in BN_sqr test is most likely caused by a failure to configure thetoolkit for current platform or lack of support for the platform in question.Run './config -t' and './apps/openssl version -p'. Do these platformidentifiers 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 yourlocal environment and you should turn to your system administrator (orsimilar). If identifiers match (and/or no alternative identifier issuggested by ./config script), then the platform is unsupported. There mightor might not be a workaround. Most notably on SPARC64 platforms with GNUC 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<openssl-dev@openssl.org>.

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

If the test program in question fails withs SIGILL, Illegal Instructionexception, then you more than likely to run SSE2-capable CPU, such asIntel P4, under control of kernel which does not support SSE2instruction extensions. See accompanying INSTALL file andOPENSSL_ia32cap(3) documentation page for further information.

OpenSSL SHA-512 implementation depends on compiler support for 64-bitinteger type. Few elder compilers [ULTRIX cc, SCO compiler to mention acouple] lack support for this and therefore are incapable of compilingthe module in question. The recommendation is to disable SHA-512 byadding no-sha512 to ./config [or ./Configure] command line. Anotherpossible alternative might be to switch to GCC.

Another common reason for test failures is bugs in the toolchainor run-time environment. Known cases of this are documented in thePROBLEMS file, please review it before you beat the drum. Even if youdon't find anything in that file, please do consider the possibilityof a compiler bug. Compiler bugs often appear in rather bizarre ways,they never make sense, and tend to emerge when you least expectthem. One thing to try is to reduce the level of optimization (suchas by editing the CFLAG variable line in the top-level Makefile),and then recompile and re-run the test.

If you are a new user then it is quite likely you haven't found a bug andsomething is happening you aren't familiar with. Check this FAQ, the associateddocumentation and the mailing lists for similar queries. If you are stillunsure whether it is a bug or not submit a query to the openssl-users mailinglist.

If you think you have found a bug based on the output of static ysis toolsthen please manually check the issue is genuine. Such tools can produce aLOT of false positives.

Please see https://.openssl.org/community

If you think your bug has security implications then please send it toopenssl-security@openssl.org if you don't get a prompt reply at leastacknowledging receipt then resend or mail it directly to one of themore active team members (e.g. Steve). If you wish to use PGP to sendin a report please use one or more of the keys of the team members listedat https://.openssl.org/community/team.html

Note that bugs only present in the openssl utility are not in generalconsidered to be security issues.

Provided an application sets up the thread callback functions, theanswer is yes. There are limitations; for example, an SSL connectioncannot be used concurrently by multiple threads. This is true formost OpenSSL objects.

To do this, your application must call CRYPTO_set_locking_callback()and one of the CRYPTO_THREADID_set...() API's. See the OpenSSL threadsmanpage for details and "note on multi-threading" in the INSTALL file inthe source distribution.

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

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

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

 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 youbuilt 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 insist on thedefault /MD] can be deployed with application compiled with differentoption or even different compiler. But there is a catch! Instead ofre-compiling OpenSSL toolkit, as you would have to with prior versions,you have to compile small C snippet with compiler and/or options ofyour choice. The snippet gets installed as<install-root>/include/openssl/applink.c and should be either added toyour application project or simply #include-d in one [and only one]of your application source files. Failure to link this shim moduleinto your application manifests itself as fatal "no OPENSSL_Applink"run-time error. An explicit reminder is due that in this situation[mixing compiler options] it is as important to add CRYPTO_malloc_initprior first call to OpenSSL.

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

 unsigned char *buf, *p;
 int len = i2d_PKCS7(p7, NULL);

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

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

The opposite assumes we already have len bytes in buf:

 unsigned char *p = buf;

 p7 = d2i_PKCS7(NULL, &p, len);

At this point p7 contains a valid PKCS7 structure or NULL if an erroroccurred. If an error occurred ERR_print_errors(bio) should give moreinformation.

The reason for the temporary variable 'p' is that the ASN1 functionsincrement the passed pointer so it is ready to read or write the nextstructure. This is often a cause of problems: without the temporaryvariable the buffer pointer is changed to point just after the datathat has been read or written. This may well be uninitialized dataand attempts to free the buffer will have unpredictable resultsbecause it no longer points to the same address.

Memory allocation and encoding can also be combined in a singleoperation by the ASN1 routines:

 unsigned char *buf = NULL;
 int len = i2d_PKCS7(p7, &buf);

 if (len < 0) {
     /* Error */
 }
 /* Do some things with 'buf' */
 /* Finished with buf: free it */
 OPENSSL_free(buf);

In this special case the "buf" parameter is *not* incremented, it pointsto the start of the encoding.

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

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

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

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

Before submitting a report or asking in one of the mailing lists, youshould try to determine the cause. In particular, you should callERR_print_errors() or ERR_print_errors_fp() after the failed calland see if the message helps. Note that the problem may occur earlierthan you think -- you should check for errors after every call whereit is possible, otherwise the actual problem may be hidden becausesome OpenSSL functions clear the error state.

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

The cause is forgetting to load OpenSSL's table of algorithms withOpenSSL_add_all_algorithms(). See the manual page for more information. Thiscan cause several problems such as being unable to read in an encryptedPEM file, unable to decrypt a PKCS#12 file or signature failure whenverifying certificates.

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 systemlocations that is detected instead of a new one installed. The OpenSSLlibrary 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 runningthe OpenSSH configure script. It should contain the detailed informationon why the OpenSSL library was not detected or considered incompatible.

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 fromthe underlying transport or that SSL_write() will just write to it --it is also possible that SSL_write() cannot do any useful work untilthere is data to read, or that SSL_read() cannot do anything until itis possible to send data. One reason for this is that the peer mayrequest a new TLS/SSL handshake at any time during the protocol,requiring a bi-directional message exchange; both SSL_read() andSSL_write() will try to continue any pending handshake.

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 theSSL_CTX_set_verify() function to enable the use of client certificates.

For OpenSSL 0.9.7 the OID table was extended and corrected. In earlierversions, 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.

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

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

Thread-local cleanup functions:

  ERR_remove_state()

Application-global cleanup functions that are aware of usage (and thereforethread-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().

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

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 datahas been read from it.

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

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

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

   BIO_set_mem_eof_return(bio, 0);

See the manual pages for more details.

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 anASN1 interpreter using generalised functions such as ASN1_item_d2i().

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

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-47340-1.html