105 files changed, 4672 insertions, 627 deletions

diff --git a/src/lib/libssl/src/doc/HOWTO/certificates.txt b/src/lib/libssl/src/doc/HOWTO/certificates.txt
new file mode 100644
index 0000000000..88048645db
--- /dev/null
+++ b/src/lib/libssl/src/doc/HOWTO/certificates.txt
@@ -0,0 +1,85 @@
+<DRAFT!>
+                        HOWTO certificates
+
+How you handle certificates depend a great deal on what your role is.
+Your role can be one or several of:
+
+  - User of some client software
+  - User of some server software
+  - Certificate authority
+
+This file is for users who wish to get a certificate of their own.
+Certificate authorities should read ca.txt.
+
+In all the cases shown below, the standard configuration file, as
+compiled into openssl, will be used.  You may find it in /etc/,
+/usr/local/ssr/ or somewhere else.  The name is openssl.cnf, and
+is better described in another HOWTO <config.txt?>.  If you want to
+use a different configuration file, use the argument '-config {file}'
+with the command shown below.
+
+
+Certificates are related to public key cryptography by containing a
+public key.  To be useful, there must be a corresponding private key
+somewhere.  With OpenSSL, public keys are easily derived from private
+keys, so before you create a certificate or a certificate request, you
+need to create a private key.
+
+Private keys are generated with 'openssl genrsa' if you want a RSA
+private key, or 'openssl gendsa' if you want a DSA private key.  More
+info on how to handle these commands are found in the manual pages for
+those commands or by running them with the argument '-h'.  For the
+sake of the description in this file, let's assume that the private
+key ended up in the file privkey.pem (which is the default in some
+cases).
+
+
+Let's start with the most normal way of getting a certificate.  Most
+often, you want or need to get a certificate from a certificate
+authority.  To handle that, the certificate authority needs a
+certificate request (or, as some certificate authorities like to put
+it, "certificate signing request", since that's exactly what they do,
+they sign it and give you the result back, thus making it authentic
+according to their policies) from you.  To generate a request, use the
+command 'openssl req' like this:
+
+  openssl req -new -key privkey.pem -out cert.csr
+
+Now, cert.csr can be sent to the certificate authority, if they can
+handle files in PEM format.  If not, use the extra argument '-outform'
+followed by the keyword for the format to use (see another HOWTO
+<formats.txt?>).  In some cases, that isn't sufficient and you will
+have to be more creative.
+
+When the certificate authority has then done the checks the need to
+do (and probably gotten payment from you), they will hand over your
+new certificate to you.
+
+
+[fill in on how to create a self-signed certificate]
+
+
+If you created everything yourself, or if the certificate authority
+was kind enough, your certificate is a raw DER thing in PEM format.
+Your key most definitely is if you have followed the examples above.
+However, some (most?) certificate authorities will encode them with
+things like PKCS7 or PKCS12, or something else.  Depending on your
+applications, this may be perfectly OK, it all depends on what they
+know how to decode.  If not, There are a number of OpenSSL tools to
+convert between some (most?) formats.
+
+So, depending on your application, you may have to convert your
+certificate and your key to various formats, most often also putting
+them together into one file.  The ways to do this is described in
+another HOWTO <formats.txt?>, I will just mention the simplest case.
+In the case of a raw DER thing in PEM format, and assuming that's all
+right for yor applications, simply concatenating the certificate and
+the key into a new file and using that one should be enough.  With
+some applications, you don't even have to do that.
+
+
+By now, you have your cetificate and your private key and can start
+using the software that depend on it.
+
+-- 
+Richard Levitte
diff --git a/src/lib/libssl/src/doc/apps/CA.pl.pod b/src/lib/libssl/src/doc/apps/CA.pl.pod
index 63cd1320cc..58e0f52001 100644
--- a/src/lib/libssl/src/doc/apps/CA.pl.pod
+++ b/src/lib/libssl/src/doc/apps/CA.pl.pod
@@ -13,6 +13,7 @@ B<CA.pl>
 [B<-help>]
 [B<-newcert>]
 [B<-newreq>]
+[B<-newreq-nodes>]
 [B<-newca>]
 [B<-xsign>]
 [B<-sign>]
@@ -46,6 +47,10 @@ written to the file "newreq.pem".
 creates a new certificate request. The private key and request are
 written to the file "newreq.pem".
 
+=item B<-newreq-nowdes>
+
+is like B<-newreq> except that the private key will not be encrypted.
+
 =item B<-newca>
 
 creates a new CA hierarchy for use with the B<ca> program (or the B<-signcert>
diff --git a/src/lib/libssl/src/doc/apps/ca.pod b/src/lib/libssl/src/doc/apps/ca.pod
index d352925864..c2ca8f2400 100644
--- a/src/lib/libssl/src/doc/apps/ca.pod
+++ b/src/lib/libssl/src/doc/apps/ca.pod
@@ -13,6 +13,7 @@ B<openssl> B<ca>
 [B<-name section>]
 [B<-gencrl>]
 [B<-revoke file>]
+[B<-subj arg>]
 [B<-crldays days>]
 [B<-crlhours hours>]
 [B<-crlexts section>]
@@ -33,9 +34,11 @@ B<openssl> B<ca>
 [B<-spkac file>]
 [B<-ss_cert file>]
 [B<-preserveDN>]
+[B<-noemailDN>]
 [B<-batch>]
 [B<-msie_hack>]
 [B<-extensions section>]
+[B<-extfile section>]
 
 =head1 DESCRIPTION
 
@@ -54,6 +57,11 @@ The options descriptions will be divided into each purpose.
 
 specifies the configuration file to use.
 
+=item B<-name section>
+
+specifies the configuration file section to use (overrides
+B<default_ca> in the B<ca> section).
+
 =item B<-in filename>
 
 an input filename containing a single certificate request to be
@@ -104,6 +112,7 @@ the 'ps' utility) this option should be used with caution.
 
 the key password source. For more information about the format of B<arg>
 see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.
+
 =item B<-verbose>
 
 this prints extra details about the operations being performed.
@@ -154,6 +163,15 @@ is the same as the request. This is largely for compatibility with the
 older IE enrollment control which would only accept certificates if their
 DNs match the order of the request. This is not needed for Xenroll.
 
+=item B<-noemailDN>
+
+The DN of a certificate can contain the EMAIL field if present in the
+request DN, however it is good policy just having the e-mail set into
+the altName extension of the certificate. When this option is set the
+EMAIL field is removed from the certificate' subject and set only in
+the, eventually present, extensions. The B<email_in_dn> keyword can be
+used in the configuration file to enable this behaviour.
+
 =item B<-batch>
 
 this sets the batch mode. In this mode no questions will be asked
@@ -162,9 +180,16 @@ and all certificates will be certified automatically.
 =item B<-extensions section>
 
 the section of the configuration file containing certificate extensions
-to be added when a certificate is issued. If no extension section is
-present then a V1 certificate is created. If the extension section
-is present (even if it is empty) then a V3 certificate is created.
+to be added when a certificate is issued (defaults to B<x509_extensions>
+unless the B<-extfile> option is used). If no extension section is
+present then, a V1 certificate is created. If the extension section
+is present (even if it is empty), then a V3 certificate is created.
+
+=item B<-extfile file>
+
+an additional configuration file to read certificate extensions from
+(using the default section unless the B<-extensions> option is also
+used).
 
 =back
 
@@ -189,6 +214,12 @@ the number of hours before the next CRL is due.
 
 a filename containing a certificate to revoke.
 
+=item B<-subj arg>
+
+supersedes subject name given in the request.
+The arg must be formatted as I</type0=value0/type1=value1/type2=...>,
+characters may be escaped by \ (backslash), no spaces are skipped.
+
 =item B<-crlexts section>
 
 the section of the configuration file containing CRL extensions to
@@ -202,8 +233,20 @@ that some software (for example Netscape) can't handle V2 CRLs.
 
 =head1 CONFIGURATION FILE OPTIONS
 
-The options for B<ca> are contained in the B<ca> section of the
-configuration file. Many of these are identical to command line
+The section of the configuration file containing options for B<ca>
+is found as follows: If the B<-name> command line option is used,
+then it names the section to be used. Otherwise the section to
+be used must be named in the B<default_ca> option of the B<ca> section
+of the configuration file (or in the default section of the
+configuration file). Besides B<default_ca>, the following options are
+read directly from the B<ca> section:
+ RANDFILE
+ preserve
+ msie_hack
+With the exception of B<RANDFILE>, this is probably a bug and may
+change in future releases.
+
+Many of the configuration file options are identical to command line
 options. Where the option is present in the configuration file
 and the command line the command line value is used. Where an
 option is described as mandatory then it must be present in
@@ -294,6 +337,12 @@ the same as B<-crlexts>.
 
 the same as B<-preserveDN>
 
+=item B<email_in_dn>
+
+the same as B<-noemailDN>. If you want the EMAIL field to be removed
+from the DN of the certificate simply set this to 'no'. If not present
+the default is to allow for the EMAIL filed in the certificate's DN.
+
 =item B<msie_hack>
 
 the same as B<-msie_hack>
@@ -303,6 +352,37 @@ the same as B<-msie_hack>
 the same as B<-policy>. Mandatory. See the B<POLICY FORMAT> section
 for more information.
 
+=item B<nameopt>, B<certopt>
+
+these options allow the format used to display the certificate details
+when asking the user to confirm signing. All the options supported by
+the B<x509> utilities B<-nameopt> and B<-certopt> switches can be used
+here, except the B<no_signame> and B<no_sigdump> are permanently set
+and cannot be disabled (this is because the certificate signature cannot
+be displayed because the certificate has not been signed at this point).
+
+For convenience the values B<default_ca> are accepted by both to produce
+a reasonable output.
+
+If neither option is present the format used in earlier versions of
+OpenSSL is used. Use of the old format is B<strongly> discouraged because
+it only displays fields mentioned in the B<policy> section, mishandles
+multicharacter string types and does not display extensions.
+
+=item B<copy_extensions>
+
+determines how extensions in certificate requests should be handled.
+If set to B<none> or this option is not present then extensions are
+ignored and not copied to the certificate. If set to B<copy> then any
+extensions present in the request that are not already present are copied
+to the certificate. If set to B<copyall> then all extensions in the
+request are copied to the certificate: if the extension is already present
+in the certificate it is deleted first. See the B<WARNINGS> section before
+using this option.
+
+The main use of this option is to allow a certificate request to supply
+values for certain extensions such as subjectAltName.
+
 =back
 
 =head1 POLICY FORMAT
@@ -392,6 +472,11 @@ A sample configuration file with the relevant sections for B<ca>:
  default_md     = md5                   # md to use
 
  policy         = policy_any            # default policy
+ email_in_dn    = no                    # Don't add the email into cert DN
+
+ nameopt        = default_ca            # Subject name display option
+ certopt        = default_ca            # Certificate display option
+ copy_extensions = none                 # Don't copy extensions from request
 
  [ policy_any ]
  countryName            = supplied
@@ -406,7 +491,7 @@ A sample configuration file with the relevant sections for B<ca>:
 The B<ca> command is quirky and at times downright unfriendly.
 
 The B<ca> utility was originally meant as an example of how to do things
-in a CA. It was not supposed be be used as a full blown CA itself:
+in a CA. It was not supposed to be used as a full blown CA itself:
 nevertheless some people are using it for this purpose.
 
 The B<ca> command is effectively a single user command: no locking is
@@ -457,10 +542,6 @@ The use of an in memory text database can cause problems when large
 numbers of certificates are present because, as the name implies
 the database has to be kept in memory.
 
-Certificate request extensions are ignored: some kind of "policy" should
-be included to use certain static extensions and certain extensions
-from the request.
-
 It is not possible to certify two certificates with the same DN: this
 is a side effect of how the text database is indexed and it cannot easily
 be fixed without introducing other problems. Some S/MIME clients can use
@@ -473,13 +554,39 @@ exposed at either a command or interface level so a more friendly utility
 B<CA.pl> help a little but not very much.
 
 Any fields in a request that are not present in a policy are silently
-deleted. This does not happen if the B<-preserveDN> option is used but
-the extra fields are not displayed when the user is asked to certify
-a request. The behaviour should be more friendly and configurable.
+deleted. This does not happen if the B<-preserveDN> option is used. To
+enforce the absence of the EMAIL field within the DN, as suggested by
+RFCs, regardless the contents of the request' subject the B<-noemailDN>
+option can be used. The behaviour should be more friendly and
+configurable.
 
 Cancelling some commands by refusing to certify a certificate can
 create an empty file.
 
+=head1 WARNINGS
+
+The B<copy_extensions> option should be used with caution. If care is
+not taken then it can be a security risk. For example if a certificate
+request contains a basicConstraints extension with CA:TRUE and the
+B<copy_extensions> value is set to B<copyall> and the user does not spot
+this when the certificate is displayed then this will hand the requestor
+a valid CA certificate.
+
+This situation can be avoided by setting B<copy_extensions> to B<copy>
+and including basicConstraints with CA:FALSE in the configuration file.
+Then if the request contains a basicConstraints extension it will be
+ignored.
+
+It is advisable to also include values for other extensions such
+as B<keyUsage> to prevent a request supplying its own values.
+
+Additional restrictions can be placed on the CA certificate itself.
+For example if the CA certificate has:
+
+ basicConstraints = CA:TRUE, pathlen:0
+
+then even if a certificate is issued with CA:TRUE it will not be valid.
+
 =head1 SEE ALSO
 
 L<req(1)|req(1)>, L<spkac(1)|spkac(1)>, L<x509(1)|x509(1)>, L<CA.pl(1)|CA.pl(1)>,
diff --git a/src/lib/libssl/src/doc/apps/enc.pod b/src/lib/libssl/src/doc/apps/enc.pod
index a68ddca139..ddf081617f 100644
--- a/src/lib/libssl/src/doc/apps/enc.pod
+++ b/src/lib/libssl/src/doc/apps/enc.pod
@@ -21,6 +21,7 @@ B<openssl enc -ciphername>
 [B<-p>]
 [B<-P>]
 [B<-bufsize number>]
+[B<-nopad>]
 [B<-debug>]
 
 =head1 DESCRIPTION
@@ -122,6 +123,10 @@ or decryption.
 
 set the buffer size for I/O
 
+=item B<-nopad>
+
+disable standard block padding
+
 =item B<-debug>
 
 debug the BIOs used for I/O.
@@ -150,11 +155,14 @@ Some of the ciphers do not have large keys and others have security
 implications if not used correctly. A beginner is advised to just use
 a strong block cipher in CBC mode such as bf or des3.
 
-All the block ciphers use PKCS#5 padding also known as standard block
+All the block ciphers normally use PKCS#5 padding also known as standard block
 padding: this allows a rudimentary integrity or password check to be
 performed. However since the chance of random data passing the test is
 better than 1 in 256 it isn't a very good test.
 
+If padding is disabled then the input data must be a multiple of the cipher
+block length.
+
 All RC2 ciphers have the same key and effective key length.
 
 Blowfish and RC5 algorithms use a 128 bit key.
@@ -256,8 +264,8 @@ The B<-A> option when used with large files doesn't work properly.
 
 There should be an option to allow an iteration count to be included.
 
-Like the EVP library the B<enc> program only supports a fixed number of
-algorithms with certain parameters. So if, for example, you want to use RC2
-with a 76 bit key or RC4 with an 84 bit key you can't use this program.
+The B<enc> program only supports a fixed number of algorithms with
+certain parameters. So if, for example, you want to use RC2 with a
+76 bit key or RC4 with an 84 bit key you can't use this program.
 
 =cut
diff --git a/src/lib/libssl/src/doc/apps/ocsp.pod b/src/lib/libssl/src/doc/apps/ocsp.pod
new file mode 100644
index 0000000000..da201b95e6
--- /dev/null
+++ b/src/lib/libssl/src/doc/apps/ocsp.pod
@@ -0,0 +1,348 @@
+=pod
+
+=head1 NAME
+
+ocsp - Online Certificate Status Protocol utility
+
+=head1 SYNOPSIS
+
+B<openssl> B<ocsp>
+[B<-out file>]
+[B<-issuer file>]
+[B<-cert file>]
+[B<-serial n>]
+[B<-req_text>]
+[B<-resp_text>]
+[B<-text>]
+[B<-reqout file>]
+[B<-respout file>]
+[B<-reqin file>]
+[B<-respin file>]
+[B<-nonce>]
+[B<-no_nonce>]
+[B<-url responder_url>]
+[B<-host host:n>]
+[B<-path>]
+[B<-CApath file>]
+[B<-CAfile file>]
+[B<-VAfile file>]
+[B<-verify_certs file>]
+[B<-noverify>]
+[B<-trust_other>]
+[B<-no_intern>]
+[B<-no_sig_verify>]
+[B<-no_cert_verify>]
+[B<-no_chain>]
+[B<-no_cert_checks>]
+[B<-validity_period nsec>]
+[B<-status_age nsec>]
+
+=head1 DESCRIPTION
+
+B<WARNING: this documentation is preliminary and subject to change.>
+
+The Online Certificate Status Protocol (OCSP) enables applications to
+determine the (revocation) state of an identified certificate (RFC 2560).
+
+The B<ocsp> command performs many common OCSP tasks. It can be used
+to print out requests and responses, create requests and send queries
+to an OCSP responder and behave like a mini OCSP server itself.
+
+=head1 OCSP CLIENT OPTIONS
+
+=over 4
+
+=item B<-out filename>
+
+specify output filename, default is standard output.
+
+=item B<-issuer filename>
+
+This specifies the current issuer certificate. This option can be used
+multiple times. The certificate specified in B<filename> must be in
+PEM format.
+
+=item B<-cert filename>
+
+Add the certificate B<filename> to the request. The issuer certificate
+is taken from the previous B<issuer> option, or an error occurs if no
+issuer certificate is specified.
+
+=item B<-serial num>
+
+Same as the B<cert> option except the certificate with serial number
+B<num> is added to the request. The serial number is interpreted as a
+decimal integer unless preceded by B<0x>. Negative integers can also
+be specified by preceding the value by a B<-> sign.
+
+=item B<-signer filename>, B<-signkey filename>
+
+Sign the OCSP request using the certificate specified in the B<signer>
+option and the private key specified by the B<signkey> option. If
+the B<signkey> option is not present then the private key is read
+from the same file as the certificate. If neither option is specified then
+the OCSP request is not signed.
+
+=item B<-nonce>, B<-no_nonce>
+
+Add an OCSP nonce extension to a request or disable OCSP nonce addition.
+Normally if an OCSP request is input using the B<respin> option no
+nonce is added: using the B<nonce> option will force addition of a nonce.
+If an OCSP request is being created (using B<cert> and B<serial> options)
+a nonce is automatically added specifying B<no_nonce> overrides this.
+
+=item B<-req_text>, B<-resp_text>, B<-text>
+
+print out the text form of the OCSP request, response or both respectively.
+
+=item B<-reqout file>, B<-respout file>
+
+write out the DER encoded certificate request or response to B<file>.
+
+=item B<-reqin file>, B<-respin file>
+
+read OCSP request or response file from B<file>. These option are ignored
+if OCSP request or response creation is implied by other options (for example
+with B<serial>, B<cert> and B<host> options).
+
+=item B<-url responder_url>
+
+specify the responder URL. Both HTTP and HTTPS (SSL/TLS) URLs can be specified.
+
+=item B<-host hostname:port>, B<-path pathname>
+
+if the B<host> option is present then the OCSP request is sent to the host
+B<hostname> on port B<port>. B<path> specifies the HTTP path name to use
+or "/" by default.
+
+=item B<-CAfile file>, B<-CApath pathname>
+
+file or pathname containing trusted CA certificates. These are used to verify
+the signature on the OCSP response.
+
+=item B<-verify_certs file>
+
+file containing additional certificates to search when attempting to locate
+the OCSP response signing certificate. Some responders omit the actual signer's
+certificate from the response: this option can be used to supply the necessary
+certificate in such cases.
+
+=item B<-trust_other>
+
+the certificates specified by the B<-verify_certs> option should be explicitly
+trusted and no additional checks will be performed on them. This is useful
+when the complete responder certificate chain is not available or trusting a
+root CA is not appropriate.
+
+=item B<-VAfile file>
+
+file containing explicitly trusted responder certificates. Equivalent to the
+B<-verify_certs> and B<-trust_other> options.
+
+=item B<-noverify>
+
+don't attempt to verify the OCSP response signature or the nonce values. This
+option will normally only be used for debugging since it disables all verification
+of the responders certificate.
+
+=item B<-no_intern>
+
+ignore certificates contained in the OCSP response when searching for the
+signers certificate. With this option the signers certificate must be specified
+with either the B<-verify_certs> or B<-VAfile> options.
+
+=item B<-no_sig_verify>
+
+don't check the signature on the OCSP response. Since this option tolerates invalid
+signatures on OCSP responses it will normally only be used for testing purposes.
+
+=item B<-no_cert_verify>
+
+don't verify the OCSP response signers certificate at all. Since this option allows
+the OCSP response to be signed by any certificate it should only be used for
+testing purposes.
+
+=item B<-no_chain>
+
+do not use certificates in the response as additional untrusted CA
+certificates.
+
+=item B<-no_cert_checks>
+
+don't perform any additional checks on the OCSP response signers certificate.
+That is do not make any checks to see if the signers certificate is authorised
+to provide the necessary status information: as a result this option should
+only be used for testing purposes.
+
+=item B<-validity_period nsec>, B<-status_age age>
+
+these options specify the range of times, in seconds, which will be tolerated
+in an OCSP response. Each certificate status response includes a B<notBefore> time and
+an optional B<notAfter> time. The current time should fall between these two values, but
+the interval between the two times may be only a few seconds. In practice the OCSP
+responder and clients clocks may not be precisely synchronised and so such a check
+may fail. To avoid this the B<-validity_period> option can be used to specify an
+acceptable error range in seconds, the default value is 5 minutes.
+
+If the B<notAfter> time is omitted from a response then this means that new status
+information is immediately available. In this case the age of the B<notBefore> field
+is checked to see it is not older than B<age> seconds old. By default this additional
+check is not performed.
+
+=back
+
+=head1 OCSP SERVER OPTIONS
+
+=over 4
+
+=item B<-index indexfile>
+
+B<indexfile> is a text index file in B<ca> format containing certificate revocation
+information.
+
+If the B<index> option is specified the B<ocsp> utility is in responder mode, otherwise
+it is in client mode. The request(s) the responder processes can be either specified on
+the command line (using B<issuer> and B<serial> options), supplied in a file (using the
+B<respin> option) or via external OCSP clients (if B<port> or B<url> is specified).
+
+If the B<index> option is present then the B<CA> and B<rsigner> options must also be
+present.
+
+=item B<-CA file>
+
+CA certificate corresponding to the revocation information in B<indexfile>.
+
+=item B<-rsigner file>
+
+The certificate to sign OCSP responses with.
+
+=item B<-rother file>
+
+Additional certificates to include in the OCSP response.
+
+=item B<-resp_no_certs>
+
+Don't include any certificates in the OCSP response.
+
+=item B<-resp_key_id>
+
+Identify the signer certificate using the key ID, default is to use the subject name.
+
+=item B<-rkey file>
+
+The private key to sign OCSP responses with: if not present the file specified in the
+B<rsigner> option is used.
+
+=item B<-port portnum>
+
+Port to listen for OCSP requests on. The port may also be specified using the B<url>
+option.
+
+=item B<-nrequest number>
+
+The OCSP server will exit after receiving B<number> requests, default unlimited. 
+
+=item B<-nmin minutes>, B<-ndays days>
+
+Number of minutes or days when fresh revocation information is available: used in the
+B<nextUpdate> field. If neither option is present then the B<nextUpdate> field is 
+omitted meaning fresh revocation information is immediately available.
+
+=back
+
+=head1 OCSP Response verification.
+
+OCSP Response follows the rules specified in RFC2560.
+
+Initially the OCSP responder certificate is located and the signature on
+the OCSP request checked using the responder certificate's public key.
+
+Then a normal certificate verify is performed on the OCSP responder certificate
+building up a certificate chain in the process. The locations of the trusted
+certificates used to build the chain can be specified by the B<CAfile>
+and B<CApath> options or they will be looked for in the standard OpenSSL
+certificates directory.
+
+If the initial verify fails then the OCSP verify process halts with an
+error.
+
+Otherwise the issuing CA certificate in the request is compared to the OCSP
+responder certificate: if there is a match then the OCSP verify succeeds.
+
+Otherwise the OCSP responder certificate's CA is checked against the issuing
+CA certificate in the request. If there is a match and the OCSPSigning
+extended key usage is present in the OCSP responder certificate then the
+OCSP verify succeeds.
+
+Otherwise the root CA of the OCSP responders CA is checked to see if it
+is trusted for OCSP signing. If it is the OCSP verify succeeds.
+
+If none of these checks is successful then the OCSP verify fails.
+
+What this effectively means if that if the OCSP responder certificate is
+authorised directly by the CA it is issuing revocation information about
+(and it is correctly configured) then verification will succeed.
+
+If the OCSP responder is a "global responder" which can give details about
+multiple CAs and has its own separate certificate chain then its root
+CA can be trusted for OCSP signing. For example:
+
+ openssl x509 -in ocspCA.pem -addtrust OCSPSigning -out trustedCA.pem
+
+Alternatively the responder certificate itself can be explicitly trusted
+with the B<-VAfile> option.
+
+=head1 NOTES
+
+As noted, most of the verify options are for testing or debugging purposes.
+Normally only the B<-CApath>, B<-CAfile> and (if the responder is a 'global
+VA') B<-VAfile> options need to be used.
+
+The OCSP server is only useful for test and demonstration purposes: it is
+not really usable as a full OCSP responder. It contains only a very
+simple HTTP request handling and can only handle the POST form of OCSP
+queries. It also handles requests serially meaning it cannot respond to
+new requests until it has processed the current one. The text index file
+format of revocation is also inefficient for large quantities of revocation
+data.
+
+It is possible to run the B<ocsp> application in responder mode via a CGI
+script using the B<respin> and B<respout> options.
+
+=head1 EXAMPLES
+
+Create an OCSP request and write it to a file:
+
+ openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem -reqout req.der
+
+Send a query to an OCSP responder with URL http://ocsp.myhost.com/ save the 
+response to a file and print it out in text form
+
+ openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \
+     -url http://ocsp.myhost.com/ -resp_text -respout resp.der
+
+Read in an OCSP response and print out text form:
+
+ openssl ocsp -respin resp.der -text
+
+OCSP server on port 8888 using a standard B<ca> configuration, and a separate
+responder certificate. All requests and responses are printed to a file.
+
+ openssl ocsp -index demoCA/index.txt -port 8888 -rsigner rcert.pem -CA demoCA/cacert.pem
+        -text -out log.txt
+
+As above but exit after processing one request:
+
+ openssl ocsp -index demoCA/index.txt -port 8888 -rsigner rcert.pem -CA demoCA/cacert.pem
+     -nrequest 1
+
+Query status information using internally generated request:
+
+ openssl ocsp -index demoCA/index.txt -rsigner rcert.pem -CA demoCA/cacert.pem
+     -issuer demoCA/cacert.pem -serial 1
+
+Query status information using request read from a file, write response to a
+second file.
+
+ openssl ocsp -index demoCA/index.txt -rsigner rcert.pem -CA demoCA/cacert.pem
+     -reqin req.der -respout resp.der
diff --git a/src/lib/libssl/src/doc/apps/openssl.pod b/src/lib/libssl/src/doc/apps/openssl.pod
index 0cbd199d79..07dd80eabe 100644
--- a/src/lib/libssl/src/doc/apps/openssl.pod
+++ b/src/lib/libssl/src/doc/apps/openssl.pod
@@ -121,10 +121,18 @@ Generation of DSA Parameters.
 
 Generation of RSA Parameters.
 
+=item L<B<ocsp>|ocsp(1)>
+
+Online Certificate Status Protocol utility.
+
 =item L<B<passwd>|passwd(1)>
 
 Generation of hashed passwords.
 
+=item L<B<pkcs12>|pkcs12(1)>
+
+PKCS#12 Data Management.
+
 =item L<B<pkcs7>|pkcs7(1)>
 
 PKCS#7 Data Management.
diff --git a/src/lib/libssl/src/doc/apps/passwd.pod b/src/lib/libssl/src/doc/apps/passwd.pod
index 6e098940c7..07d849c824 100644
--- a/src/lib/libssl/src/doc/apps/passwd.pod
+++ b/src/lib/libssl/src/doc/apps/passwd.pod
@@ -13,6 +13,7 @@ B<openssl passwd>
 [B<-salt> I<string>]
 [B<-in> I<file>]
 [B<-stdin>]
+[B<-noverify>]
 [B<-quiet>]
 [B<-table>]
 {I<password>}
@@ -22,7 +23,7 @@ B<openssl passwd>
 The B<passwd> command computes the hash of a password typed at
 run-time or the hash of each password in a list.  The password list is
 taken from the named file for option B<-in file>, from stdin for
-option B<-stdin>, and from the command line otherwise.
+option B<-stdin>, or from the command line, or from the terminal otherwise.
 The Unix standard algorithm B<crypt> and the MD5-based BSD password
 algorithm B<1> and its Apache variant B<apr1> are available.
 
@@ -45,6 +46,7 @@ Use the B<apr1> algorithm (Apache variant of the BSD algorithm).
 =item B<-salt> I<string>
 
 Use the specified salt.
+When reading a password from the terminal, this implies B<-noverify>.
 
 =item B<-in> I<file>
 
@@ -54,6 +56,10 @@ Read passwords from I<file>.
 
 Read passwords from B<stdin>.
 
+=item B<-noverify>
+
+Don't verify when reading a password from the terminal.
+
 =item B<-quiet>
 
 Don't output warnings when passwords given at the command line are truncated.
diff --git a/src/lib/libssl/src/doc/apps/pkcs12.pod b/src/lib/libssl/src/doc/apps/pkcs12.pod
index 7e0307dda0..7d84146293 100644
--- a/src/lib/libssl/src/doc/apps/pkcs12.pod
+++ b/src/lib/libssl/src/doc/apps/pkcs12.pod
@@ -262,7 +262,7 @@ the one corresponding to the private key. Certain software which requires
 a private key and certificate and assumes the first certificate in the
 file is the one corresponding to the private key: this may not always
 be the case. Using the B<-clcerts> option will solve this problem by only
-outputing the certificate corresponding to the private key. If the CA
+outputting the certificate corresponding to the private key. If the CA
 certificates are required then they can be output to a separate file using
 the B<-nokeys -cacerts> options to just output CA certificates.
 
diff --git a/src/lib/libssl/src/doc/apps/pkcs7.pod b/src/lib/libssl/src/doc/apps/pkcs7.pod
index 4e9bd6e46b..9871c0e0cd 100644
--- a/src/lib/libssl/src/doc/apps/pkcs7.pod
+++ b/src/lib/libssl/src/doc/apps/pkcs7.pod
@@ -78,7 +78,7 @@ The PEM PKCS#7 format uses the header and footer lines:
  -----BEGIN PKCS7-----
  -----END PKCS7-----
 
-For compatability with some CAs it will also accept:
+For compatibility with some CAs it will also accept:
 
  -----BEGIN CERTIFICATE-----
  -----END CERTIFICATE-----
diff --git a/src/lib/libssl/src/doc/apps/rand.pod b/src/lib/libssl/src/doc/apps/rand.pod
index cbf8768801..75745ca002 100644
--- a/src/lib/libssl/src/doc/apps/rand.pod
+++ b/src/lib/libssl/src/doc/apps/rand.pod
@@ -15,7 +15,7 @@ I<num>
 =head1 DESCRIPTION
 
 The B<rand> command outputs I<num> pseudo-random bytes after seeding
-the random number generater once.  As in other B<openssl> command
+the random number generator once.  As in other B<openssl> command
 line tools, PRNG seeding uses the file I<$HOME/>B<.rnd> or B<.rnd>
 in addition to the files given in the B<-rand> option.  A new
 I<$HOME>/B<.rnd> or B<.rnd> file will be written back if enough
diff --git a/src/lib/libssl/src/doc/apps/req.pod b/src/lib/libssl/src/doc/apps/req.pod
index a3f54f45a3..10e4e12a5c 100644
--- a/src/lib/libssl/src/doc/apps/req.pod
+++ b/src/lib/libssl/src/doc/apps/req.pod
@@ -3,7 +3,7 @@
 
 =head1 NAME
 
-req - PKCS#10 certificate and certificate generating utility.
+req - PKCS#10 certificate request and certificate generating utility.
 
 =head1 SYNOPSIS
 
@@ -15,6 +15,7 @@ B<openssl> B<req>
 [B<-out filename>]
 [B<-passout arg>]
 [B<-text>]
+[B<-pubkey>]
 [B<-noout>]
 [B<-verify>]
 [B<-modulus>]
@@ -28,12 +29,18 @@ B<openssl> B<req>
 [B<-keyout filename>]
 [B<-[md5|sha1|md2|mdc2]>]
 [B<-config filename>]
+[B<-subj arg>]
 [B<-x509>]
 [B<-days n>]
+[B<-set_serial n>]
 [B<-asn1-kludge>]
 [B<-newhdr>]
 [B<-extensions section>]
 [B<-reqexts section>]
+[B<-utf8>]
+[B<-nameopt>]
+[B<-batch>]
+[B<-verbose>]
 
 =head1 DESCRIPTION
 
@@ -82,6 +89,10 @@ see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.
 
 prints out the certificate request in text form.
 
+=item B<-pubkey>
+
+outputs the public key.
+
 =item B<-noout>
 
 this option prevents output of the encoded version of the request.
@@ -154,18 +165,33 @@ this allows an alternative configuration file to be specified,
 this overrides the compile time filename or any specified in
 the B<OPENSSL_CONF> environment variable.
 
+=item B<-subj arg>
+
+sets subject name for new request or supersedes the subject name
+when processing a request.
+The arg must be formatted as I</type0=value0/type1=value1/type2=...>,
+characters may be escaped by \ (backslash), no spaces are skipped.
+
 =item B<-x509>
 
 this option outputs a self signed certificate instead of a certificate
 request. This is typically used to generate a test certificate or
 a self signed root CA. The extensions added to the certificate
-(if any) are specified in the configuration file.
+(if any) are specified in the configuration file. Unless specified
+using the B<set_serial> option B<0> will be used for the serial
+number.
 
 =item B<-days n>
 
 when the B<-x509> option is being used this specifies the number of
 days to certify the certificate for. The default is 30 days.
 
+=item B<-set_serial n>
+
+serial number to use when outputting a self signed certificate. This
+may be specified as a decimal value or a hex value if preceded by B<0x>.
+It is possible to use negative serial numbers but this is not recommended.
+
 =item B<-extensions section>
 
 =item B<-reqexts section>
@@ -176,6 +202,20 @@ request extensions. This allows several different sections to
 be used in the same configuration file to specify requests for
 a variety of purposes.
 
+=item B<-utf8>
+
+this option causes field values to be interpreted as UTF8 strings, by 
+default they are interpreted as ASCII. This means that the field
+values, whether prompted from a terminal or obtained from a
+configuration file, must be valid UTF8 strings.
+
+=item B<-nameopt option>
+
+option which determines how the subject or issuer names are displayed. The
+B<option> argument can be a single option or multiple options separated by
+commas.  Alternatively the B<-nameopt> switch may be used more than once to
+set multiple options. See the L<x509(1)|x509(1)> manual page for details.
+
 =item B<-asn1-kludge>
 
 by default the B<req> command outputs certificate requests containing
@@ -196,6 +236,14 @@ It should be noted that very few CAs still require the use of this option.
 Adds the word B<NEW> to the PEM file header and footer lines on the outputed
 request. Some software (Netscape certificate server) and some CAs need this.
 
+=item B<-batch>
+
+non-interactive mode.
+
+=item B<-verbose>
+
+print extra details about the operations being performed.
+
 =back
 
 =head1 CONFIGURATION FILE FORMAT
@@ -292,6 +340,13 @@ if set to the value B<no> this disables prompting of certificate fields
 and just takes values from the config file directly. It also changes the
 expected format of the B<distinguished_name> and B<attributes> sections.
 
+=item B<utf8>
+
+if set to the value B<yes> then field values to be interpreted as UTF8
+strings, by default they are interpreted as ASCII. This means that
+the field values, whether prompted from a terminal or obtained from a
+configuration file, must be valid UTF8 strings.
+
 =item B<attributes>
 
 this specifies the section containing any request attributes: its format
diff --git a/src/lib/libssl/src/doc/apps/rsa.pod b/src/lib/libssl/src/doc/apps/rsa.pod
index f0e613ed05..ef74f1adff 100644
--- a/src/lib/libssl/src/doc/apps/rsa.pod
+++ b/src/lib/libssl/src/doc/apps/rsa.pod
@@ -136,7 +136,7 @@ and Microsoft IIS .key files, this uses unsalted RC4 for its encryption.
 It is not very secure and so should only be used when necessary.
 
 Some newer version of IIS have additional data in the exported .key
-files. To use thse with the utility view the file with a binary editor
+files. To use these with the utility, view the file with a binary editor
 and look for the string "private-key", then trace back to the byte
 sequence 0x30, 0x82 (this is an ASN1 SEQUENCE). Copy all the data
 from this point onwards to another file and use that as the input
diff --git a/src/lib/libssl/src/doc/apps/s_client.pod b/src/lib/libssl/src/doc/apps/s_client.pod
index 078ff086c3..7fca9cbdbd 100644
--- a/src/lib/libssl/src/doc/apps/s_client.pod
+++ b/src/lib/libssl/src/doc/apps/s_client.pod
@@ -18,6 +18,7 @@ B<openssl> B<s_client>
 [B<-pause>]
 [B<-showcerts>]
 [B<-debug>]
+[B<-msg>]
 [B<-nbio_test>]
 [B<-state>]
 [B<-nbio>]
@@ -32,8 +33,8 @@ B<openssl> B<s_client>
 [B<-no_tls1>]
 [B<-bugs>]
 [B<-cipher cipherlist>]
-[B<-rand file(s)>]
 [B<-engine id>]
+[B<-rand file(s)>]
 
 =head1 DESCRIPTION
 
@@ -112,6 +113,10 @@ prints out the SSL session states.
 
 print extensive debugging information including a hex dump of all traffic.
 
+=item B<-msg>
+
+show all protocol messages with hex dump.
+
 =item B<-nbio_test>
 
 tests non-blocking I/O
@@ -132,7 +137,7 @@ input.
 
 =item B<-quiet>
 
-inhibit printing of session and certificate information.  This implicitely
+inhibit printing of session and certificate information.  This implicitly
 turns on B<-ign_eof> as well.
 
 =item B<-ssl2>, B<-ssl3>, B<-tls1>, B<-no_ssl2>, B<-no_ssl3>, B<-no_tls1>
@@ -158,6 +163,13 @@ the server determines which cipher suite is used it should take the first
 supported cipher in the list sent by the client. See the B<ciphers>
 command for more information.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<s_client>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =item B<-rand file(s)>
 
 a file or files containing random data used to seed the random number
@@ -166,13 +178,6 @@ Multiple files can be specified separated by a OS-dependent character.
 The separator is B<;> for MS-Windows, B<,> for OpenVMS, and B<:> for
 all others.
 
-=item B<-engine id>
-
-specifying an engine (by it's unique B<id> string) will cause B<s_client>
-to attempt to obtain a functional reference to the specified engine,
-thus initialising it if needed. The engine will then be set as the default
-for all available algorithms.
-
 =back
 
 =head1 CONNECTED COMMANDS
@@ -180,7 +185,7 @@ for all available algorithms.
 If a connection is established with an SSL server then any data received
 from the server is displayed and any key presses will be sent to the
 server. When used interactively (which means neither B<-quiet> nor B<-ign_eof>
-have been given), the session will be renegociated if the line begins with an
+have been given), the session will be renegotiated if the line begins with an
 B<R>, and if the line begins with a B<Q> or if end of file is reached, the
 connection will be closed down.
 
diff --git a/src/lib/libssl/src/doc/apps/s_server.pod b/src/lib/libssl/src/doc/apps/s_server.pod
index 313116ab66..4b1e4260ef 100644
--- a/src/lib/libssl/src/doc/apps/s_server.pod
+++ b/src/lib/libssl/src/doc/apps/s_server.pod
@@ -21,6 +21,7 @@ B<openssl> B<s_server>
 [B<-nbio_test>]
 [B<-crlf>]
 [B<-debug>]
+[B<-msg>]
 [B<-state>]
 [B<-CApath directory>]
 [B<-CAfile filename>]
@@ -39,8 +40,9 @@ B<openssl> B<s_server>
 [B<-hack>]
 [B<-www>]
 [B<-WWW>]
-[B<-rand file(s)>]
+[B<-HTTP>]
 [B<-engine id>]
+[B<-rand file(s)>]
 
 =head1 DESCRIPTION
 
@@ -135,6 +137,10 @@ prints out the SSL session states.
 
 print extensive debugging information including a hex dump of all traffic.
 
+=item B<-msg>
+
+show all protocol messages with hex dump.
+
 =item B<-nbio_test>
 
 tests non blocking I/O
@@ -188,13 +194,13 @@ emulates a simple web server. Pages will be resolved relative to the
 current directory, for example if the URL https://myhost/page.html is
 requested the file ./page.html will be loaded.
 
-=item B<-rand file(s)>
+=item B<-HTTP>
 
-a file or files containing random data used to seed the random number
-generator, or an EGD socket (see L<RAND_egd(3)|RAND_egd(3)>).
-Multiple files can be specified separated by a OS-dependent character.
-The separator is B<;> for MS-Windows, B<,> for OpenVMS, and B<:> for
-all others.
+emulates a simple web server. Pages will be resolved relative to the
+current directory, for example if the URL https://myhost/page.html is
+requested the file ./page.html will be loaded. The files loaded are
+assumed to contain a complete and correct HTTP response (lines that
+are part of the HTTP response line and headers must end with CRLF).
 
 =item B<-engine id>
 
@@ -203,6 +209,14 @@ to attempt to obtain a functional reference to the specified engine,
 thus initialising it if needed. The engine will then be set as the default
 for all available algorithms.
 
+=item B<-rand file(s)>
+
+a file or files containing random data used to seed the random number
+generator, or an EGD socket (see L<RAND_egd(3)|RAND_egd(3)>).
+Multiple files can be specified separated by a OS-dependent character.
+The separator is B<;> for MS-Windows, B<,> for OpenVMS, and B<:> for
+all others.
+
 =back
 
 =head1 CONNECTED COMMANDS
diff --git a/src/lib/libssl/src/doc/apps/verify.pod b/src/lib/libssl/src/doc/apps/verify.pod
index 90455525d1..ea5c29c150 100644
--- a/src/lib/libssl/src/doc/apps/verify.pod
+++ b/src/lib/libssl/src/doc/apps/verify.pod
@@ -200,13 +200,13 @@ the signature of the certificate is invalid. Unused.
 
 the certificate is not yet valid: the notBefore date is after the current time.
 
-=item B<10 X509_V_ERR_CRL_NOT_YET_VALID: CRL is not yet valid>
+=item B<10 X509_V_ERR_CERT_HAS_EXPIRED: certificate has expired>
 
-the CRL is not yet valid. Unused.
+the certificate has expired: that is the notAfter date is before the current time.
 
-=item B<11 X509_V_ERR_CERT_HAS_EXPIRED: Certificate has expired>
+=item B<11 X509_V_ERR_CRL_NOT_YET_VALID: CRL is not yet valid>
 
-the certificate has expired: that is the notAfter date is before the current time.
+the CRL is not yet valid. Unused.
 
 =item B<12 X509_V_ERR_CRL_HAS_EXPIRED: CRL has expired>
 
diff --git a/src/lib/libssl/src/doc/apps/version.pod b/src/lib/libssl/src/doc/apps/version.pod
index 5d261a6405..e00324c446 100644
--- a/src/lib/libssl/src/doc/apps/version.pod
+++ b/src/lib/libssl/src/doc/apps/version.pod
@@ -46,6 +46,10 @@ compilation flags.
 
 platform setting.
 
+=item B<-d>
+
+OPENSSLDIR setting.
+
 =back
 
 =head1 NOTES
@@ -53,4 +57,8 @@ platform setting.
 The output of B<openssl version -a> would typically be used when sending
 in a bug report.
 
+=head1 HISTORY
+
+The B<-d> option was added in OpenSSL 0.9.7.
+
 =cut
diff --git a/src/lib/libssl/src/doc/apps/x509.pod b/src/lib/libssl/src/doc/apps/x509.pod
index 84f76cb421..23367b7659 100644
--- a/src/lib/libssl/src/doc/apps/x509.pod
+++ b/src/lib/libssl/src/doc/apps/x509.pod
@@ -36,6 +36,7 @@ B<openssl> B<x509>
 [B<-addreject arg>]
 [B<-setalias arg>]
 [B<-days arg>]
+[B<-set_serial n>]
 [B<-signkey filename>]
 [B<-x509toreq>]
 [B<-req>]
@@ -112,6 +113,13 @@ prints out the certificate in text form. Full details are output including the
 public key, signature algorithms, issuer and subject names, serial number
 any extensions present and any trust settings.
 
+=item B<-certopt option>
+
+customise the output format used with B<-text>. The B<option> argument can be
+a single option or multiple options separated by commas. The B<-certopt> switch
+may be also be used more than once to set multiple options. See the B<TEXT OPTIONS>
+section for more information.
+
 =item B<-noout>
 
 this option prevents output of the encoded version of the request.
@@ -141,9 +149,10 @@ outputs the issuer name.
 
 =item B<-nameopt option>
 
-option which determine how the subject or issuer names are displayed. This
-option may be used more than once to set multiple options. See the B<NAME
-OPTIONS> section for more information.
+option which determines how the subject or issuer names are displayed. The
+B<option> argument can be a single option or multiple options separated by
+commas.  Alternatively the B<-nameopt> switch may be used more than once to
+set multiple options. See the B<NAME OPTIONS> section for more information.
 
 =item B<-email>
 
@@ -163,7 +172,8 @@ prints out the start and expiry dates of a certificate.
 
 =item B<-fingerprint>
 
-prints out the digest of the DER encoded version of the whole certificate.
+prints out the digest of the DER encoded version of the whole certificate
+(see digest options).
 
 =item B<-C>
 
@@ -292,6 +302,16 @@ is used to pass the required private key.
 by default a certificate is expected on input. With this option a
 certificate request is expected instead.
 
+=item B<-set_serial n>
+
+specifies the serial number to use. This option can be used with either
+the B<-signkey> or B<-CA> options. If used in conjunction with the B<-CA>
+option the serial number file (as specified by the B<-CAserial> or
+B<-CAcreateserial> options) is not used.
+
+The serial number can be decimal or hex (if preceded by B<0x>). Negative
+serial numbers can also be specified but their use is not recommended.
+
 =item B<-CA filename>
 
 specifies the CA certificate to be used for signing. When this option is
@@ -372,12 +392,12 @@ options.
 =item B<multiline>
 
 a multiline format. It is equivalent B<esc_ctrl>, B<esc_msb>, B<sep_multiline>,
-B<spc_eq> and B<lname>.
+B<spc_eq>, B<lname> and B<align>.
 
 =item B<esc_2253>
 
 escape the "special" characters required by RFC2253 in a field That is
-B<,+"E<lt>E<gt>;>. Additionally B<#> is escaped at the beginnging of a string
+B<,+"E<lt>E<gt>;>. Additionally B<#> is escaped at the beginning of a string
 and a space character at the beginning or end of a string.
 
 =item B<esc_ctrl>
@@ -431,7 +451,7 @@ B<#XXXX...> format.
 
 dump non character string types (for example OCTET STRING) if this
 option is not set then non character string types will be displayed
-as though each content octet repesents a single character.
+as though each content octet represents a single character.
 
 =item B<dump_all>
 
@@ -467,6 +487,11 @@ not display the field at all. B<sname> uses the "short name" form
 B<oid> represents the OID in numerical form and is useful for
 diagnostic purpose.
 
+=item B<align>
+
+align field values for a more readable output. Only usable with
+B<sep_multiline>.
+
 =item B<spc_eq>
 
 places spaces round the B<=> character which follows the field
@@ -474,6 +499,87 @@ name.
 
 =back
 
+=head1 TEXT OPTIONS
+
+As well as customising the name output format, it is also possible to
+customise the actual fields printed using the B<certopt> options when
+the B<text> option is present. The default behaviour is to print all fields.
+
+=item B<compatible>
+
+use the old format. This is equivalent to specifying no output options at all.
+
+=item B<no_header>
+
+don't print header information: that is the lines saying "Certificate" and "Data".
+
+=item B<no_version>
+
+don't print out the version number.
+
+=item B<no_serial>
+
+don't print out the serial number.
+
+=item B<no_signame>
+
+don't print out the signature algorithm used.
+
+=item B<no_validity>
+
+don't print the validity, that is the B<notBefore> and B<notAfter> fields.
+
+=item B<no_subject>
+
+don't print out the subject name.
+
+=item B<no_issuer>
+
+don't print out the issuer name.
+
+=item B<no_pubkey>
+
+don't print out the public key.
+
+=item B<no_sigdump>
+
+don't give a hexadecimal dump of the certificate signature.
+
+=item B<no_aux>
+
+don't print out certificate trust information.
+
+=item B<no_extensions>
+
+don't print out any X509V3 extensions.
+
+=item B<ext_default>
+
+retain default extension behaviour: attempt to print out unsupported certificate extensions.
+
+=item B<ext_error>
+
+print an error message for unsupported certificate extensions.
+
+=item B<ext_parse>
+
+ASN1 parse unsupported extensions.
+
+=item B<ext_dump>
+
+hex dump unsupported extensions.
+
+=item B<ca_default>
+
+the value used by the B<ca> utility, equivalent to B<no_issuer>, B<no_pubkey>, B<no_header>,
+B<no_version>, B<no_sigdump> and B<no_signame>.
+
+
+
+=over 4
+
+=back
+
 =head1 EXAMPLES
 
 Note: in these examples the '\' means the example should be all on one
@@ -498,7 +604,7 @@ Display the certificate subject name in RFC2253 form:
 Display the certificate subject name in oneline form on a terminal
 supporting UTF8:
 
- openssl x509 -in cert.pem -noout -subject -nameopt oneline -nameopt -escmsb
+ openssl x509 -in cert.pem -noout -subject -nameopt oneline,-escmsb
 
 Display the certificate MD5 fingerprint:
 
diff --git a/src/lib/libssl/src/doc/crypto/BIO_f_md.pod b/src/lib/libssl/src/doc/crypto/BIO_f_md.pod
index c32504dfb1..0d24083e6d 100644
--- a/src/lib/libssl/src/doc/crypto/BIO_f_md.pod
+++ b/src/lib/libssl/src/doc/crypto/BIO_f_md.pod
@@ -28,7 +28,7 @@ BIO_gets(), if its B<size> parameter is large enough finishes the
 digest calculation and returns the digest value. BIO_puts() is
 not supported.
 
-BIO_reset() reinitializes a digest BIO.
+BIO_reset() reinitialises a digest BIO.
 
 BIO_set_md() sets the message digest of BIO B<b> to B<md>: this
 must be called to initialize a digest BIO before any data is
diff --git a/src/lib/libssl/src/doc/crypto/BIO_new_bio_pair.pod b/src/lib/libssl/src/doc/crypto/BIO_new_bio_pair.pod
index 2256ba9d34..1a8dbc577b 100644
--- a/src/lib/libssl/src/doc/crypto/BIO_new_bio_pair.pod
+++ b/src/lib/libssl/src/doc/crypto/BIO_new_bio_pair.pod
@@ -12,7 +12,8 @@ BIO_new_bio_pair - create a new BIO pair
 
 =head1 DESCRIPTION
 
-BIO_new_bio_pair() creates a buffering BIO pair. It has two endpoints between
+BIO_new_bio_pair() creates a buffering BIO pair based on the
+L<SSL_set_bio(3)|SSL_set_bio(3)> method. The BIO pair has two endpoints between which
 data can be buffered. Its typical use is to connect one endpoint as underlying
 input/output BIO to an SSL and access the other one controlled by the program
 instead of accessing the network connection directly.
@@ -38,7 +39,7 @@ without having to go through the SSL-interface.
  BIO *internal_bio, *network_bio;
  ...
  BIO_new_bio_pair(internal_bio, 0, network_bio, 0);
- SSL_set_bio(ssl, internal_bio);
+ SSL_set_bio(ssl, internal_bio, internal_bio);
  SSL_operations();
  ...
 
@@ -67,7 +68,7 @@ and must be transfered to the network. Use BIO_ctrl_get_read_request() to
 find out, how many bytes must be written into the buffer before the
 SSL_operation() can successfully be continued.
 
-=head1 IMPORTANT
+=head1 WARNING
 
 As the data is buffered, SSL_operation() may return with a ERROR_SSL_WANT_READ
 condition, but there is still data in the write buffer. An application must
diff --git a/src/lib/libssl/src/doc/crypto/BIO_s_accept.pod b/src/lib/libssl/src/doc/crypto/BIO_s_accept.pod
index c49da7fb02..55e4b730b9 100644
--- a/src/lib/libssl/src/doc/crypto/BIO_s_accept.pod
+++ b/src/lib/libssl/src/doc/crypto/BIO_s_accept.pod
@@ -10,31 +10,31 @@ BIO_get_bind_mode, BIO_do_accept - accept BIO
 
  #include <openssl/bio.h>
 
- BIO_METHOD * BIO_s_accept(void);
+ BIO_METHOD *BIO_s_accept(void);
 
- #define BIO_set_accept_port(b,name) BIO_ctrl(b,BIO_C_SET_ACCEPT,0,(char *)name)
- #define BIO_get_accept_port(b) BIO_ptr_ctrl(b,BIO_C_GET_ACCEPT,0)
+ long BIO_set_accept_port(BIO *b, char *name);
+ char *BIO_get_accept_port(BIO *b);
 
  BIO *BIO_new_accept(char *host_port);
 
- #define BIO_set_nbio_accept(b,n) BIO_ctrl(b,BIO_C_SET_ACCEPT,1,(n)?"a":NULL)
- #define BIO_set_accept_bios(b,bio) BIO_ctrl(b,BIO_C_SET_ACCEPT,2,(char *)bio)
+ long BIO_set_nbio_accept(BIO *b, int n);
+ long BIO_set_accept_bios(BIO *b, char *bio);
 
- #define BIO_set_bind_mode(b,mode) BIO_ctrl(b,BIO_C_SET_BIND_MODE,mode,NULL)
- #define BIO_get_bind_mode(b,mode) BIO_ctrl(b,BIO_C_GET_BIND_MODE,0,NULL)
+ long BIO_set_bind_mode(BIO *b, long mode);
+ long BIO_get_bind_mode(BIO *b, long dummy);
 
  #define BIO_BIND_NORMAL                0
  #define BIO_BIND_REUSEADDR_IF_UNUSED   1
  #define BIO_BIND_REUSEADDR             2
 
- #define BIO_do_accept(b)       BIO_do_handshake(b)
+ int BIO_do_accept(BIO *b);
 
 =head1 DESCRIPTION
 
 BIO_s_accept() returns the accept BIO method. This is a wrapper
 round the platform's TCP/IP socket accept routines.
 
-Using accept BIOs TCP/IP connections can be accepted and data
+Using accept BIOs, TCP/IP connections can be accepted and data
 transferred using only BIO routines. In this way any platform
 specific operations are hidden by the BIO abstraction.
 
@@ -92,7 +92,7 @@ BIO_do_accept() serves two functions. When it is first
 called, after the accept BIO has been setup, it will attempt
 to create the accept socket and bind an address to it. Second
 and subsequent calls to BIO_do_accept() will await an incoming
-connection.
+connection, or request a retry in non blocking mode.
 
 =head1 NOTES
 
@@ -130,6 +130,17 @@ however because the accept BIO will still accept additional incoming
 connections. This can be resolved by using BIO_pop() (see above)
 and freeing up the accept BIO after the initial connection.
 
+If the underlying accept socket is non-blocking and BIO_do_accept() is
+called to await an incoming connection it is possible for
+BIO_should_io_special() with the reason BIO_RR_ACCEPT. If this happens
+then it is an indication that an accept attempt would block: the application
+should take appropriate action to wait until the underlying socket has
+accepted a connection and retry the call.
+
+BIO_set_accept_port(), BIO_get_accept_port(), BIO_set_nbio_accept(),
+BIO_set_accept_bios(), BIO_set_bind_mode(), BIO_get_bind_mode() and
+BIO_do_accept() are macros.
+
 =head1 RETURN VALUES
 
 TBA
diff --git a/src/lib/libssl/src/doc/crypto/BIO_s_connect.pod b/src/lib/libssl/src/doc/crypto/BIO_s_connect.pod
index fe1aa679d4..bcf7d8dcac 100644
--- a/src/lib/libssl/src/doc/crypto/BIO_s_connect.pod
+++ b/src/lib/libssl/src/doc/crypto/BIO_s_connect.pod
@@ -13,25 +13,27 @@ BIO_set_nbio, BIO_do_connect - connect BIO
 
  BIO_METHOD * BIO_s_connect(void);
 
- #define BIO_set_conn_hostname(b,name) BIO_ctrl(b,BIO_C_SET_CONNECT,0,(char *)name)
- #define BIO_set_conn_port(b,port) BIO_ctrl(b,BIO_C_SET_CONNECT,1,(char *)port)
- #define BIO_set_conn_ip(b,ip)    BIO_ctrl(b,BIO_C_SET_CONNECT,2,(char *)ip)
- #define BIO_set_conn_int_port(b,port) BIO_ctrl(b,BIO_C_SET_CONNECT,3,(char *)port)
- #define BIO_get_conn_hostname(b)  BIO_ptr_ctrl(b,BIO_C_GET_CONNECT,0)
- #define BIO_get_conn_port(b)      BIO_ptr_ctrl(b,BIO_C_GET_CONNECT,1)
- #define BIO_get_conn_ip(b,ip) BIO_ptr_ctrl(b,BIO_C_SET_CONNECT,2)
- #define BIO_get_conn_int_port(b,port) BIO_int_ctrl(b,BIO_C_SET_CONNECT,3,port)
+ BIO *BIO_new_connect(char *name);
 
- #define BIO_set_nbio(b,n)      BIO_ctrl(b,BIO_C_SET_NBIO,(n),NULL)
+ long BIO_set_conn_hostname(BIO *b, char *name);
+ long BIO_set_conn_port(BIO *b, char *port);
+ long BIO_set_conn_ip(BIO *b, char *ip);
+ long BIO_set_conn_int_port(BIO *b, char *port);
+ char *BIO_get_conn_hostname(BIO *b);
+ char *BIO_get_conn_port(BIO *b);
+ char *BIO_get_conn_ip(BIO *b, dummy);
+ long BIO_get_conn_int_port(BIO *b, int port);
 
- #define BIO_do_connect(b)      BIO_do_handshake(b)
+ long BIO_set_nbio(BIO *b, long n);
+
+ int BIO_do_connect(BIO *b);
 
 =head1 DESCRIPTION
 
 BIO_s_connect() returns the connect BIO method. This is a wrapper
 round the platform's TCP/IP socket connection routines.
 
-Using connect BIOs TCP/IP connections can be made and data
+Using connect BIOs, TCP/IP connections can be made and data
 transferred using only BIO routines. In this way any platform
 specific operations are hidden by the BIO abstraction.
 
@@ -54,7 +56,7 @@ BIO_get_fd() places the underlying socket in B<c> if it is not NULL,
 it also returns the socket . If B<c> is not NULL it should be of
 type (int *).
 
-BIO_set_conn_hostname() uses the string B<name> to set the hostname
+BIO_set_conn_hostname() uses the string B<name> to set the hostname.
 The hostname can be an IP address. The hostname can also include the
 port in the form hostname:port . It is also acceptable to use the
 form "hostname/any/other/path" or "hostname:port/any/other/path".
@@ -87,6 +89,9 @@ is set. Blocking I/O is the default. The call to BIO_set_nbio()
 should be made before the connection is established because 
 non blocking I/O is set during the connect process.
 
+BIO_new_connect() combines BIO_new() and BIO_set_conn_hostname() into
+a single call: that is it creates a new connect BIO with B<name>.
+
 BIO_do_connect() attempts to connect the supplied BIO. It returns 1
 if the connection was established successfully. A zero or negative
 value is returned if the connection could not be established, the
@@ -123,6 +128,11 @@ then this is an indication that a connection attempt would block,
 the application should then take appropriate action to wait until
 the underlying socket has connected and retry the call.
 
+BIO_set_conn_hostname(), BIO_set_conn_port(), BIO_set_conn_ip(),
+BIO_set_conn_int_port(), BIO_get_conn_hostname(), BIO_get_conn_port(),
+BIO_get_conn_ip(), BIO_get_conn_int_port(), BIO_set_nbio() and
+BIO_do_connect() are macros.
+
 =head1 RETURN VALUES
 
 BIO_s_connect() returns the connect BIO method.
diff --git a/src/lib/libssl/src/doc/crypto/BIO_s_socket.pod b/src/lib/libssl/src/doc/crypto/BIO_s_socket.pod
index 253185185c..1c8d3a9110 100644
--- a/src/lib/libssl/src/doc/crypto/BIO_s_socket.pod
+++ b/src/lib/libssl/src/doc/crypto/BIO_s_socket.pod
@@ -8,10 +8,10 @@ BIO_s_socket, BIO_new_socket - socket BIO
 
  #include <openssl/bio.h>
 
- BIO_METHOD *   BIO_s_socket(void);
+ BIO_METHOD *BIO_s_socket(void);
 
- #define BIO_set_fd(b,fd,c)     BIO_int_ctrl(b,BIO_C_SET_FD,c,fd)
- #define BIO_get_fd(b,c)        BIO_ctrl(b,BIO_C_GET_FD,0,(char *)c)
+ long BIO_set_fd(BIO *b, int fd, long close_flag);
+ long BIO_get_fd(BIO *b, int *c);
 
  BIO *BIO_new_socket(int sock, int close_flag);
 
@@ -27,10 +27,10 @@ If the close flag is set then the socket is shut down and closed
 when the BIO is freed.
 
 BIO_set_fd() sets the socket of BIO B<b> to B<fd> and the close
-flag to B<c>.
+flag to B<close_flag>.
 
 BIO_get_fd() places the socket in B<c> if it is not NULL, it also
-returns the socket . If B<c> is not NULL it should be of type (int *).
+returns the socket. If B<c> is not NULL it should be of type (int *).
 
 BIO_new_socket() returns a socket BIO using B<sock> and B<close_flag>.
 
@@ -44,6 +44,8 @@ platforms sockets are not file descriptors and use distinct I/O routines,
 Windows is one such platform. Any code mixing the two will not work on
 all platforms.
 
+BIO_set_fd() and BIO_get_fd() are macros.
+
 =head1 RETURN VALUES
 
 BIO_s_socket() returns the socket BIO method.
diff --git a/src/lib/libssl/src/doc/crypto/BN_add.pod b/src/lib/libssl/src/doc/crypto/BN_add.pod
index 7baed2d492..88c7a799ee 100644
--- a/src/lib/libssl/src/doc/crypto/BN_add.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_add.pod
@@ -2,8 +2,9 @@
 
 =head1 NAME
 
-BN_add, BN_sub, BN_mul, BN_div, BN_sqr, BN_mod, BN_mod_mul, BN_exp,
-BN_mod_exp, BN_gcd - arithmetic operations on BIGNUMs
+BN_add, BN_sub, BN_mul, BN_sqr, BN_div, BN_mod, BN_nnmod, BN_mod_add,
+BN_mod_sub, BN_mod_mul, BN_mod_sqr, BN_exp, BN_mod_exp, BN_gcd -
+arithmetic operations on BIGNUMs
 
 =head1 SYNOPSIS
 
@@ -15,16 +16,26 @@ BN_mod_exp, BN_gcd - arithmetic operations on BIGNUMs
 
  int BN_mul(BIGNUM *r, BIGNUM *a, BIGNUM *b, BN_CTX *ctx);
 
+ int BN_sqr(BIGNUM *r, BIGNUM *a, BN_CTX *ctx);
+
  int BN_div(BIGNUM *dv, BIGNUM *rem, const BIGNUM *a, const BIGNUM *d,
          BN_CTX *ctx);
 
- int BN_sqr(BIGNUM *r, BIGNUM *a, BN_CTX *ctx);
-
  int BN_mod(BIGNUM *rem, const BIGNUM *a, const BIGNUM *m, BN_CTX *ctx);
 
- int BN_mod_mul(BIGNUM *ret, BIGNUM *a, BIGNUM *b, const BIGNUM *m,
+ int BN_nnmod(BIGNUM *r, const BIGNUM *a, const BIGNUM *m, BN_CTX *ctx);
+
+ int BN_mod_add(BIGNUM *r, BIGNUM *a, BIGNUM *b, const BIGNUM *m,
+         BN_CTX *ctx);
+
+ int BN_mod_sub(BIGNUM *r, BIGNUM *a, BIGNUM *b, const BIGNUM *m,
+         BN_CTX *ctx);
+
+ int BN_mod_mul(BIGNUM *r, BIGNUM *a, BIGNUM *b, const BIGNUM *m,
          BN_CTX *ctx);
 
+ int BN_mod_sqr(BIGNUM *r, BIGNUM *a, const BIGNUM *m, BN_CTX *ctx);
+
  int BN_exp(BIGNUM *r, BIGNUM *a, BIGNUM *p, BN_CTX *ctx);
 
  int BN_mod_exp(BIGNUM *r, BIGNUM *a, const BIGNUM *p,
@@ -34,45 +45,59 @@ BN_mod_exp, BN_gcd - arithmetic operations on BIGNUMs
 
 =head1 DESCRIPTION
 
-BN_add() adds B<a> and B<b> and places the result in B<r> (C<r=a+b>).
-B<r> may be the same B<BIGNUM> as B<a> or B<b>.
+BN_add() adds I<a> and I<b> and places the result in I<r> (C<r=a+b>).
+I<r> may be the same B<BIGNUM> as I<a> or I<b>.
 
-BN_sub() subtracts B<b> from B<a> and places the result in B<r> (C<r=a-b>).
+BN_sub() subtracts I<b> from I<a> and places the result in I<r> (C<r=a-b>).
 
-BN_mul() multiplies B<a> and B<b> and places the result in B<r> (C<r=a*b>).
-B<r> may be the same B<BIGNUM> as B<a> or B<b>.
+BN_mul() multiplies I<a> and I<b> and places the result in I<r> (C<r=a*b>).
+I<r> may be the same B<BIGNUM> as I<a> or I<b>.
 For multiplication by powers of 2, use L<BN_lshift(3)|BN_lshift(3)>.
 
-BN_div() divides B<a> by B<d> and places the result in B<dv> and the
-remainder in B<rem> (C<dv=a/d, rem=a%d>). Either of B<dv> and B<rem> may
-be NULL, in which case the respective value is not returned.
+BN_sqr() takes the square of I<a> and places the result in I<r>
+(C<r=a^2>). I<r> and I<a> may be the same B<BIGNUM>.
+This function is faster than BN_mul(r,a,a).
+
+BN_div() divides I<a> by I<d> and places the result in I<dv> and the
+remainder in I<rem> (C<dv=a/d, rem=a%d>). Either of I<dv> and I<rem> may
+be B<NULL>, in which case the respective value is not returned.
+The result is rounded towards zero; thus if I<a> is negative, the
+remainder will be zero or negative.
 For division by powers of 2, use BN_rshift(3).
 
-BN_sqr() takes the square of B<a> and places the result in B<r>
-(C<r=a^2>). B<r> and B<a> may be the same B<BIGNUM>.
-This function is faster than BN_mul(r,a,a).
+BN_mod() corresponds to BN_div() with I<dv> set to B<NULL>.
+
+BN_nnmod() reduces I<a> modulo I<m> and places the non-negative
+remainder in I<r>.
+
+BN_mod_add() adds I<a> to I<b> modulo I<m> and places the non-negative
+result in I<r>.
+
+BN_mod_sub() subtracts I<b> from I<a> modulo I<m> and places the
+non-negative result in I<r>.
 
-BN_mod() find the remainder of B<a> divided by B<m> and places it in
-B<rem> (C<rem=a%m>).
+BN_mod_mul() multiplies I<a> by I<b> and finds the non-negative
+remainder respective to modulus I<m> (C<r=(a*b) mod m>). I<r> may be
+the same B<BIGNUM> as I<a> or I<b>. For more efficient algorithms for
+repeated computations using the same modulus, see
+L<BN_mod_mul_montgomery(3)|BN_mod_mul_montgomery(3)> and
+L<BN_mod_mul_reciprocal(3)|BN_mod_mul_reciprocal(3)>.
 
-BN_mod_mul() multiplies B<a> by B<b> and finds the remainder when
-divided by B<m> (C<r=(a*b)%m>). B<r> may be the same B<BIGNUM> as B<a>
-or B<b>. For a more efficient algorithm, see
-L<BN_mod_mul_montgomery(3)|BN_mod_mul_montgomery(3)>; for repeated
-computations using the same modulus, see L<BN_mod_mul_reciprocal(3)|BN_mod_mul_reciprocal(3)>.
+BN_mod_sqr() takes the square of I<a> modulo B<m> and places the
+result in I<r>.
 
-BN_exp() raises B<a> to the B<p>-th power and places the result in B<r>
+BN_exp() raises I<a> to the I<p>-th power and places the result in I<r>
 (C<r=a^p>). This function is faster than repeated applications of
 BN_mul().
 
-BN_mod_exp() computes B<a> to the B<p>-th power modulo B<m> (C<r=a^p %
+BN_mod_exp() computes I<a> to the I<p>-th power modulo I<m> (C<r=a^p %
 m>). This function uses less time and space than BN_exp().
 
-BN_gcd() computes the greatest common divisor of B<a> and B<b> and
-places the result in B<r>. B<r> may be the same B<BIGNUM> as B<a> or
-B<b>.
+BN_gcd() computes the greatest common divisor of I<a> and I<b> and
+places the result in I<r>. I<r> may be the same B<BIGNUM> as I<a> or
+I<b>.
 
-For all functions, B<ctx> is a previously allocated B<BN_CTX> used for
+For all functions, I<ctx> is a previously allocated B<BN_CTX> used for
 temporary variables; see L<BN_CTX_new(3)|BN_CTX_new(3)>.
 
 Unless noted otherwise, the result B<BIGNUM> must be different from
@@ -91,9 +116,11 @@ L<BN_add_word(3)|BN_add_word(3)>, L<BN_set_bit(3)|BN_set_bit(3)>
 
 =head1 HISTORY
 
-BN_add(), BN_sub(), BN_div(), BN_sqr(), BN_mod(), BN_mod_mul(),
+BN_add(), BN_sub(), BN_sqr(), BN_div(), BN_mod(), BN_mod_mul(),
 BN_mod_exp() and BN_gcd() are available in all versions of SSLeay and
-OpenSSL. The B<ctx> argument to BN_mul() was added in SSLeay
+OpenSSL. The I<ctx> argument to BN_mul() was added in SSLeay
 0.9.1b. BN_exp() appeared in SSLeay 0.9.0.
+BN_nnmod(), BN_mod_add(), BN_mod_sub(), and BN_mod_sqr() were added in
+OpenSSL 0.9.7.
 
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/BN_bn2bin.pod b/src/lib/libssl/src/doc/crypto/BN_bn2bin.pod
index 4f78574ed0..a4b17ca60a 100644
--- a/src/lib/libssl/src/doc/crypto/BN_bn2bin.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_bn2bin.pod
@@ -49,7 +49,7 @@ with a leading '-' for negative numbers, to the B<BIO> or B<FILE>
 B<fp>.
 
 BN_bn2mpi() and BN_mpi2bn() convert B<BIGNUM>s from and to a format
-that consists of the number's length in bytes represented as a 3-byte
+that consists of the number's length in bytes represented as a 4-byte
 big-endian number, and the number itself in big-endian format, where
 the most significant bit signals a negative number (the representation
 of numbers with the MSB set is prefixed with null byte).
diff --git a/src/lib/libssl/src/doc/crypto/BN_mod_mul_montgomery.pod b/src/lib/libssl/src/doc/crypto/BN_mod_mul_montgomery.pod
index f3cee924b9..6b16351b92 100644
--- a/src/lib/libssl/src/doc/crypto/BN_mod_mul_montgomery.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_mod_mul_montgomery.pod
@@ -36,22 +36,23 @@ using the same modulus.
 BN_MONT_CTX_new() allocates and initializes a B<BN_MONT_CTX> structure.
 BN_MONT_CTX_init() initializes an existing uninitialized B<BN_MONT_CTX>.
 
-BN_MONT_CTX_set() sets up the B<mont> structure from the modulus B<m>
+BN_MONT_CTX_set() sets up the I<mont> structure from the modulus I<m>
 by precomputing its inverse and a value R.
 
-BN_MONT_CTX_copy() copies the B<BN_MONT_CTX> B<from> to B<to>.
+BN_MONT_CTX_copy() copies the B<BN_MONT_CTX> I<from> to I<to>.
 
 BN_MONT_CTX_free() frees the components of the B<BN_MONT_CTX>, and, if
 it was created by BN_MONT_CTX_new(), also the structure itself.
 
-BN_mod_mul_montgomery() computes Mont(B<a>,B<b>):=B<a>*B<b>*R^-1 and places
-the result in B<r>.
+BN_mod_mul_montgomery() computes Mont(I<a>,I<b>):=I<a>*I<b>*R^-1 and places
+the result in I<r>.
 
-BN_from_montgomery() performs the Montgomery reduction B<r> = B<a>*R^-1.
+BN_from_montgomery() performs the Montgomery reduction I<r> = I<a>*R^-1.
 
-BN_to_montgomery() computes Mont(B<a>,R^2), i.e. B<a>*R.
+BN_to_montgomery() computes Mont(I<a>,R^2), i.e. I<a>*R.
+Note that I<a> must be non-negative and smaller than the modulus.
 
-For all functions, B<ctx> is a previously allocated B<BN_CTX> used for
+For all functions, I<ctx> is a previously allocated B<BN_CTX> used for
 temporary variables.
 
 The B<BN_MONT_CTX> structure is defined as follows:
@@ -79,6 +80,11 @@ BN_MONT_CTX_init() and BN_MONT_CTX_free() have no return values.
 For the other functions, 1 is returned for success, 0 on error.
 The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
+=head1 WARNING
+
+The inputs must be reduced modulo B<m>, otherwise the result will be
+outside the expected range.
+
 =head1 SEE ALSO
 
 L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<BN_add(3)|BN_add(3)>,
diff --git a/src/lib/libssl/src/doc/crypto/BN_rand.pod b/src/lib/libssl/src/doc/crypto/BN_rand.pod
index 5406552ba4..18301a396a 100644
--- a/src/lib/libssl/src/doc/crypto/BN_rand.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_rand.pod
@@ -14,6 +14,8 @@ BN_rand, BN_pseudo_rand - generate pseudo-random number
 
  int BN_rand_range(BIGNUM *rnd, BIGNUM *range);
 
+ int BN_pseudo_rand_range(BIGNUM *rnd, int bits, int top, int bottom);
+
 =head1 DESCRIPTION
 
 BN_rand() generates a cryptographically strong pseudo-random number of
@@ -31,6 +33,8 @@ protocols, but usually not for key generation etc.
 
 BN_rand_range() generates a cryptographically strong pseudo-random
 number B<rnd> in the range 0 <lt>= B<rnd> E<lt> B<range>.
+BN_pseudo_rand_range() does the same, but is based on BN_pseudo_rand(),
+and hence numbers generated by it are not necessarily unpredictable.
 
 The PRNG must be seeded prior to calling BN_rand() or BN_rand_range().
 
@@ -49,5 +53,6 @@ L<RAND_add(3)|RAND_add(3)>, L<RAND_bytes(3)|RAND_bytes(3)>
 BN_rand() is available in all versions of SSLeay and OpenSSL.
 BN_pseudo_rand() was added in OpenSSL 0.9.5. The B<top> == -1 case
 and the function BN_rand_range() were added in OpenSSL 0.9.6a.
+BN_pseudo_rand_range() was added in OpenSSL 0.9.6c.
 
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/BN_swap.pod b/src/lib/libssl/src/doc/crypto/BN_swap.pod
new file mode 100644
index 0000000000..79efaa1446
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/BN_swap.pod
@@ -0,0 +1,23 @@
+=pod
+
+=head1 NAME
+
+BN_swap - exchange BIGNUMs
+
+=head1 SYNOPSIS
+
+ #include <openssl/bn.h>
+
+ void BN_swap(BIGNUM *a, BIGNUM *b);
+
+=head1 DESCRIPTION
+
+BN_swap() exchanges the values of I<a> and I<b>.
+
+L<bn(3)|bn(3)>
+
+=head1 HISTORY
+
+BN_swap was added in OpenSSL 0.9.7.
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/BN_zero.pod b/src/lib/libssl/src/doc/crypto/BN_zero.pod
index 2f33876498..3c64a65697 100644
--- a/src/lib/libssl/src/doc/crypto/BN_zero.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_zero.pod
@@ -12,7 +12,7 @@ operations
  int BN_zero(BIGNUM *a);
  int BN_one(BIGNUM *a);
 
- BIGNUM *BN_value_one(void);
+ const BIGNUM *BN_value_one(void);
 
  int BN_set_word(BIGNUM *a, unsigned long w);
  unsigned long BN_get_word(BIGNUM *a);
diff --git a/src/lib/libssl/src/doc/crypto/DH_set_method.pod b/src/lib/libssl/src/doc/crypto/DH_set_method.pod
index 62088eea1b..d990bf8786 100644
--- a/src/lib/libssl/src/doc/crypto/DH_set_method.pod
+++ b/src/lib/libssl/src/doc/crypto/DH_set_method.pod
@@ -82,8 +82,8 @@ the default engine for Diffie-Hellman opertaions is used.
 
 =head1 RETURN VALUES
 
-DH_OpenSSL() and DH_get_default_method() return pointers to the respective
-DH_METHODs.
+DH_OpenSSL() and DH_get_default_openssl_method() return pointers to the
+respective B<DH_METHOD>s.
 
 DH_set_default_openssl_method() returns no value.
 
diff --git a/src/lib/libssl/src/doc/crypto/DSA_set_method.pod b/src/lib/libssl/src/doc/crypto/DSA_set_method.pod
index c56dfd0f47..36a1052d27 100644
--- a/src/lib/libssl/src/doc/crypto/DSA_set_method.pod
+++ b/src/lib/libssl/src/doc/crypto/DSA_set_method.pod
@@ -90,7 +90,7 @@ struct
 =head1 RETURN VALUES
 
 DSA_OpenSSL() and DSA_get_default_openssl_method() return pointers to the
-respective DSA_METHODs.
+respective B<DSA_METHOD>s.
 
 DSA_set_default_openssl_method() returns no value.
 
diff --git a/src/lib/libssl/src/doc/crypto/ERR_get_error.pod b/src/lib/libssl/src/doc/crypto/ERR_get_error.pod
index 3551bacb8d..9fdedbcb91 100644
--- a/src/lib/libssl/src/doc/crypto/ERR_get_error.pod
+++ b/src/lib/libssl/src/doc/crypto/ERR_get_error.pod
@@ -2,8 +2,10 @@
 
 =head1 NAME
 
-ERR_get_error, ERR_peek_error, ERR_get_error_line, ERR_peek_error_line,
-ERR_get_error_line_data, ERR_peek_error_line_data - obtain error code and data
+ERR_get_error, ERR_peek_error, ERR_peek_last_error,
+ERR_get_error_line, ERR_peek_error_line, ERR_peek_last_error_line,
+ERR_get_error_line_data, ERR_peek_error_line_data,
+ERR_peek_error_line_data - obtain error code and data
 
 =head1 SYNOPSIS
 
@@ -11,22 +13,29 @@ ERR_get_error_line_data, ERR_peek_error_line_data - obtain error code and data
 
  unsigned long ERR_get_error(void);
  unsigned long ERR_peek_error(void);
+ unsigned long ERR_peek_last_error(void);
 
  unsigned long ERR_get_error_line(const char **file, int *line);
  unsigned long ERR_peek_error_line(const char **file, int *line);
+ unsigned long ERR_peek_last_error_line(const char **file, int *line);
 
  unsigned long ERR_get_error_line_data(const char **file, int *line,
          const char **data, int *flags);
  unsigned long ERR_peek_error_line_data(const char **file, int *line,
          const char **data, int *flags);
+ unsigned long ERR_peek_last_error_line_data(const char **file, int *line,
+         const char **data, int *flags);
 
 =head1 DESCRIPTION
 
-ERR_get_error() returns the last error code from the thread's error
+ERR_get_error() returns the earliest error code from the thread's error
 queue and removes the entry. This function can be called repeatedly
 until there are no more error codes to return.
 
-ERR_peek_error() returns the last error code from the thread's
+ERR_peek_error() returns the earliest error code from the thread's
+error queue without modifying it.
+
+ERR_peek_last_error() returns the latest error code from the thread's
 error queue without modifying it.
 
 See L<ERR_GET_LIB(3)|ERR_GET_LIB(3)> for obtaining information about
@@ -34,12 +43,14 @@ location and reason of the error, and
 L<ERR_error_string(3)|ERR_error_string(3)> for human-readable error
 messages.
 
-ERR_get_error_line() and ERR_peek_error_line() are the same as the
-above, but they additionally store the file name and line number where
+ERR_get_error_line(), ERR_peek_error_line() and
+ERR_peek_last_error_line() are the same as the above, but they
+additionally store the file name and line number where
 the error occurred in *B<file> and *B<line>, unless these are B<NULL>.
 
-ERR_get_error_line_data() and ERR_peek_error_line_data() store
-additional data and flags associated with the error code in *B<data>
+ERR_get_error_line_data(), ERR_peek_error_line_data() and
+ERR_get_last_error_line_data() store additional data and flags
+associated with the error code in *B<data>
 and *B<flags>, unless these are B<NULL>. *B<data> contains a string
 if *B<flags>&B<ERR_TXT_STRING>. If it has been allocated by OPENSSL_malloc(),
 *B<flags>&B<ERR_TXT_MALLOCED> is true.
@@ -59,5 +70,7 @@ ERR_get_error(), ERR_peek_error(), ERR_get_error_line() and
 ERR_peek_error_line() are available in all versions of SSLeay and
 OpenSSL. ERR_get_error_line_data() and ERR_peek_error_line_data()
 were added in SSLeay 0.9.0.
+ERR_peek_last_error(), ERR_peek_last_error_line() and
+ERR_peek_last_error_line_data() were added in OpenSSL 0.9.7.
 
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/EVP_BytesToKey.pod b/src/lib/libssl/src/doc/crypto/EVP_BytesToKey.pod
new file mode 100644
index 0000000000..5ce4add082
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/EVP_BytesToKey.pod
@@ -0,0 +1,67 @@
+=pod
+
+=head1 NAME
+
+ EVP_BytesToKey - password based encryption routine
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ int EVP_BytesToKey(const EVP_CIPHER *type,const EVP_MD *md,
+                       const unsigned char *salt,
+                       const unsigned char *data, int datal, int count,
+                       unsigned char *key,unsigned char *iv);
+
+=head1 DESCRIPTION
+
+EVP_BytesToKey() derives a key and IV from various parameters. B<type> is
+the cipher to derive the key and IV for. B<md> is the message digest to use.
+The B<salt> paramter is used as a salt in the derivation: it should point to
+an 8 byte buffer or NULL if no salt is used. B<data> is a buffer containing
+B<datal> bytes which is used to derive the keying data. B<count> is the
+iteration count to use. The derived key and IV will be written to B<key>
+and B<iv> respectively.
+
+=head1 NOTES
+
+A typical application of this function is to derive keying material for an
+encryption algorithm from a password in the B<data> parameter.
+
+Increasing the B<count> parameter slows down the algorithm which makes it
+harder for an attacker to peform a brute force attack using a large number
+of candidate passwords.
+
+If the total key and IV length is less than the digest length and
+B<MD5> is used then the derivation algorithm is compatible with PKCS#5 v1.5
+otherwise a non standard extension is used to derive the extra data.
+
+Newer applications should use more standard algorithms such as PKCS#5
+v2.0 for key derivation.
+
+=head1 KEY DERIVATION ALGORITHM
+
+The key and IV is derived by concatenating D_1, D_2, etc until
+enough data is available for the key and IV. D_i is defined as:
+
+        D_i = HASH^count(D_(i-1) || data || salt)
+
+where || denotes concatentaion, D_0 is empty, HASH is the digest
+algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data)
+is HASH(HASH(data)) and so on.
+
+The initial bytes are used for the key and the subsequent bytes for
+the IV.
+
+=head1 RETURN VALUES
+
+EVP_BytesToKey() returns the size of the derived key in bytes.
+
+=head1 SEE ALSO
+
+L<evp(3)|evp(3)>, L<rand(3)|rand(3)>,
+L<EVP_EncryptInit(3)|EVP_EncryptInit(3)>,
+
+=head1 HISTORY
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/EVP_DigestInit.pod b/src/lib/libssl/src/doc/crypto/EVP_DigestInit.pod
index fefc858f7e..acd4d0167a 100644
--- a/src/lib/libssl/src/doc/crypto/EVP_DigestInit.pod
+++ b/src/lib/libssl/src/doc/crypto/EVP_DigestInit.pod
@@ -2,9 +2,10 @@
 
 =head1 NAME
 
-EVP_DigestInit, EVP_DigestUpdate, EVP_DigestFinal, EVP_MAX_MD_SIZE,
-EVP_MD_CTX_copy, EVP_MD_type, EVP_MD_pkey_type, EVP_MD_size, EVP_MD_block_size,
-EVP_MD_CTX_md, EVP_MD_CTX_size, EVP_MD_CTX_block_size, EVP_MD_CTX_type,
+EVP_MD_CTX_init, EVP_MD_CTX_create, EVP_DigestInit_ex, EVP_DigestUpdate,
+EVP_DigestFinal_ex, EVP_MD_CTX_cleanup, EVP_MD_CTX_destroy, EVP_MAX_MD_SIZE,
+EVP_MD_CTX_copy_ex EVP_MD_CTX_copy, EVP_MD_type, EVP_MD_pkey_type, EVP_MD_size,
+EVP_MD_block_size, EVP_MD_CTX_md, EVP_MD_CTX_size, EVP_MD_CTX_block_size, EVP_MD_CTX_type,
 EVP_md_null, EVP_md2, EVP_md5, EVP_sha, EVP_sha1, EVP_dss, EVP_dss1, EVP_mdc2,
 EVP_ripemd160, EVP_get_digestbyname, EVP_get_digestbynid, EVP_get_digestbyobj -
 EVP digest routines
@@ -13,15 +14,28 @@ EVP digest routines
 
  #include <openssl/evp.h>
 
- void EVP_DigestInit(EVP_MD_CTX *ctx, const EVP_MD *type);
- void EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
- void EVP_DigestFinal(EVP_MD_CTX *ctx, unsigned char *md,
+ void EVP_MD_CTX_init(EVP_MD_CTX *ctx);
+ EVP_MD_CTX *EVP_MD_CTX_create(void);
+
+ int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl);
+ int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
+ int EVP_DigestFinal_ex(EVP_MD_CTX *ctx, unsigned char *md,
         unsigned int *s);
 
- #define EVP_MAX_MD_SIZE (16+20) /* The SSLv3 md5+sha1 type */
+ int EVP_MD_CTX_cleanup(EVP_MD_CTX *ctx);
+ void EVP_MD_CTX_destroy(EVP_MD_CTX *ctx);
+
+ int EVP_MD_CTX_copy_ex(EVP_MD_CTX *out,const EVP_MD_CTX *in);  
+
+ int EVP_DigestInit(EVP_MD_CTX *ctx, const EVP_MD *type);
+ int EVP_DigestFinal(EVP_MD_CTX *ctx, unsigned char *md,
+        unsigned int *s);
 
  int EVP_MD_CTX_copy(EVP_MD_CTX *out,EVP_MD_CTX *in);  
 
+ #define EVP_MAX_MD_SIZE (16+20) /* The SSLv3 md5+sha1 type */
+
+
  #define EVP_MD_type(e)                 ((e)->type)
  #define EVP_MD_pkey_type(e)            ((e)->pkey_type)
  #define EVP_MD_size(e)                 ((e)->md_size)
@@ -32,15 +46,15 @@ EVP digest routines
  #define EVP_MD_CTX_block_size(e)       EVP_MD_block_size((e)->digest)
  #define EVP_MD_CTX_type(e)             EVP_MD_type((e)->digest)
 
- EVP_MD *EVP_md_null(void);
- EVP_MD *EVP_md2(void);
- EVP_MD *EVP_md5(void);
- EVP_MD *EVP_sha(void);
- EVP_MD *EVP_sha1(void);
- EVP_MD *EVP_dss(void);
- EVP_MD *EVP_dss1(void);
- EVP_MD *EVP_mdc2(void);
- EVP_MD *EVP_ripemd160(void);
+ const EVP_MD *EVP_md_null(void);
+ const EVP_MD *EVP_md2(void);
+ const EVP_MD *EVP_md5(void);
+ const EVP_MD *EVP_sha(void);
+ const EVP_MD *EVP_sha1(void);
+ const EVP_MD *EVP_dss(void);
+ const EVP_MD *EVP_dss1(void);
+ const EVP_MD *EVP_mdc2(void);
+ const EVP_MD *EVP_ripemd160(void);
 
  const EVP_MD *EVP_get_digestbyname(const char *name);
  #define EVP_get_digestbynid(a) EVP_get_digestbyname(OBJ_nid2sn(a))
@@ -50,25 +64,48 @@ EVP digest routines
 
 The EVP digest routines are a high level interface to message digests.
 
-EVP_DigestInit() initializes a digest context B<ctx> to use a digest
-B<type>: this will typically be supplied by a function such as
-EVP_sha1().
+EVP_MD_CTX_init() initializes digest contet B<ctx>.
+
+EVP_MD_CTX_create() allocates, initializes and returns a digest contet.
+
+EVP_DigestInit_ex() sets up digest context B<ctx> to use a digest
+B<type> from ENGINE B<impl>. B<ctx> must be initialized before calling this
+function. B<type> will typically be supplied by a functionsuch as EVP_sha1().
+If B<impl> is NULL then the default implementation of digest B<type> is used.
 
 EVP_DigestUpdate() hashes B<cnt> bytes of data at B<d> into the
 digest context B<ctx>. This function can be called several times on the
 same B<ctx> to hash additional data.
 
-EVP_DigestFinal() retrieves the digest value from B<ctx> and places
+EVP_DigestFinal_ex() retrieves the digest value from B<ctx> and places
 it in B<md>. If the B<s> parameter is not NULL then the number of
 bytes of data written (i.e. the length of the digest) will be written
 to the integer at B<s>, at most B<EVP_MAX_MD_SIZE> bytes will be written.
-After calling EVP_DigestFinal() no additional calls to EVP_DigestUpdate()
-can be made, but EVP_DigestInit() can be called to initialize a new
+After calling EVP_DigestFinal_ex() no additional calls to EVP_DigestUpdate()
+can be made, but EVP_DigestInit_ex() can be called to initialize a new
 digest operation.
 
-EVP_MD_CTX_copy() can be used to copy the message digest state from
+EVP_MD_CTX_cleanup() cleans up digest context B<ctx>, it should be called
+after a digest context is no longer needed.
+
+EVP_MD_CTX_destroy() cleans up digest context B<ctx> and frees up the
+space allocated to it, it should be called only on a context created
+using EVP_MD_CTX_create().
+
+EVP_MD_CTX_copy_ex() can be used to copy the message digest state from
 B<in> to B<out>. This is useful if large amounts of data are to be
-hashed which only differ in the last few bytes.
+hashed which only differ in the last few bytes. B<out> must be initialized
+before calling this function.
+
+EVP_DigestInit() behaves in the same way as EVP_DigestInit_ex() except
+the passed context B<ctx> does not have to be initialized, and it always
+uses the default digest implementation.
+
+EVP_DigestFinal() is similar to EVP_DigestFinal_ex() except the digest
+contet B<ctx> is automatically cleaned up.
+
+EVP_MD_CTX_copy() is similar to EVP_MD_CTX_copy_ex() except the destination
+B<out> does not have to be initialized.
 
 EVP_MD_size() and EVP_MD_CTX_size() return the size of the message digest
 when passed an B<EVP_MD> or an B<EVP_MD_CTX> structure, i.e. the size of the
@@ -107,9 +144,10 @@ using, for example, OpenSSL_add_all_digests() for these functions to work.
 
 =head1 RETURN VALUES
 
-EVP_DigestInit(), EVP_DigestUpdate() and EVP_DigestFinal() do not return values.
+EVP_DigestInit_ex(), EVP_DigestUpdate() and EVP_DigestFinal_ex() return 1 for
+success and 0 for failure.
 
-EVP_MD_CTX_copy() returns 1 if successful or 0 for failure.
+EVP_MD_CTX_copy_ex() returns 1 if successful or 0 for failure.
 
 EVP_MD_type(), EVP_MD_pkey_type() and EVP_MD_type() return the NID of the
 corresponding OBJECT IDENTIFIER or NID_undef if none exists.
@@ -134,6 +172,19 @@ transparent to the digest used and much more flexible.
 SHA1 is the digest of choice for new applications. The other digest algorithms
 are still in common use.
 
+For most applications the B<impl> parameter to EVP_DigestInit_ex() will be
+set to NULL to use the default digest implementation.
+
+The functions EVP_DigestInit(), EVP_DigestFinal() and EVP_MD_CTX_copy() are 
+obsolete but are retained to maintain compatibility with existing code. New
+applications should use EVP_DigestInit_ex(), EVP_DigestFinal_ex() and 
+EVP_MD_CTX_copy_ex() because they can efficiently reuse a digest context
+instead of initializing and cleaning it up on each call and allow non default
+implementations of digests to be specified.
+
+In OpenSSL 0.9.7 and later if digest contexts are not cleaned up after use
+memory leaks will occur. 
+
 =head1 EXAMPLE
 
 This example digests the data "Test Message\n" and "Hello World\n", using the
@@ -165,10 +216,12 @@ digest name passed on the command line.
         exit(1);
  }
 
- EVP_DigestInit(&mdctx, md);
+ EVP_MD_CTX_init(&mdctx);
+ EVP_DigestInit_ex(&mdctx, md, NULL);
  EVP_DigestUpdate(&mdctx, mess1, strlen(mess1));
  EVP_DigestUpdate(&mdctx, mess2, strlen(mess2));
- EVP_DigestFinal(&mdctx, md_value, &md_len);
+ EVP_DigestFinal_ex(&mdctx, md_value, &md_len);
+ EVP_MD_CTX_cleanup(&mdctx);
 
  printf("Digest is: ");
  for(i = 0; i < md_len; i++) printf("%02x", md_value[i]);
@@ -177,17 +230,10 @@ digest name passed on the command line.
 
 =head1 BUGS
 
-Several of the functions do not return values: maybe they should. Although the
-internal digest operations will never fail some future hardware based operations
-might.
-
 The link between digests and signing algorithms results in a situation where
 EVP_sha1() must be used with RSA and EVP_dss1() must be used with DSS
 even though they are identical digests.
 
-The size of an B<EVP_MD_CTX> structure is determined at compile time: this results
-in code that must be recompiled if the size of B<EVP_MD_CTX> increases.
-
 =head1 SEE ALSO
 
 L<evp(3)|evp(3)>, L<HMAC(3)|HMAC(3)>, L<MD2(3)|MD2(3)>,
@@ -199,4 +245,7 @@ L<SHA1(3)|SHA1(3)>
 EVP_DigestInit(), EVP_DigestUpdate() and EVP_DigestFinal() are
 available in all versions of SSLeay and OpenSSL.
 
+EVP_DigestInit_ex(), EVP_DigestFinal_ex() and EVP_MD_CTX_copy_ex()
+were added in OpenSSL 0.9.7.
+
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod b/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
index 9afe2396e2..371b6a2287 100644
--- a/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
+++ b/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
@@ -2,43 +2,65 @@
 
 =head1 NAME
 
-EVP_EncryptInit, EVP_EncryptUpdate, EVP_EncryptFinal, EVP_DecryptInit,
-EVP_DecryptUpdate, EVP_DecryptFinal, EVP_CipherInit, EVP_CipherUpdate,
-EVP_CipherFinal, EVP_CIPHER_CTX_set_key_length, EVP_CIPHER_CTX_ctrl,
-EVP_CIPHER_CTX_cleanup, EVP_get_cipherbyname, EVP_get_cipherbynid,
-EVP_get_cipherbyobj, EVP_CIPHER_nid, EVP_CIPHER_block_size,
-EVP_CIPHER_key_length, EVP_CIPHER_iv_length, EVP_CIPHER_flags,
-EVP_CIPHER_mode, EVP_CIPHER_type, EVP_CIPHER_CTX_cipher, EVP_CIPHER_CTX_nid,
-EVP_CIPHER_CTX_block_size, EVP_CIPHER_CTX_key_length, EVP_CIPHER_CTX_iv_length,
-EVP_CIPHER_CTX_get_app_data, EVP_CIPHER_CTX_set_app_data, EVP_CIPHER_CTX_type,
-EVP_CIPHER_CTX_flags, EVP_CIPHER_CTX_mode, EVP_CIPHER_param_to_asn1,
-EVP_CIPHER_asn1_to_param - EVP cipher routines
+EVP_CIPHER_CTX_init, EVP_EncryptInit_ex, EVP_EncryptUpdate,
+EVP_EncryptFinal_ex, EVP_DecryptInit_ex, EVP_DecryptUpdate,
+EVP_DecryptFinal_ex, EVP_CipherInit_ex, EVP_CipherUpdate,
+EVP_CipherFinal_ex, EVP_CIPHER_CTX_set_key_length,
+EVP_CIPHER_CTX_ctrl, EVP_CIPHER_CTX_cleanup, EVP_EncryptInit,
+EVP_EncryptFinal, EVP_DecryptInit, EVP_DecryptFinal,
+EVP_CipherInit, EVP_CipherFinal, EVP_get_cipherbyname,
+EVP_get_cipherbynid, EVP_get_cipherbyobj, EVP_CIPHER_nid,
+EVP_CIPHER_block_size, EVP_CIPHER_key_length, EVP_CIPHER_iv_length,
+EVP_CIPHER_flags, EVP_CIPHER_mode, EVP_CIPHER_type, EVP_CIPHER_CTX_cipher,
+EVP_CIPHER_CTX_nid, EVP_CIPHER_CTX_block_size, EVP_CIPHER_CTX_key_length,
+EVP_CIPHER_CTX_iv_length, EVP_CIPHER_CTX_get_app_data,
+EVP_CIPHER_CTX_set_app_data, EVP_CIPHER_CTX_type, EVP_CIPHER_CTX_flags,
+EVP_CIPHER_CTX_mode, EVP_CIPHER_param_to_asn1, EVP_CIPHER_asn1_to_param,
+EVP_CIPHER_CTX_set_padding - EVP cipher routines
 
 =head1 SYNOPSIS
 
  #include <openssl/evp.h>
 
- int EVP_EncryptInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
-         unsigned char *key, unsigned char *iv);
+ int EVP_CIPHER_CTX_init(EVP_CIPHER_CTX *a);
+
+ int EVP_EncryptInit_ex(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
+         ENGINE *impl, unsigned char *key, unsigned char *iv);
  int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
          int *outl, unsigned char *in, int inl);
+ int EVP_EncryptFinal_ex(EVP_CIPHER_CTX *ctx, unsigned char *out,
+         int *outl);
+
+ int EVP_DecryptInit_ex(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
+         ENGINE *impl, unsigned char *key, unsigned char *iv);
+ int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
+         int *outl, unsigned char *in, int inl);
+ int EVP_DecryptFinal_ex(EVP_CIPHER_CTX *ctx, unsigned char *outm,
+         int *outl);
+
+ int EVP_CipherInit_ex(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
+         ENGINE *impl, unsigned char *key, unsigned char *iv, int enc);
+ int EVP_CipherUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
+         int *outl, unsigned char *in, int inl);
+ int EVP_CipherFinal_ex(EVP_CIPHER_CTX *ctx, unsigned char *outm,
+         int *outl);
+
+ int EVP_EncryptInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
+         unsigned char *key, unsigned char *iv);
  int EVP_EncryptFinal(EVP_CIPHER_CTX *ctx, unsigned char *out,
          int *outl);
 
  int EVP_DecryptInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
          unsigned char *key, unsigned char *iv);
- int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
-         int *outl, unsigned char *in, int inl);
  int EVP_DecryptFinal(EVP_CIPHER_CTX *ctx, unsigned char *outm,
          int *outl);
 
  int EVP_CipherInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
          unsigned char *key, unsigned char *iv, int enc);
- int EVP_CipherUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
-         int *outl, unsigned char *in, int inl);
  int EVP_CipherFinal(EVP_CIPHER_CTX *ctx, unsigned char *outm,
          int *outl);
 
+ int EVP_CIPHER_CTX_set_padding(EVP_CIPHER_CTX *x, int padding);
  int EVP_CIPHER_CTX_set_key_length(EVP_CIPHER_CTX *x, int keylen);
  int EVP_CIPHER_CTX_ctrl(EVP_CIPHER_CTX *ctx, int type, int arg, void *ptr);
  int EVP_CIPHER_CTX_cleanup(EVP_CIPHER_CTX *a);
@@ -74,14 +96,19 @@ EVP_CIPHER_asn1_to_param - EVP cipher routines
 The EVP cipher routines are a high level interface to certain
 symmetric ciphers.
 
-EVP_EncryptInit() initializes a cipher context B<ctx> for encryption
-with cipher B<type>. B<type> is normally supplied by a function such
-as EVP_des_cbc() . B<key> is the symmetric key to use and B<iv> is the
-IV to use (if necessary), the actual number of bytes used for the
-key and IV depends on the cipher. It is possible to set all parameters
-to NULL except B<type> in an initial call and supply the remaining
-parameters in subsequent calls, all of which have B<type> set to NULL.
-This is done when the default cipher parameters are not appropriate.
+EVP_CIPHER_CTX_init() initializes cipher contex B<ctx>.
+
+EVP_EncryptInit_ex() sets up cipher context B<ctx> for encryption
+with cipher B<type> from ENGINE B<impl>. B<ctx> must be initialized
+before calling this function. B<type> is normally supplied
+by a function such as EVP_des_cbc(). If B<impl> is NULL then the
+default implementation is used. B<key> is the symmetric key to use
+and B<iv> is the IV to use (if necessary), the actual number of bytes
+used for the key and IV depends on the cipher. It is possible to set
+all parameters to NULL except B<type> in an initial call and supply
+the remaining parameters in subsequent calls, all of which have B<type>
+set to NULL. This is done when the default cipher parameters are not
+appropriate.
 
 EVP_EncryptUpdate() encrypts B<inl> bytes from the buffer B<in> and
 writes the encrypted version to B<out>. This function can be called
@@ -89,32 +116,49 @@ multiple times to encrypt successive blocks of data. The amount
 of data written depends on the block alignment of the encrypted data:
 as a result the amount of data written may be anything from zero bytes
 to (inl + cipher_block_size - 1) so B<outl> should contain sufficient
-room.  The actual number of bytes written is placed in B<outl>.
+room. The actual number of bytes written is placed in B<outl>.
+
+If padding is enabled (the default) then EVP_EncryptFinal_ex() encrypts
+the "final" data, that is any data that remains in a partial block.
+It uses L<standard block padding|/NOTES> (aka PKCS padding). The encrypted
+final data is written to B<out> which should have sufficient space for
+one cipher block. The number of bytes written is placed in B<outl>. After
+this function is called the encryption operation is finished and no further
+calls to EVP_EncryptUpdate() should be made.
 
-EVP_EncryptFinal() encrypts the "final" data, that is any data that
-remains in a partial block. It uses L<standard block padding|/NOTES> (aka PKCS
-padding). The encrypted final data is written to B<out> which should
-have sufficient space for one cipher block. The number of bytes written
-is placed in B<outl>. After this function is called the encryption operation
-is finished and no further calls to EVP_EncryptUpdate() should be made.
+If padding is disabled then EVP_EncryptFinal_ex() will not encrypt any more
+data and it will return an error if any data remains in a partial block:
+that is if the total data length is not a multiple of the block size. 
 
-EVP_DecryptInit(), EVP_DecryptUpdate() and EVP_DecryptFinal() are the
+EVP_DecryptInit_ex(), EVP_DecryptUpdate() and EVP_DecryptFinal_ex() are the
 corresponding decryption operations. EVP_DecryptFinal() will return an
-error code if the final block is not correctly formatted. The parameters
-and restrictions are identical to the encryption operations except that
-the decrypted data buffer B<out> passed to EVP_DecryptUpdate() should
-have sufficient room for (B<inl> + cipher_block_size) bytes unless the
-cipher block size is 1 in which case B<inl> bytes is sufficient.
-
-EVP_CipherInit(), EVP_CipherUpdate() and EVP_CipherFinal() are functions
-that can be used for decryption or encryption. The operation performed
-depends on the value of the B<enc> parameter. It should be set to 1 for
-encryption, 0 for decryption and -1 to leave the value unchanged (the
-actual value of 'enc' being supplied in a previous call).
-
-EVP_CIPHER_CTX_cleanup() clears all information from a cipher context.
-It should be called after all operations using a cipher are complete
-so sensitive information does not remain in memory.
+error code if padding is enabled and the final block is not correctly
+formatted. The parameters and restrictions are identical to the encryption
+operations except that if padding is enabled the decrypted data buffer B<out>
+passed to EVP_DecryptUpdate() should have sufficient room for
+(B<inl> + cipher_block_size) bytes unless the cipher block size is 1 in
+which case B<inl> bytes is sufficient.
+
+EVP_CipherInit_ex(), EVP_CipherUpdate() and EVP_CipherFinal_ex() are
+functions that can be used for decryption or encryption. The operation
+performed depends on the value of the B<enc> parameter. It should be set
+to 1 for encryption, 0 for decryption and -1 to leave the value unchanged
+(the actual value of 'enc' being supplied in a previous call).
+
+EVP_CIPHER_CTX_cleanup() clears all information from a cipher context
+and free up any allocated memory associate with it. It should be called
+after all operations using a cipher are complete so sensitive information
+does not remain in memory.
+
+EVP_EncryptInit(), EVP_DecryptInit() and EVP_CipherInit() behave in a
+similar way to EVP_EncryptInit_ex(), EVP_DecryptInit_ex and
+EVP_CipherInit_ex() except the B<ctx> paramter does not need to be
+initialized and they always use the default cipher implementation.
+
+EVP_EncryptFinal(), EVP_DecryptFinal() and EVP_CipherFinal() behave in a
+similar way to EVP_EncryptFinal_ex(), EVP_DecryptFinal_ex() and
+EVP_CipherFinal_ex() except B<ctx> is automatically cleaned up 
+after the call.
 
 EVP_get_cipherbyname(), EVP_get_cipherbynid() and EVP_get_cipherbyobj()
 return an EVP_CIPHER structure when passed a cipher name, a NID or an
@@ -125,6 +169,13 @@ passed an B<EVP_CIPHER> or B<EVP_CIPHER_CTX> structure.  The actual NID
 value is an internal value which may not have a corresponding OBJECT
 IDENTIFIER.
 
+EVP_CIPHER_CTX_set_padding() enables or disables padding. By default
+encryption operations are padded using standard block padding and the
+padding is checked and removed when decrypting. If the B<pad> parameter
+is zero then no padding is performed, the total amount of data encrypted
+or decrypted must then be a multiple of the block size or an error will
+occur.
+
 EVP_CIPHER_key_length() and EVP_CIPHER_CTX_key_length() return the key
 length of a cipher when passed an B<EVP_CIPHER> or B<EVP_CIPHER_CTX>
 structure. The constant B<EVP_MAX_KEY_LENGTH> is the maximum key length
@@ -185,14 +236,14 @@ RC5 can be set.
 
 =head1 RETURN VALUES
 
-EVP_EncryptInit(), EVP_EncryptUpdate() and EVP_EncryptFinal() return 1 for success
-and 0 for failure.
+EVP_CIPHER_CTX_init, EVP_EncryptInit_ex(), EVP_EncryptUpdate() and
+EVP_EncryptFinal_ex() return 1 for success and 0 for failure.
 
-EVP_DecryptInit() and EVP_DecryptUpdate() return 1 for success and 0 for failure.
-EVP_DecryptFinal() returns 0 if the decrypt failed or 1 for success.
+EVP_DecryptInit_ex() and EVP_DecryptUpdate() return 1 for success and 0 for failure.
+EVP_DecryptFinal_ex() returns 0 if the decrypt failed or 1 for success.
 
-EVP_CipherInit() and EVP_CipherUpdate() return 1 for success and 0 for failure.
-EVP_CipherFinal() returns 1 for a decryption failure or 1 for success.
+EVP_CipherInit_ex() and EVP_CipherUpdate() return 1 for success and 0 for failure.
+EVP_CipherFinal_ex() returns 0 for a decryption failure or 1 for success.
 
 EVP_CIPHER_CTX_cleanup() returns 1 for success and 0 for failure.
 
@@ -207,6 +258,8 @@ size.
 EVP_CIPHER_key_length() and EVP_CIPHER_CTX_key_length() return the key
 length.
 
+EVP_CIPHER_CTX_set_padding() always returns 1.
+
 EVP_CIPHER_iv_length() and EVP_CIPHER_CTX_iv_length() return the IV
 length or zero if the cipher does not use an IV.
 
@@ -301,25 +354,26 @@ encrypted then 5 padding bytes of value 5 will be added.
 
 When decrypting the final block is checked to see if it has the correct form.
 
-Although the decryption operation can produce an error, it is not a strong
-test that the input data or key is correct. A random block has better than
-1 in 256 chance of being of the correct format and problems with the
-input data earlier on will not produce a final decrypt error.
+Although the decryption operation can produce an error if padding is enabled,
+it is not a strong test that the input data or key is correct. A random block
+has better than 1 in 256 chance of being of the correct format and problems with
+the input data earlier on will not produce a final decrypt error.
 
-The functions EVP_EncryptInit(), EVP_EncryptUpdate(), EVP_EncryptFinal(),
-EVP_DecryptInit(), EVP_DecryptUpdate(), EVP_CipherInit() and EVP_CipherUpdate()
-and EVP_CIPHER_CTX_cleanup() did not return errors in OpenSSL version 0.9.5a or
-earlier. Software only versions of encryption algorithms will never return
-error codes for these functions, unless there is a programming error (for example
-and attempt to set the key before the cipher is set in EVP_EncryptInit() ).
+If padding is disabled then the decryption operation will always succeed if
+the total amount of data decrypted is a multiple of the block size.
+
+The functions EVP_EncryptInit(), EVP_EncryptFinal(), EVP_DecryptInit(),
+EVP_CipherInit() and EVP_CipherFinal() are obsolete but are retained for
+compatibility with existing code. New code should use EVP_EncryptInit_ex(),
+EVP_EncryptFinal_ex(), EVP_DecryptInit_ex(), EVP_DecryptFinal_ex(),
+EVP_CipherInit_ex() and EVP_CipherFinal_ex() because they can reuse an
+existing context without allocating and freeing it up on each call.
 
 =head1 BUGS
 
 For RC5 the number of rounds can currently only be set to 8, 12 or 16. This is
 a limitation of the current RC5 code rather than the EVP interface.
 
-It should be possible to disable PKCS padding: currently it isn't.
-
 EVP_MAX_KEY_LENGTH and EVP_MAX_IV_LENGTH only refer to the internal ciphers with
 default key lengths. If custom ciphers exceed these values the results are
 unpredictable. This is because it has become standard practice to define a 
@@ -333,22 +387,113 @@ for certain common S/MIME ciphers (RC2, DES, triple DES) in CBC mode.
 Get the number of rounds used in RC5:
 
  int nrounds;
- EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GET_RC5_ROUNDS, 0, &i);
+ EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GET_RC5_ROUNDS, 0, &nrounds);
 
 Get the RC2 effective key length:
 
  int key_bits;
- EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GET_RC2_KEY_BITS, 0, &i);
+ EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GET_RC2_KEY_BITS, 0, &key_bits);
 
 Set the number of rounds used in RC5:
 
  int nrounds;
- EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_SET_RC5_ROUNDS, i, NULL);
+ EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_SET_RC5_ROUNDS, nrounds, NULL);
 
-Set the number of rounds used in RC2:
+Set the effective key length used in RC2:
+
+ int key_bits;
+ EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_SET_RC2_KEY_BITS, key_bits, NULL);
+
+Encrypt a string using blowfish:
+
+ int do_crypt(char *outfile)
+        {
+        unsigned char outbuf[1024];
+        int outlen, tmplen;
+        /* Bogus key and IV: we'd normally set these from
+         * another source.
+         */
+        unsigned char key[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
+        unsigned char iv[] = {1,2,3,4,5,6,7,8};
+        char intext[] = "Some Crypto Text";
+        EVP_CIPHER_CTX ctx;
+        FILE *out;
+        EVP_CIPHER_CTX_init(&ctx);
+        EVP_EncryptInit_ex(&ctx, NULL, EVP_bf_cbc(), key, iv);
+
+        if(!EVP_EncryptUpdate(&ctx, outbuf, &outlen, intext, strlen(intext)))
+                {
+                /* Error */
+                return 0;
+                }
+        /* Buffer passed to EVP_EncryptFinal() must be after data just
+         * encrypted to avoid overwriting it.
+         */
+        if(!EVP_EncryptFinal_ex(&ctx, outbuf + outlen, &tmplen))
+                {
+                /* Error */
+                return 0;
+                }
+        outlen += tmplen;
+        EVP_CIPHER_CTX_cleanup(&ctx);
+        /* Need binary mode for fopen because encrypted data is
+         * binary data. Also cannot use strlen() on it because
+         * it wont be null terminated and may contain embedded
+         * nulls.
+         */
+        out = fopen(outfile, "wb");
+        fwrite(outbuf, 1, outlen, out);
+        fclose(out);
+        return 1;
+        }
+
+The ciphertext from the above example can be decrypted using the B<openssl>
+utility with the command line:
+ 
+ S<openssl bf -in cipher.bin -K 000102030405060708090A0B0C0D0E0F -iv 0102030405060708 -d>
+
+General encryption, decryption function example using FILE I/O and RC2 with an
+80 bit key:
+
+ int do_crypt(FILE *in, FILE *out, int do_encrypt)
+        {
+        /* Allow enough space in output buffer for additional block */
+        inbuf[1024], outbuf[1024 + EVP_MAX_BLOCK_LENGTH];
+        int inlen, outlen;
+        /* Bogus key and IV: we'd normally set these from
+         * another source.
+         */
+        unsigned char key[] = "0123456789";
+        unsigned char iv[] = "12345678";
+        /* Don't set key or IV because we will modify the parameters */
+        EVP_CIPHER_CTX_init(&ctx);
+        EVP_CipherInit_ex(&ctx, EVP_rc2(), NULL, NULL, NULL, do_encrypt);
+        EVP_CIPHER_CTX_set_key_length(&ctx, 10);
+        /* We finished modifying parameters so now we can set key and IV */
+        EVP_CipherInit_ex(&ctx, NULL, NULL, key, iv, do_encrypt);
+
+        for(;;) 
+                {
+                inlen = fread(inbuf, 1, 1024, in);
+                if(inlen <= 0) break;
+                if(!EVP_CipherUpdate(&ctx, outbuf, &outlen, inbuf, inlen))
+                        {
+                        /* Error */
+                        return 0;
+                        }
+                fwrite(outbuf, 1, outlen, out);
+                }
+        if(!EVP_CipherFinal_ex(&ctx, outbuf, &outlen))
+                {
+                /* Error */
+                return 0;
+                }
+        fwrite(outbuf, 1, outlen, out);
+
+        EVP_CIPHER_CTX_cleanup(&ctx);
+        return 1;
+        }
 
- int nrounds;
- EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_SET_RC2_KEY_BITS, i, NULL);
 
 =head1 SEE ALSO
 
diff --git a/src/lib/libssl/src/doc/crypto/EVP_SignInit.pod b/src/lib/libssl/src/doc/crypto/EVP_SignInit.pod
index d5ce245ecd..b1ac129430 100644
--- a/src/lib/libssl/src/doc/crypto/EVP_SignInit.pod
+++ b/src/lib/libssl/src/doc/crypto/EVP_SignInit.pod
@@ -8,10 +8,12 @@ EVP_SignInit, EVP_SignUpdate, EVP_SignFinal - EVP signing functions
 
  #include <openssl/evp.h>
 
- void EVP_SignInit(EVP_MD_CTX *ctx, const EVP_MD *type);
- void EVP_SignUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
+ int EVP_SignInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl);
+ int EVP_SignUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
  int EVP_SignFinal(EVP_MD_CTX *ctx,unsigned char *sig,unsigned int *s, EVP_PKEY *pkey);
 
+ void EVP_SignInit(EVP_MD_CTX *ctx, const EVP_MD *type);
+
  int EVP_PKEY_size(EVP_PKEY *pkey);
 
 =head1 DESCRIPTION
@@ -19,9 +21,9 @@ EVP_SignInit, EVP_SignUpdate, EVP_SignFinal - EVP signing functions
 The EVP signature routines are a high level interface to digital
 signatures.
 
-EVP_SignInit() initializes a signing context B<ctx> to using digest
-B<type>: this will typically be supplied by a function such as
-EVP_sha1().
+EVP_SignInit_ex() sets up signing context B<ctx> to use digest
+B<type> from ENGINE B<impl>. B<ctx> must be initialized with
+EVP_MD_CTX_init() before calling this function.
 
 EVP_SignUpdate() hashes B<cnt> bytes of data at B<d> into the
 signature context B<ctx>. This function can be called several times on the
@@ -31,18 +33,18 @@ EVP_SignFinal() signs the data in B<ctx> using the private key B<pkey>
 and places the signature in B<sig>. If the B<s> parameter is not NULL
 then the number of bytes of data written (i.e. the length of the signature)
 will be written to the integer at B<s>, at most EVP_PKEY_size(pkey) bytes
-will be written.  After calling EVP_SignFinal() no additional calls to
-EVP_SignUpdate() can be made, but EVP_SignInit() can be called to initialize
-a new signature operation.
+will be written. 
+
+EVP_SignInit() initializes a signing context B<ctx> to use the default
+implementation of digest B<type>.
 
 EVP_PKEY_size() returns the maximum size of a signature in bytes. The actual
 signature returned by EVP_SignFinal() may be smaller.
 
 =head1 RETURN VALUES
 
-EVP_SignInit() and EVP_SignUpdate() do not return values.
-
-EVP_SignFinal() returns 1 for success and 0 for failure.
+EVP_SignInit_ex(), EVP_SignUpdate() and EVP_SignFinal() return 1
+for success and 0 for failure.
 
 EVP_PKEY_size() returns the maximum size of a signature in bytes.
 
@@ -63,11 +65,18 @@ When signing with DSA private keys the random number generator must be seeded
 or the operation will fail. The random number generator does not need to be
 seeded for RSA signatures.
 
+The call to EVP_SignFinal() internally finalizes a copy of the digest context.
+This means that calls to EVP_SignUpdate() and EVP_SignFinal() can be called
+later to digest and sign additional data.
+
+Since only a copy of the digest context is ever finalized the context must
+be cleaned up after use by calling EVP_MD_CTX_cleanup() or a memory leak
+will occur.
+
 =head1 BUGS
 
-Several of the functions do not return values: maybe they should. Although the
-internal digest operations will never fail some future hardware based operations
-might.
+Older versions of this documentation wrongly stated that calls to 
+EVP_SignUpdate() could not be made after calling EVP_SignFinal().
 
 =head1 SEE ALSO
 
@@ -82,4 +91,6 @@ L<SHA1(3)|SHA1(3)>, L<digest(1)|digest(1)>
 EVP_SignInit(), EVP_SignUpdate() and EVP_SignFinal() are
 available in all versions of SSLeay and OpenSSL.
 
+EVP_SignInit_ex() was added in OpenSSL 0.9.7
+
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/EVP_VerifyInit.pod b/src/lib/libssl/src/doc/crypto/EVP_VerifyInit.pod
index 736a0f4a82..80c656fde8 100644
--- a/src/lib/libssl/src/doc/crypto/EVP_VerifyInit.pod
+++ b/src/lib/libssl/src/doc/crypto/EVP_VerifyInit.pod
@@ -8,30 +8,35 @@ EVP_VerifyInit, EVP_VerifyUpdate, EVP_VerifyFinal - EVP signature verification f
 
  #include <openssl/evp.h>
 
- void EVP_VerifyInit(EVP_MD_CTX *ctx, const EVP_MD *type);
- void EVP_VerifyUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
+ int EVP_VerifyInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl);
+ int EVP_VerifyUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
  int EVP_VerifyFinal(EVP_MD_CTX *ctx,unsigned char *sigbuf, unsigned int siglen,EVP_PKEY *pkey);
 
+ int EVP_VerifyInit(EVP_MD_CTX *ctx, const EVP_MD *type);
+
 =head1 DESCRIPTION
 
 The EVP signature verification routines are a high level interface to digital
 signatures.
 
-EVP_VerifyInit() initializes a verification context B<ctx> to using digest
-B<type>: this will typically be supplied by a function such as EVP_sha1().
+EVP_VerifyInit_ex() sets up verification context B<ctx> to use digest
+B<type> from ENGINE B<impl>. B<ctx> must be initialized by calling
+EVP_MD_CTX_init() before calling this function.
 
 EVP_VerifyUpdate() hashes B<cnt> bytes of data at B<d> into the
 verification context B<ctx>. This function can be called several times on the
 same B<ctx> to include additional data.
 
 EVP_VerifyFinal() verifies the data in B<ctx> using the public key B<pkey>
-and against the B<siglen> bytes at B<sigbuf>. After calling EVP_VerifyFinal()
-no additional calls to EVP_VerifyUpdate() can be made, but EVP_VerifyInit()
-can be called to initialize a new verification operation.
+and against the B<siglen> bytes at B<sigbuf>.
+
+EVP_VerifyInit() initializes verification context B<ctx> to use the default
+implementation of digest B<type>.
 
 =head1 RETURN VALUES
 
-EVP_VerifyInit() and EVP_VerifyUpdate() do not return values.
+EVP_VerifyInit_ex() and EVP_VerifyUpdate() return 1 for success and 0 for
+failure.
 
 EVP_VerifyFinal() returns 1 for a correct signature, 0 for failure and -1 if some
 other error occurred.
@@ -49,11 +54,18 @@ digest algorithm must be used with the correct public key type. A list of
 algorithms and associated public key algorithms appears in 
 L<EVP_DigestInit(3)|EVP_DigestInit(3)>.
 
+The call to EVP_VerifyFinal() internally finalizes a copy of the digest context.
+This means that calls to EVP_VerifyUpdate() and EVP_VerifyFinal() can be called
+later to digest and verify additional data.
+
+Since only a copy of the digest context is ever finalized the context must
+be cleaned up after use by calling EVP_MD_CTX_cleanup() or a memory leak
+will occur.
+
 =head1 BUGS
 
-Several of the functions do not return values: maybe they should. Although the
-internal digest operations will never fail some future hardware based operations
-might.
+Older versions of this documentation wrongly stated that calls to 
+EVP_VerifyUpdate() could not be made after calling EVP_VerifyFinal().
 
 =head1 SEE ALSO
 
@@ -69,4 +81,6 @@ L<sha(3)|sha(3)>, L<digest(1)|digest(1)>
 EVP_VerifyInit(), EVP_VerifyUpdate() and EVP_VerifyFinal() are
 available in all versions of SSLeay and OpenSSL.
 
+EVP_VerifyInit_ex() was added in OpenSSL 0.9.7
+
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/OPENSSL_VERSION_NUMBER.pod b/src/lib/libssl/src/doc/crypto/OPENSSL_VERSION_NUMBER.pod
index 68ea723259..c39ac35e78 100644
--- a/src/lib/libssl/src/doc/crypto/OPENSSL_VERSION_NUMBER.pod
+++ b/src/lib/libssl/src/doc/crypto/OPENSSL_VERSION_NUMBER.pod
@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-OPENSSL_VERSION_NUMBER, SSLeay SSLeay_version - get OpenSSL version number
+OPENSSL_VERSION_NUMBER, SSLeay, SSLeay_version - get OpenSSL version number
 
 =head1 SYNOPSIS
 
@@ -11,7 +11,7 @@ OPENSSL_VERSION_NUMBER, SSLeay SSLeay_version - get OpenSSL version number
 
  #include <openssl/crypto.h>
  long SSLeay(void);
- char *SSLeay_version(int t);
+ const char *SSLeay_version(int t);
 
 =head1 DESCRIPTION
 
@@ -55,20 +55,32 @@ SSLeay_version() returns different strings depending on B<t>:
 =over 4
 
 =item SSLEAY_VERSION
+
 The text variant of the version number and the release date.  For example,
 "OpenSSL 0.9.5a 1 Apr 2000".
 
 =item SSLEAY_CFLAGS
-The flags given to the C compiler when compiling OpenSSL are returned in a
-string.
+
+The compiler flags set for the compilation process in the form
+"compiler: ..."  if available or "compiler: information not available"
+otherwise.
+
+=item SSLEAY_BUILT_ON
+
+The date of the build process in the form "built on: ..." if available
+or "built on: date not available" otherwise.
 
 =item SSLEAY_PLATFORM
-The platform name used when OpenSSL was configured is returned.
 
-=back
+The "Configure" target of the library build in the form "platform: ..."
+if available or "platform: information not available" otherwise.
+
+=item SSLEAY_DIR
 
-If the data request isn't available, a text saying that the information is
-not available is returned.
+The "OPENSSLDIR" setting of the library build in the form "OPENSSLDIR: "...""
+if available or "OPENSSLDIR: N/A" otherwise.
+
+=back
 
 For an unknown B<t>, the text "not available" is returned.
 
@@ -84,5 +96,6 @@ L<crypto(3)|crypto(3)>
 
 SSLeay() and SSLEAY_VERSION_NUMBER are available in all versions of SSLeay and OpenSSL.
 OPENSSL_VERSION_NUMBER is available in all versions of OpenSSL.
+B<SSLEAY_DIR> was added in OpenSSL 0.9.7.
 
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/RAND_egd.pod b/src/lib/libssl/src/doc/crypto/RAND_egd.pod
index 71cab3ca04..62adbe19b2 100644
--- a/src/lib/libssl/src/doc/crypto/RAND_egd.pod
+++ b/src/lib/libssl/src/doc/crypto/RAND_egd.pod
@@ -11,6 +11,8 @@ RAND_egd - query entropy gathering daemon
  int RAND_egd(const char *path);
  int RAND_egd_bytes(const char *path, int bytes);
 
+ int RAND_query_egd_bytes(const char *path, unsigned char *buf, int bytes);
+
 =head1 DESCRIPTION
 
 RAND_egd() queries the entropy gathering daemon EGD on socket B<path>.
@@ -27,6 +29,11 @@ be generated, it is not necessary to request the full amount 255 bytes from
 the EGD socket. This can be advantageous, since the amount of entropy
 that can be retrieved from EGD over time is limited.
 
+RAND_query_egd_bytes() performs the actual query of the EGD daemon on socket
+B<path>. If B<buf> is given, B<bytes> bytes are queried and written into
+B<buf>. If B<buf> is NULL, B<bytes> bytes are queried and used to seed the
+OpenSSL built-in PRNG using L<RAND_add(3)|RAND_add(3)>.
+
 =head1 NOTES
 
 On systems without /dev/*random devices providing entropy from the kernel,
@@ -47,12 +54,19 @@ http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html .
 PRNGD does employ an internal PRNG itself and can therefore never run
 out of entropy.
 
+OpenSSL automatically queries EGD when entropy is requested via RAND_bytes()
+or the status is checked via RAND_status() for the first time, if the socket
+is located at /var/run/egd-pool, /dev/egd-pool or /etc/egd-pool.
+
 =head1 RETURN VALUE
 
 RAND_egd() and RAND_egd_bytes() return the number of bytes read from the
 daemon on success, and -1 if the connection failed or the daemon did not
 return enough data to fully seed the PRNG.
 
+RAND_query_egd_bytes() returns the number of bytes read from the daemon on
+success, and -1 if the connection failed. The PRNG state is not considered.
+
 =head1 SEE ALSO
 
 L<rand(3)|rand(3)>, L<RAND_add(3)|RAND_add(3)>,
@@ -64,4 +78,8 @@ RAND_egd() is available since OpenSSL 0.9.5.
 
 RAND_egd_bytes() is available since OpenSSL 0.9.6.
 
+RAND_query_egd_bytes() is available since OpenSSL 0.9.7.
+
+The automatic query of /var/run/egd-pool et al was added in OpenSSL 0.9.7.
+
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/RSA_generate_key.pod b/src/lib/libssl/src/doc/crypto/RSA_generate_key.pod
index 0e0f0a764c..11bc0b3459 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_generate_key.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_generate_key.pod
@@ -19,7 +19,7 @@ be seeded prior to calling RSA_generate_key().
 
 The modulus size will be B<num> bits, and the public exponent will be
 B<e>. Key sizes with B<num> E<lt> 1024 should be considered insecure.
-The exponent is an odd number, typically 3 or 65535.
+The exponent is an odd number, typically 3, 17 or 65537.
 
 A callback function may be used to provide feedback about the
 progress of the key generation. If B<callback> is not B<NULL>, it
diff --git a/src/lib/libssl/src/doc/crypto/RSA_public_encrypt.pod b/src/lib/libssl/src/doc/crypto/RSA_public_encrypt.pod
index 23861c0004..8022a23f99 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_public_encrypt.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_public_encrypt.pod
@@ -74,10 +74,6 @@ SSL, PKCS #1 v2.0
 
 L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>, L<RSA_size(3)|RSA_size(3)>
 
-=head1 NOTES
-
-The L<RSA_PKCS1_RSAref(3)|RSA_PKCS1_RSAref(3)> method supports only the RSA_PKCS1_PADDING mode.
-
 =head1 HISTORY
 
 The B<padding> argument was added in SSLeay 0.8. RSA_NO_PADDING is
diff --git a/src/lib/libssl/src/doc/crypto/RSA_set_method.pod b/src/lib/libssl/src/doc/crypto/RSA_set_method.pod
index b672712292..14917dd35f 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_set_method.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_set_method.pod
@@ -3,7 +3,7 @@
 =head1 NAME
 
 RSA_set_default_method, RSA_get_default_method, RSA_set_method,
-RSA_get_method, RSA_PKCS1_SSLeay, RSA_PKCS1_RSAref,
+RSA_get_method, RSA_PKCS1_SSLeay,
 RSA_null_method, RSA_flags, RSA_new_method - select RSA method
 
 =head1 SYNOPSIS
@@ -15,14 +15,12 @@ RSA_null_method, RSA_flags, RSA_new_method - select RSA method
 
  RSA_METHOD *RSA_get_default_openssl_method(void);
 
- RSA_METHOD *RSA_set_method(RSA *rsa, ENGINE *engine);
+ int RSA_set_method(RSA *rsa, ENGINE *engine);
 
  RSA_METHOD *RSA_get_method(RSA *rsa);
 
  RSA_METHOD *RSA_PKCS1_SSLeay(void);
 
- RSA_METHOD *RSA_PKCS1_RSAref(void);
-
  RSA_METHOD *RSA_null_method(void);
 
  int RSA_flags(RSA *rsa);
@@ -35,17 +33,8 @@ An B<RSA_METHOD> specifies the functions that OpenSSL uses for RSA
 operations. By modifying the method, alternative implementations
 such as hardware accelerators may be used.
 
-Initially, the default is to use the OpenSSL internal implementation,
-unless OpenSSL was configured with the C<rsaref> or C<-DRSA_NULL>
-options. RSA_PKCS1_SSLeay() returns a pointer to that method.
-
-RSA_PKCS1_RSAref() returns a pointer to a method that uses the RSAref
-library. This is the default method in the C<rsaref> configuration;
-the function is not available in other configurations.
-RSA_null_method() returns a pointer to a method that does not support
-the RSA transformation. It is the default if OpenSSL is compiled with
-C<-DRSA_NULL>. These methods may be useful in the USA because of a
-patent on the RSA cryptosystem.
+Initially, the default is to use the OpenSSL internal implementation.
+RSA_PKCS1_SSLeay() returns a pointer to that method.
 
 RSA_set_default_openssl_method() makes B<meth> the default method for all B<RSA>
 structures created later. B<NB:> This is true only whilst the default engine
@@ -132,9 +121,8 @@ the default engine for RSA operations is used.
 
 =head1 RETURN VALUES
 
-RSA_PKCS1_SSLeay(), RSA_PKCS1_RSAref(), RSA_PKCS1_null_method(),
-RSA_get_default_openssl_method() and RSA_get_method() return pointers to
-the respective RSA_METHODs.
+RSA_PKCS1_SSLeay(), RSA_PKCS1_null_method(), RSA_get_default_openssl_method()
+and RSA_get_method() return pointers to the respective RSA_METHODs.
 
 RSA_set_default_openssl_method() returns no value.
 
@@ -163,6 +151,6 @@ added in OpenSSL 0.9.4.
 RSA_set_default_openssl_method() and RSA_get_default_openssl_method()
 replaced RSA_set_default_method() and RSA_get_default_method() respectively,
 and RSA_set_method() and RSA_new_method() were altered to use B<ENGINE>s
-rather than B<DH_METHOD>s during development of OpenSSL 0.9.6.
+rather than B<RSA_METHOD>s during development of OpenSSL 0.9.6.
 
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/blowfish.pod b/src/lib/libssl/src/doc/crypto/blowfish.pod
index 65b8be388c..ed71334f56 100644
--- a/src/lib/libssl/src/doc/crypto/blowfish.pod
+++ b/src/lib/libssl/src/doc/crypto/blowfish.pod
@@ -27,7 +27,7 @@ BF_cfb64_encrypt, BF_ofb64_encrypt, BF_options - Blowfish encryption
 
 =head1 DESCRIPTION
 
-This library implements the Blowfish cipher, which is invented and described
+This library implements the Blowfish cipher, which was invented and described
 by Counterpane (see http://www.counterpane.com/blowfish.html ).
 
 Blowfish is a block cipher that operates on 64 bit (8 byte) blocks of data.
@@ -57,7 +57,7 @@ for the same message.  B<ivec> may be initialized with anything, but the
 recipient needs to know what it was initialized with, or it won't be able
 to decrypt.  Some programs and protocols simplify this, like SSH, where
 B<ivec> is simply initialized to zero.
-BF_cbc_encrypt() operates of data that is a multiple of 8 bytes long, while
+BF_cbc_encrypt() operates on data that is a multiple of 8 bytes long, while
 BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to encrypt an variable
 number of bytes (the amount does not have to be an exact multiple of 8).  The
 purpose of the latter two is to simulate stream ciphers, and therefore, they
diff --git a/src/lib/libssl/src/doc/crypto/bn.pod b/src/lib/libssl/src/doc/crypto/bn.pod
index d183028d61..210dfeac08 100644
--- a/src/lib/libssl/src/doc/crypto/bn.pod
+++ b/src/lib/libssl/src/doc/crypto/bn.pod
@@ -21,19 +21,27 @@ bn - multiprecision integer arithmetics
  BIGNUM *BN_copy(BIGNUM *a, const BIGNUM *b);
  BIGNUM *BN_dup(const BIGNUM *a);
 
+ BIGNUM *BN_swap(BIGNUM *a, BIGNUM *b);
+
  int BN_num_bytes(const BIGNUM *a);
  int BN_num_bits(const BIGNUM *a);
  int BN_num_bits_word(BN_ULONG w);
 
- int BN_add(BIGNUM *r, BIGNUM *a, BIGNUM *b);
+ int BN_add(BIGNUM *r, const BIGNUM *a, const BIGNUM *b);
  int BN_sub(BIGNUM *r, const BIGNUM *a, const BIGNUM *b);
  int BN_mul(BIGNUM *r, BIGNUM *a, BIGNUM *b, BN_CTX *ctx);
+ int BN_sqr(BIGNUM *r, BIGNUM *a, BN_CTX *ctx);
  int BN_div(BIGNUM *dv, BIGNUM *rem, const BIGNUM *a, const BIGNUM *d,
          BN_CTX *ctx);
- int BN_sqr(BIGNUM *r, BIGNUM *a, BN_CTX *ctx);
  int BN_mod(BIGNUM *rem, const BIGNUM *a, const BIGNUM *m, BN_CTX *ctx);
+ int BN_nnmod(BIGNUM *rem, const BIGNUM *a, const BIGNUM *m, BN_CTX *ctx);
+ int BN_mod_add(BIGNUM *ret, BIGNUM *a, BIGNUM *b, const BIGNUM *m,
+         BN_CTX *ctx);
+ int BN_mod_sub(BIGNUM *ret, BIGNUM *a, BIGNUM *b, const BIGNUM *m,
+         BN_CTX *ctx);
  int BN_mod_mul(BIGNUM *ret, BIGNUM *a, BIGNUM *b, const BIGNUM *m,
          BN_CTX *ctx);
+ int BN_mod_sqr(BIGNUM *ret, BIGNUM *a, const BIGNUM *m, BN_CTX *ctx);
  int BN_exp(BIGNUM *r, BIGNUM *a, BIGNUM *p, BN_CTX *ctx);
  int BN_mod_exp(BIGNUM *r, BIGNUM *a, const BIGNUM *p,
          const BIGNUM *m, BN_CTX *ctx);
@@ -54,13 +62,14 @@ bn - multiprecision integer arithmetics
 
  int BN_zero(BIGNUM *a);
  int BN_one(BIGNUM *a);
- BIGNUM *BN_value_one(void);
+ const BIGNUM *BN_value_one(void);
  int BN_set_word(BIGNUM *a, unsigned long w);
  unsigned long BN_get_word(BIGNUM *a);
 
  int BN_rand(BIGNUM *rnd, int bits, int top, int bottom);
  int BN_pseudo_rand(BIGNUM *rnd, int bits, int top, int bottom);
  int BN_rand_range(BIGNUM *rnd, BIGNUM *range);
+ int BN_pseudo_rand_range(BIGNUM *rnd, BIGNUM *range);
 
  BIGNUM *BN_generate_prime(BIGNUM *ret, int bits,int safe, BIGNUM *add,
          BIGNUM *rem, void (*callback)(int, int, void *), void *cb_arg);
@@ -138,7 +147,7 @@ of B<BIGNUM>s to external formats is described in L<BN_bn2bin(3)|BN_bn2bin(3)>.
 L<bn_internal(3)|bn_internal(3)>,
 L<dh(3)|dh(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>,
 L<BN_new(3)|BN_new(3)>, L<BN_CTX_new(3)|BN_CTX_new(3)>,
-L<BN_copy(3)|BN_copy(3)>, L<BN_num_bytes(3)|BN_num_bytes(3)>,
+L<BN_copy(3)|BN_copy(3)>, L<BN_swap(3)|BN_swap(3)>, L<BN_num_bytes(3)|BN_num_bytes(3)>,
 L<BN_add(3)|BN_add(3)>, L<BN_add_word(3)|BN_add_word(3)>,
 L<BN_cmp(3)|BN_cmp(3)>, L<BN_zero(3)|BN_zero(3)>, L<BN_rand(3)|BN_rand(3)>,
 L<BN_generate_prime(3)|BN_generate_prime(3)>, L<BN_set_bit(3)|BN_set_bit(3)>,
diff --git a/src/lib/libssl/src/doc/crypto/bn_internal.pod b/src/lib/libssl/src/doc/crypto/bn_internal.pod
index 8da244aed4..d6f3cfe2ee 100644
--- a/src/lib/libssl/src/doc/crypto/bn_internal.pod
+++ b/src/lib/libssl/src/doc/crypto/bn_internal.pod
@@ -34,9 +34,9 @@ library internal functions
    int nb);
  void bn_mul_low_normal(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n);
  void bn_mul_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n2,
-   BN_ULONG *tmp);
+   int dna,int dnb,BN_ULONG *tmp);
  void bn_mul_part_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b,
-   int tn, int n, BN_ULONG *tmp);
+   int n, int tna,int tnb, BN_ULONG *tmp);
  void bn_mul_low_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b,
    int n2, BN_ULONG *tmp);
  void bn_mul_high(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, BN_ULONG *l,
@@ -152,14 +152,15 @@ bn_mul_low_normal(B<r>, B<a>, B<b>, B<n>) operates on the B<n> word
 arrays B<r>, B<a> and B<b>.  It computes the B<n> low words of
 B<a>*B<b> and places the result in B<r>.
 
-bn_mul_recursive(B<r>, B<a>, B<b>, B<n2>, B<t>) operates on the B<n2>
-word arrays B<a> and B<b> and the 2*B<n2> word arrays B<r> and B<t>.
-B<n2> must be a power of 2.  It computes B<a>*B<b> and places the
-result in B<r>.
+bn_mul_recursive(B<r>, B<a>, B<b>, B<n2>, B<dna>, B<dnb>, B<t>) operates
+on the word arrays B<a> and B<b> of length B<n2>+B<dna> and B<n2>+B<dnb>
+(B<dna> and B<dnb> are currently allowed to be 0 or negative) and the 2*B<n2>
+word arrays B<r> and B<t>.  B<n2> must be a power of 2.  It computes
+B<a>*B<b> and places the result in B<r>.
 
-bn_mul_part_recursive(B<r>, B<a>, B<b>, B<tn>, B<n>, B<tmp>) operates
-on the B<n>+B<tn> word arrays B<a> and B<b> and the 4*B<n> word arrays
-B<r> and B<tmp>.
+bn_mul_part_recursive(B<r>, B<a>, B<b>, B<n>, B<tna>, B<tnb, B<tmp>)
+operates on the word arrays B<a> and B<b> of length B<n>+B<tna> and
+B<n>+B<tnb> and the 4*B<n> word arrays B<r> and B<tmp>.
 
 bn_mul_low_recursive(B<r>, B<a>, B<b>, B<n2>, B<tmp>) operates on the
 B<n2> word arrays B<r> and B<tmp> and the B<n2>/2 word arrays B<a>
diff --git a/src/lib/libssl/src/doc/crypto/crypto.pod b/src/lib/libssl/src/doc/crypto/crypto.pod
index 07ba7e5bc9..c12eec1409 100644
--- a/src/lib/libssl/src/doc/crypto/crypto.pod
+++ b/src/lib/libssl/src/doc/crypto/crypto.pod
@@ -46,7 +46,8 @@ L<sha(3)|sha(3)>
 
 =item AUXILIARY FUNCTIONS
 
-L<err(3)|err(3)>, L<threads(3)|threads(3)>, L<rand(3)|rand(3)>
+L<err(3)|err(3)>, L<threads(3)|threads(3)>, L<rand(3)|rand(3)>,
+L<OPENSSL_VERSION_NUMBER(3)|OPENSSL_VERSION_NUMBER(3)>
 
 =item INPUT/OUTPUT, DATA ENCODING
 
diff --git a/src/lib/libssl/src/doc/crypto/des.pod b/src/lib/libssl/src/doc/crypto/des.pod
index 99080391b1..528c73acac 100644
--- a/src/lib/libssl/src/doc/crypto/des.pod
+++ b/src/lib/libssl/src/doc/crypto/des.pod
@@ -2,113 +2,105 @@
 
 =head1 NAME
 
-des_random_key, des_set_key, des_key_sched, des_set_key_checked,
-des_set_key_unchecked, des_set_odd_parity, des_is_weak_key,
-des_ecb_encrypt, des_ecb2_encrypt, des_ecb3_encrypt, des_ncbc_encrypt,
-des_cfb_encrypt, des_ofb_encrypt, des_pcbc_encrypt, des_cfb64_encrypt,
-des_ofb64_encrypt, des_xcbc_encrypt, des_ede2_cbc_encrypt,
-des_ede2_cfb64_encrypt, des_ede2_ofb64_encrypt, des_ede3_cbc_encrypt,
-des_ede3_cbcm_encrypt, des_ede3_cfb64_encrypt, des_ede3_ofb64_encrypt,
-des_read_password, des_read_2passwords, des_read_pw_string,
-des_cbc_cksum, des_quad_cksum, des_string_to_key, des_string_to_2keys,
-des_fcrypt, des_crypt, des_enc_read, des_enc_write - DES encryption
+DES_random_key, DES_set_key, DES_key_sched, DES_set_key_checked,
+DES_set_key_unchecked, DES_set_odd_parity, DES_is_weak_key,
+DES_ecb_encrypt, DES_ecb2_encrypt, DES_ecb3_encrypt, DES_ncbc_encrypt,
+DES_cfb_encrypt, DES_ofb_encrypt, DES_pcbc_encrypt, DES_cfb64_encrypt,
+DES_ofb64_encrypt, DES_xcbc_encrypt, DES_ede2_cbc_encrypt,
+DES_ede2_cfb64_encrypt, DES_ede2_ofb64_encrypt, DES_ede3_cbc_encrypt,
+DES_ede3_cbcm_encrypt, DES_ede3_cfb64_encrypt, DES_ede3_ofb64_encrypt,
+DES_cbc_cksum, DES_quad_cksum, DES_string_to_key, DES_string_to_2keys,
+DES_fcrypt, DES_crypt, DES_enc_read, DES_enc_write - DES encryption
 
 =head1 SYNOPSIS
 
  #include <openssl/des.h>
 
- void des_random_key(des_cblock *ret);
+ void DES_random_key(DES_cblock *ret);
 
- int des_set_key(const_des_cblock *key, des_key_schedule schedule);
- int des_key_sched(const_des_cblock *key, des_key_schedule schedule);
- int des_set_key_checked(const_des_cblock *key,
-        des_key_schedule schedule);
- void des_set_key_unchecked(const_des_cblock *key,
-        des_key_schedule schedule);
+ int DES_set_key(const_DES_cblock *key, DES_key_schedule *schedule);
+ int DES_key_sched(const_DES_cblock *key, DES_key_schedule *schedule);
+ int DES_set_key_checked(const_DES_cblock *key,
+        DES_key_schedule *schedule);
+ void DES_set_key_unchecked(const_DES_cblock *key,
+        DES_key_schedule *schedule);
 
- void des_set_odd_parity(des_cblock *key);
- int des_is_weak_key(const_des_cblock *key);
+ void DES_set_odd_parity(DES_cblock *key);
+ int DES_is_weak_key(const_DES_cblock *key);
 
- void des_ecb_encrypt(const_des_cblock *input, des_cblock *output, 
-        des_key_schedule ks, int enc);
- void des_ecb2_encrypt(const_des_cblock *input, des_cblock *output, 
-        des_key_schedule ks1, des_key_schedule ks2, int enc);
- void des_ecb3_encrypt(const_des_cblock *input, des_cblock *output, 
-        des_key_schedule ks1, des_key_schedule ks2, 
-        des_key_schedule ks3, int enc);
+ void DES_ecb_encrypt(const_DES_cblock *input, DES_cblock *output, 
+        DES_key_schedule *ks, int enc);
+ void DES_ecb2_encrypt(const_DES_cblock *input, DES_cblock *output, 
+        DES_key_schedule *ks1, DES_key_schedule *ks2, int enc);
+ void DES_ecb3_encrypt(const_DES_cblock *input, DES_cblock *output, 
+        DES_key_schedule *ks1, DES_key_schedule *ks2, 
+        DES_key_schedule *ks3, int enc);
 
- void des_ncbc_encrypt(const unsigned char *input, unsigned char *output, 
-        long length, des_key_schedule schedule, des_cblock *ivec, 
+ void DES_ncbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, DES_key_schedule *schedule, DES_cblock *ivec, 
         int enc);
- void des_cfb_encrypt(const unsigned char *in, unsigned char *out,
-        int numbits, long length, des_key_schedule schedule,
-        des_cblock *ivec, int enc);
- void des_ofb_encrypt(const unsigned char *in, unsigned char *out,
-        int numbits, long length, des_key_schedule schedule,
-        des_cblock *ivec);
- void des_pcbc_encrypt(const unsigned char *input, unsigned char *output, 
-        long length, des_key_schedule schedule, des_cblock *ivec, 
+ void DES_cfb_encrypt(const unsigned char *in, unsigned char *out,
+        int numbits, long length, DES_key_schedule *schedule,
+        DES_cblock *ivec, int enc);
+ void DES_ofb_encrypt(const unsigned char *in, unsigned char *out,
+        int numbits, long length, DES_key_schedule *schedule,
+        DES_cblock *ivec);
+ void DES_pcbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, DES_key_schedule *schedule, DES_cblock *ivec, 
         int enc);
- void des_cfb64_encrypt(const unsigned char *in, unsigned char *out,
-        long length, des_key_schedule schedule, des_cblock *ivec,
+ void DES_cfb64_encrypt(const unsigned char *in, unsigned char *out,
+        long length, DES_key_schedule *schedule, DES_cblock *ivec,
         int *num, int enc);
- void des_ofb64_encrypt(const unsigned char *in, unsigned char *out,
-        long length, des_key_schedule schedule, des_cblock *ivec,
+ void DES_ofb64_encrypt(const unsigned char *in, unsigned char *out,
+        long length, DES_key_schedule *schedule, DES_cblock *ivec,
         int *num);
 
- void des_xcbc_encrypt(const unsigned char *input, unsigned char *output, 
-        long length, des_key_schedule schedule, des_cblock *ivec, 
-        const_des_cblock *inw, const_des_cblock *outw, int enc);
-
- void des_ede2_cbc_encrypt(const unsigned char *input,
-        unsigned char *output, long length, des_key_schedule ks1,
-        des_key_schedule ks2, des_cblock *ivec, int enc);
- void des_ede2_cfb64_encrypt(const unsigned char *in,
-        unsigned char *out, long length, des_key_schedule ks1,
-        des_key_schedule ks2, des_cblock *ivec, int *num, int enc);
- void des_ede2_ofb64_encrypt(const unsigned char *in,
-        unsigned char *out, long length, des_key_schedule ks1,
-        des_key_schedule ks2, des_cblock *ivec, int *num);
-
- void des_ede3_cbc_encrypt(const unsigned char *input,
-        unsigned char *output, long length, des_key_schedule ks1,
-        des_key_schedule ks2, des_key_schedule ks3, des_cblock *ivec,
+ void DES_xcbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, DES_key_schedule *schedule, DES_cblock *ivec, 
+        const_DES_cblock *inw, const_DES_cblock *outw, int enc);
+
+ void DES_ede2_cbc_encrypt(const unsigned char *input,
+        unsigned char *output, long length, DES_key_schedule *ks1,
+        DES_key_schedule *ks2, DES_cblock *ivec, int enc);
+ void DES_ede2_cfb64_encrypt(const unsigned char *in,
+        unsigned char *out, long length, DES_key_schedule *ks1,
+        DES_key_schedule *ks2, DES_cblock *ivec, int *num, int enc);
+ void DES_ede2_ofb64_encrypt(const unsigned char *in,
+        unsigned char *out, long length, DES_key_schedule *ks1,
+        DES_key_schedule *ks2, DES_cblock *ivec, int *num);
+
+ void DES_ede3_cbc_encrypt(const unsigned char *input,
+        unsigned char *output, long length, DES_key_schedule *ks1,
+        DES_key_schedule *ks2, DES_key_schedule *ks3, DES_cblock *ivec,
         int enc);
- void des_ede3_cbcm_encrypt(const unsigned char *in, unsigned char *out, 
-        long length, des_key_schedule ks1, des_key_schedule ks2, 
-        des_key_schedule ks3, des_cblock *ivec1, des_cblock *ivec2, 
+ void DES_ede3_cbcm_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, DES_key_schedule *ks1, DES_key_schedule *ks2, 
+        DES_key_schedule *ks3, DES_cblock *ivec1, DES_cblock *ivec2, 
         int enc);
- void des_ede3_cfb64_encrypt(const unsigned char *in, unsigned char *out, 
-        long length, des_key_schedule ks1, des_key_schedule ks2,
-        des_key_schedule ks3, des_cblock *ivec, int *num, int enc);
- void des_ede3_ofb64_encrypt(const unsigned char *in, unsigned char *out, 
-        long length, des_key_schedule ks1, 
-        des_key_schedule ks2, des_key_schedule ks3, 
-        des_cblock *ivec, int *num);
-
- int des_read_password(des_cblock *key, const char *prompt, int verify);
- int des_read_2passwords(des_cblock *key1, des_cblock *key2, 
-        const char *prompt, int verify);
- int des_read_pw_string(char *buf, int length, const char *prompt,
-        int verify);
-
- DES_LONG des_cbc_cksum(const unsigned char *input, des_cblock *output, 
-        long length, des_key_schedule schedule, 
-        const_des_cblock *ivec);
- DES_LONG des_quad_cksum(const unsigned char *input, des_cblock output[], 
-        long length, int out_count, des_cblock *seed);
- void des_string_to_key(const char *str, des_cblock *key);
- void des_string_to_2keys(const char *str, des_cblock *key1,
-        des_cblock *key2);
-
- char *des_fcrypt(const char *buf, const char *salt, char *ret);
- char *des_crypt(const char *buf, const char *salt);
- char *crypt(const char *buf, const char *salt);
-
- int des_enc_read(int fd, void *buf, int len, des_key_schedule sched,
-        des_cblock *iv);
- int des_enc_write(int fd, const void *buf, int len,
-        des_key_schedule sched, des_cblock *iv);
+ void DES_ede3_cfb64_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, DES_key_schedule *ks1, DES_key_schedule *ks2,
+        DES_key_schedule *ks3, DES_cblock *ivec, int *num, int enc);
+ void DES_ede3_ofb64_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, DES_key_schedule *ks1, 
+        DES_key_schedule *ks2, DES_key_schedule *ks3, 
+        DES_cblock *ivec, int *num);
+
+ DES_LONG DES_cbc_cksum(const unsigned char *input, DES_cblock *output, 
+        long length, DES_key_schedule *schedule, 
+        const_DES_cblock *ivec);
+ DES_LONG DES_quad_cksum(const unsigned char *input, DES_cblock output[], 
+        long length, int out_count, DES_cblock *seed);
+ void DES_string_to_key(const char *str, DES_cblock *key);
+ void DES_string_to_2keys(const char *str, DES_cblock *key1,
+        DES_cblock *key2);
+
+ char *DES_fcrypt(const char *buf, const char *salt, char *ret);
+ char *DES_crypt(const char *buf, const char *salt);
+
+ int DES_enc_read(int fd, void *buf, int len, DES_key_schedule *sched,
+        DES_cblock *iv);
+ int DES_enc_write(int fd, const void *buf, int len,
+        DES_key_schedule *sched, DES_cblock *iv);
 
 =head1 DESCRIPTION
 
@@ -116,56 +108,52 @@ This library contains a fast implementation of the DES encryption
 algorithm.
 
 There are two phases to the use of DES encryption.  The first is the
-generation of a I<des_key_schedule> from a key, the second is the
-actual encryption.  A DES key is of type I<des_cblock>. This type is
+generation of a I<DES_key_schedule> from a key, the second is the
+actual encryption.  A DES key is of type I<DES_cblock>. This type is
 consists of 8 bytes with odd parity.  The least significant bit in
 each byte is the parity bit.  The key schedule is an expanded form of
 the key; it is used to speed the encryption process.
 
-des_random_key() generates a random key.  The PRNG must be seeded
-prior to using this function (see L<rand(3)|rand(3)>; for backward
-compatibility the function des_random_seed() is available as well).
-If the PRNG could not generate a secure key, 0 is returned.  In
-earlier versions of the library, des_random_key() did not generate
-secure keys.
+DES_random_key() generates a random key.  The PRNG must be seeded
+prior to using this function (see L<rand(3)|rand(3)>).  If the PRNG
+could not generate a secure key, 0 is returned.
 
 Before a DES key can be used, it must be converted into the
-architecture dependent I<des_key_schedule> via the
-des_set_key_checked() or des_set_key_unchecked() function.
+architecture dependent I<DES_key_schedule> via the
+DES_set_key_checked() or DES_set_key_unchecked() function.
 
-des_set_key_checked() will check that the key passed is of odd parity
+DES_set_key_checked() will check that the key passed is of odd parity
 and is not a week or semi-weak key.  If the parity is wrong, then -1
 is returned.  If the key is a weak key, then -2 is returned.  If an
 error is returned, the key schedule is not generated.
 
-des_set_key() (called des_key_sched() in the MIT library) works like
-des_set_key_checked() if the I<des_check_key> flag is non-zero,
-otherwise like des_set_key_unchecked().  These functions are available
+DES_set_key() works like
+DES_set_key_checked() if the I<DES_check_key> flag is non-zero,
+otherwise like DES_set_key_unchecked().  These functions are available
 for compatibility; it is recommended to use a function that does not
 depend on a global variable.
 
-des_set_odd_parity() (called des_fixup_key_parity() in the MIT
-library) sets the parity of the passed I<key> to odd.
+DES_set_odd_parity() sets the parity of the passed I<key> to odd.
 
-des_is_weak_key() returns 1 is the passed key is a weak key, 0 if it
+DES_is_weak_key() returns 1 is the passed key is a weak key, 0 if it
 is ok.  The probability that a randomly generated key is weak is
 1/2^52, so it is not really worth checking for them.
 
 The following routines mostly operate on an input and output stream of
-I<des_cblock>s.
+I<DES_cblock>s.
 
-des_ecb_encrypt() is the basic DES encryption routine that encrypts or
-decrypts a single 8-byte I<des_cblock> in I<electronic code book>
+DES_ecb_encrypt() is the basic DES encryption routine that encrypts or
+decrypts a single 8-byte I<DES_cblock> in I<electronic code book>
 (ECB) mode.  It always transforms the input data, pointed to by
 I<input>, into the output data, pointed to by the I<output> argument.
 If the I<encrypt> argument is non-zero (DES_ENCRYPT), the I<input>
 (cleartext) is encrypted in to the I<output> (ciphertext) using the
 key_schedule specified by the I<schedule> argument, previously set via
-I<des_set_key>. If I<encrypt> is zero (DES_DECRYPT), the I<input> (now
+I<DES_set_key>. If I<encrypt> is zero (DES_DECRYPT), the I<input> (now
 ciphertext) is decrypted into the I<output> (now cleartext).  Input
-and output may overlap.  des_ecb_encrypt() does not return a value.
+and output may overlap.  DES_ecb_encrypt() does not return a value.
 
-des_ecb3_encrypt() encrypts/decrypts the I<input> block by using
+DES_ecb3_encrypt() encrypts/decrypts the I<input> block by using
 three-key Triple-DES encryption in ECB mode.  This involves encrypting
 the input with I<ks1>, decrypting with the key schedule I<ks2>, and
 then encrypting with I<ks3>.  This routine greatly reduces the chances
@@ -173,10 +161,10 @@ of brute force breaking of DES and has the advantage of if I<ks1>,
 I<ks2> and I<ks3> are the same, it is equivalent to just encryption
 using ECB mode and I<ks1> as the key.
 
-The macro des_ecb2_encrypt() is provided to perform two-key Triple-DES
+The macro DES_ecb2_encrypt() is provided to perform two-key Triple-DES
 encryption by using I<ks1> for the final encryption.
 
-des_ncbc_encrypt() encrypts/decrypts using the I<cipher-block-chaining>
+DES_ncbc_encrypt() encrypts/decrypts using the I<cipher-block-chaining>
 (CBC) mode of DES.  If the I<encrypt> argument is non-zero, the
 routine cipher-block-chain encrypts the cleartext data pointed to by
 the I<input> argument into the ciphertext pointed to by the I<output>
@@ -186,24 +174,24 @@ I<length> argument is not an integral multiple of eight bytes, the
 last block is copied to a temporary area and zero filled.  The output
 is always an integral multiple of eight bytes.
 
-des_xcbc_encrypt() is RSA's DESX mode of DES.  It uses I<inw> and
+DES_xcbc_encrypt() is RSA's DESX mode of DES.  It uses I<inw> and
 I<outw> to 'whiten' the encryption.  I<inw> and I<outw> are secret
 (unlike the iv) and are as such, part of the key.  So the key is sort
 of 24 bytes.  This is much better than CBC DES.
 
-des_ede3_cbc_encrypt() implements outer triple CBC DES encryption with
+DES_ede3_cbc_encrypt() implements outer triple CBC DES encryption with
 three keys. This means that each DES operation inside the CBC mode is
 really an C<C=E(ks3,D(ks2,E(ks1,M)))>.  This mode is used by SSL.
 
-The des_ede2_cbc_encrypt() macro implements two-key Triple-DES by
+The DES_ede2_cbc_encrypt() macro implements two-key Triple-DES by
 reusing I<ks1> for the final encryption.  C<C=E(ks1,D(ks2,E(ks1,M)))>.
 This form of Triple-DES is used by the RSAREF library.
 
-des_pcbc_encrypt() encrypt/decrypts using the propagating cipher block
+DES_pcbc_encrypt() encrypt/decrypts using the propagating cipher block
 chaining mode used by Kerberos v4. Its parameters are the same as
-des_ncbc_encrypt().
+DES_ncbc_encrypt().
 
-des_cfb_encrypt() encrypt/decrypts using cipher feedback mode.  This
+DES_cfb_encrypt() encrypt/decrypts using cipher feedback mode.  This
 method takes an array of characters as input and outputs and array of
 characters.  It does not require any padding to 8 character groups.
 Note: the I<ivec> variable is changed and the new changed value needs to
@@ -211,7 +199,7 @@ be passed to the next call to this function.  Since this function runs
 a complete DES ECB encryption per I<numbits>, this function is only
 suggested for use when sending small numbers of characters.
 
-des_cfb64_encrypt()
+DES_cfb64_encrypt()
 implements CFB mode of DES with 64bit feedback.  Why is this
 useful you ask?  Because this routine will allow you to encrypt an
 arbitrary number of bytes, no 8 byte padding.  Each call to this
@@ -219,10 +207,10 @@ routine will encrypt the input bytes to output and then update ivec
 and num.  num contains 'how far' we are though ivec.  If this does
 not make much sense, read more about cfb mode of DES :-).
 
-des_ede3_cfb64_encrypt() and des_ede2_cfb64_encrypt() is the same as
-des_cfb64_encrypt() except that Triple-DES is used.
+DES_ede3_cfb64_encrypt() and DES_ede2_cfb64_encrypt() is the same as
+DES_cfb64_encrypt() except that Triple-DES is used.
 
-des_ofb_encrypt() encrypts using output feedback mode.  This method
+DES_ofb_encrypt() encrypts using output feedback mode.  This method
 takes an array of characters as input and outputs and array of
 characters.  It does not require any padding to 8 character groups.
 Note: the I<ivec> variable is changed and the new changed value needs to
@@ -230,39 +218,22 @@ be passed to the next call to this function.  Since this function runs
 a complete DES ECB encryption per numbits, this function is only
 suggested for use when sending small numbers of characters.
 
-des_ofb64_encrypt() is the same as des_cfb64_encrypt() using Output
+DES_ofb64_encrypt() is the same as DES_cfb64_encrypt() using Output
 Feed Back mode.
 
-des_ede3_ofb64_encrypt() and des_ede2_ofb64_encrypt() is the same as
-des_ofb64_encrypt(), using Triple-DES.
+DES_ede3_ofb64_encrypt() and DES_ede2_ofb64_encrypt() is the same as
+DES_ofb64_encrypt(), using Triple-DES.
 
 The following functions are included in the DES library for
-compatibility with the MIT Kerberos library. des_read_pw_string()
-is also available under the name EVP_read_pw_string().
-
-des_read_pw_string() writes the string specified by I<prompt> to
-standard output, turns echo off and reads in input string from the
-terminal.  The string is returned in I<buf>, which must have space for
-at least I<length> bytes.  If I<verify> is set, the user is asked for
-the password twice and unless the two copies match, an error is
-returned.  A return code of -1 indicates a system error, 1 failure due
-to use interaction, and 0 is success.
-
-des_read_password() does the same and converts the password to a DES
-key by calling des_string_to_key(); des_read_2password() operates in
-the same way as des_read_password() except that it generates two keys
-by using the des_string_to_2key() function.  des_string_to_key() is
-available for backward compatibility with the MIT library.  New
-applications should use a cryptographic hash function.  The same
-applies for des_string_to_2key().
-
-des_cbc_cksum() produces an 8 byte checksum based on the input stream
+compatibility with the MIT Kerberos library.
+
+DES_cbc_cksum() produces an 8 byte checksum based on the input stream
 (via CBC encryption).  The last 4 bytes of the checksum are returned
 and the complete 8 bytes are placed in I<output>. This function is
 used by Kerberos v4.  Other applications should use
 L<EVP_DigestInit(3)|EVP_DigestInit(3)> etc. instead.
 
-des_quad_cksum() is a Kerberos v4 function.  It returns a 4 byte
+DES_quad_cksum() is a Kerberos v4 function.  It returns a 4 byte
 checksum from the input bytes.  The algorithm can be iterated over the
 input, depending on I<out_count>, 1, 2, 3 or 4 times.  If I<output> is
 non-NULL, the 8 bytes generated by each pass are written into
@@ -270,19 +241,19 @@ I<output>.
 
 The following are DES-based transformations:
 
-des_fcrypt() is a fast version of the Unix crypt(3) function.  This
+DES_fcrypt() is a fast version of the Unix crypt(3) function.  This
 version takes only a small amount of space relative to other fast
 crypt() implementations.  This is different to the normal crypt in
 that the third parameter is the buffer that the return value is
 written into.  It needs to be at least 14 bytes long.  This function
 is thread safe, unlike the normal crypt.
 
-des_crypt() is a faster replacement for the normal system crypt().
-This function calls des_fcrypt() with a static array passed as the
+DES_crypt() is a faster replacement for the normal system crypt().
+This function calls DES_fcrypt() with a static array passed as the
 third parameter.  This emulates the normal non-thread safe semantics
 of crypt(3).
 
-des_enc_write() writes I<len> bytes to file descriptor I<fd> from
+DES_enc_write() writes I<len> bytes to file descriptor I<fd> from
 buffer I<buf>. The data is encrypted via I<pcbc_encrypt> (default)
 using I<sched> for the key and I<iv> as a starting vector.  The actual
 data send down I<fd> consists of 4 bytes (in network byte order)
@@ -290,40 +261,40 @@ containing the length of the following encrypted data.  The encrypted
 data then follows, padded with random data out to a multiple of 8
 bytes.
 
-des_enc_read() is used to read I<len> bytes from file descriptor
+DES_enc_read() is used to read I<len> bytes from file descriptor
 I<fd> into buffer I<buf>. The data being read from I<fd> is assumed to
-have come from des_enc_write() and is decrypted using I<sched> for
+have come from DES_enc_write() and is decrypted using I<sched> for
 the key schedule and I<iv> for the initial vector.
 
-B<Warning:> The data format used by des_enc_write() and des_enc_read()
+B<Warning:> The data format used by DES_enc_write() and DES_enc_read()
 has a cryptographic weakness: When asked to write more than MAXWRITE
-bytes, des_enc_write() will split the data into several chunks that
+bytes, DES_enc_write() will split the data into several chunks that
 are all encrypted using the same IV.  So don't use these functions
 unless you are sure you know what you do (in which case you might not
 want to use them anyway).  They cannot handle non-blocking sockets.
-des_enc_read() uses an internal state and thus cannot be used on
+DES_enc_read() uses an internal state and thus cannot be used on
 multiple files.
 
-I<des_rw_mode> is used to specify the encryption mode to use with
-des_enc_read() and des_end_write().  If set to I<DES_PCBC_MODE> (the
-default), des_pcbc_encrypt is used.  If set to I<DES_CBC_MODE>
-des_cbc_encrypt is used.
+I<DES_rw_mode> is used to specify the encryption mode to use with
+DES_enc_read() and DES_end_write().  If set to I<DES_PCBC_MODE> (the
+default), DES_pcbc_encrypt is used.  If set to I<DES_CBC_MODE>
+DES_cbc_encrypt is used.
 
 =head1 NOTES
 
 Single-key DES is insecure due to its short key size.  ECB mode is
-not suitable for most applications; see L<des_modes(7)|des_modes(7)>.
+not suitable for most applications; see L<DES_modes(7)|DES_modes(7)>.
 
 The L<evp(3)|evp(3)> library provides higher-level encryption functions.
 
 =head1 BUGS
 
-des_3cbc_encrypt() is flawed and must not be used in applications.
+DES_3cbc_encrypt() is flawed and must not be used in applications.
 
-des_cbc_encrypt() does not modify B<ivec>; use des_ncbc_encrypt()
+DES_cbc_encrypt() does not modify B<ivec>; use DES_ncbc_encrypt()
 instead.
 
-des_cfb_encrypt() and des_ofb_encrypt() operates on input of 8 bits.
+DES_cfb_encrypt() and DES_ofb_encrypt() operates on input of 8 bits.
 What this means is that if you set numbits to 12, and length to 2, the
 first 12 bits will come from the 1st input byte and the low half of
 the second input byte.  The second 12 bits will have the low 8 bits
@@ -333,8 +304,9 @@ implemented this way because most people will be using a multiple of 8
 and because once you get into pulling bytes input bytes apart things
 get ugly!
 
-des_read_pw_string() is the most machine/OS dependent function and
-normally generates the most problems when porting this code.
+DES_string_to_key() is available for backward compatibility with the
+MIT library.  New applications should use a cryptographic hash function.
+The same applies for DES_string_to_2key().
 
 =head1 CONFORMING TO
 
@@ -349,10 +321,20 @@ crypt(3), L<des_modes(7)|des_modes(7)>, L<evp(3)|evp(3)>, L<rand(3)|rand(3)>
 
 =head1 HISTORY
 
+In OpenSSL 0.9.7, all des_ functions were renamed to DES_ to avoid
+clashes with older versions of libdes.  Compatibility des_ functions
+are provided for a short while, as well as crypt().
+Declarations for these are in <openssl/des_old.h>. There is no DES_
+variant for des_random_seed().
+This will happen to other functions
+as well if they are deemed redundant (des_random_seed() just calls
+RAND_seed() and is present for backward compatibility only), buggy or
+already scheduled for removal.
+
 des_cbc_cksum(), des_cbc_encrypt(), des_ecb_encrypt(),
 des_is_weak_key(), des_key_sched(), des_pcbc_encrypt(),
-des_quad_cksum(), des_random_key(), des_read_password() and
-des_string_to_key() are available in the MIT Kerberos library;
+des_quad_cksum(), des_random_key() and des_string_to_key()
+are available in the MIT Kerberos library;
 des_check_key_parity(), des_fixup_key_parity() and des_is_weak_key()
 are available in newer versions of that library.
 
diff --git a/src/lib/libssl/src/doc/crypto/hmac.pod b/src/lib/libssl/src/doc/crypto/hmac.pod
index 631f40377e..3cc29dfc83 100644
--- a/src/lib/libssl/src/doc/crypto/hmac.pod
+++ b/src/lib/libssl/src/doc/crypto/hmac.pod
@@ -13,11 +13,16 @@ authentication code
                int key_len, const unsigned char *d, int n,
                unsigned char *md, unsigned int *md_len);
 
+ void HMAC_CTX_init(HMAC_CTX *ctx);
+
  void HMAC_Init(HMAC_CTX *ctx, const void *key, int key_len,
                const EVP_MD *md);
+ void HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int key_len,
+                   const EVP_MD *md);
  void HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, int len);
  void HMAC_Final(HMAC_CTX *ctx, unsigned char *md, unsigned int *len);
 
+ void HMAC_CTX_cleanup(HMAC_CTX *ctx);
  void HMAC_cleanup(HMAC_CTX *ctx);
 
 =head1 DESCRIPTION
@@ -39,13 +44,31 @@ B<evp_md> can be EVP_sha1(), EVP_ripemd160() etc.
 B<key> and B<evp_md> may be B<NULL> if a key and hash function have
 been set in a previous call to HMAC_Init() for that B<HMAC_CTX>.
 
-HMAC_cleanup() erases the key and other data from the B<HMAC_CTX>.
+HMAC_CTX_init() initialises a B<HMAC_CTX> before first use. It must be
+called.
+
+HMAC_CTX_cleanup() erases the key and other data from the B<HMAC_CTX>
+and releases any associated resources. It must be called when an
+B<HMAC_CTX> is no longer required.
+
+HMAC_cleanup() is an alias for HMAC_CTX_cleanup() included for back
+compatibility with 0.9.6b, it is deprecated.
 
 The following functions may be used if the message is not completely
 stored in memory:
 
 HMAC_Init() initializes a B<HMAC_CTX> structure to use the hash
-function B<evp_md> and the key B<key> which is B<key_len> bytes long.
+function B<evp_md> and the key B<key> which is B<key_len> bytes
+long. It is deprecated and only included for backward compatibility
+with OpenSSL 0.9.6b.
+
+HMAC_Init_ex() initializes or reuses a B<HMAC_CTX> structure to use
+the function B<evp_md> and key B<key>. Either can be NULL, in which
+case the existing one will be reused. HMAC_CTX_init() must have been
+called before the first use of an B<HMAC_CTX> in this
+function. B<N.B. HMAC_Init() had this undocumented behaviour in
+previous versions of OpenSSL - failure to switch to HMAC_Init_ex() in
+programs that expect it will cause them to stop working>.
 
 HMAC_Update() can be called repeatedly with chunks of the message to
 be authenticated (B<len> bytes at B<data>).
@@ -57,8 +80,8 @@ must have space for the hash function output.
 
 HMAC() returns a pointer to the message authentication code.
 
-HMAC_Init(), HMAC_Update(), HMAC_Final() and HMAC_cleanup() do not
-return values.
+HMAC_CTX_init(), HMAC_Init_ex(), HMAC_Update(), HMAC_Final() and
+HMAC_CTX_cleanup() do not return values.
 
 =head1 CONFORMING TO
 
diff --git a/src/lib/libssl/src/doc/crypto/lhash.pod b/src/lib/libssl/src/doc/crypto/lhash.pod
index 4e87aee824..0bac11421e 100644
--- a/src/lib/libssl/src/doc/crypto/lhash.pod
+++ b/src/lib/libssl/src/doc/crypto/lhash.pod
@@ -2,43 +2,108 @@
 
 =head1 NAME
 
-lh_new, lh_free, lh_insert, lh_delete, lh_retrieve, lh_doall,
-lh_doall_arg, lh_error - dynamic hash table
+lh_new, lh_free, lh_insert, lh_delete, lh_retrieve, lh_doall, lh_doall_arg, lh_error - dynamic hash table
 
 =head1 SYNOPSIS
 
  #include <openssl/lhash.h>
 
- LHASH *lh_new(unsigned long (*hash)(/*void *a*/),
-          int (*compare)(/*void *a,void *b*/));
+ LHASH *lh_new(LHASH_HASH_FN_TYPE hash, LHASH_COMP_FN_TYPE compare);
  void lh_free(LHASH *table);
 
  void *lh_insert(LHASH *table, void *data);
  void *lh_delete(LHASH *table, void *data);
  void *lh_retrieve(LHASH *table, void *data);
 
- void lh_doall(LHASH *table, void (*func)(/*void *b*/));
- void lh_doall_arg(LHASH *table, void (*func)(/*void *a,void *b*/),
+ void lh_doall(LHASH *table, LHASH_DOALL_FN_TYPE func);
+ void lh_doall_arg(LHASH *table, LHASH_DOALL_ARG_FN_TYPE func,
           void *arg);
 
  int lh_error(LHASH *table);
 
+ typedef int (*LHASH_COMP_FN_TYPE)(const void *, const void *);
+ typedef unsigned long (*LHASH_HASH_FN_TYPE)(const void *);
+ typedef void (*LHASH_DOALL_FN_TYPE)(const void *);
+ typedef void (*LHASH_DOALL_ARG_FN_TYPE)(const void *, const void *);
+
 =head1 DESCRIPTION
 
 This library implements dynamic hash tables. The hash table entries
 can be arbitrary structures. Usually they consist of key and value
 fields.
 
-lh_new() creates a new B<LHASH> structure. B<hash> takes a pointer to
-the structure and returns an unsigned long hash value of its key
-field. The hash value is normally truncated to a power of 2, so make
-sure that your hash function returns well mixed low order
-bits. B<compare> takes two arguments, and returns 0 if their keys are
-equal, non-zero otherwise.
+lh_new() creates a new B<LHASH> structure to store arbitrary data
+entries, and provides the 'hash' and 'compare' callbacks to be used in
+organising the table's entries.  The B<hash> callback takes a pointer
+to a table entry as its argument and returns an unsigned long hash
+value for its key field.  The hash value is normally truncated to a
+power of 2, so make sure that your hash function returns well mixed
+low order bits.  The B<compare> callback takes two arguments (pointers
+to two hash table entries), and returns 0 if their keys are equal,
+non-zero otherwise.  If your hash table will contain items of some
+particular type and the B<hash> and B<compare> callbacks hash/compare
+these types, then the B<DECLARE_LHASH_HASH_FN> and
+B<IMPLEMENT_LHASH_COMP_FN> macros can be used to create callback
+wrappers of the prototypes required by lh_new().  These provide
+per-variable casts before calling the type-specific callbacks written
+by the application author.  These macros, as well as those used for
+the "doall" callbacks, are defined as;
+
+ #define DECLARE_LHASH_HASH_FN(f_name,o_type) \
+         unsigned long f_name##_LHASH_HASH(const void *);
+ #define IMPLEMENT_LHASH_HASH_FN(f_name,o_type) \
+         unsigned long f_name##_LHASH_HASH(const void *arg) { \
+                 o_type a = (o_type)arg; \
+                 return f_name(a); }
+ #define LHASH_HASH_FN(f_name) f_name##_LHASH_HASH
+
+ #define DECLARE_LHASH_COMP_FN(f_name,o_type) \
+         int f_name##_LHASH_COMP(const void *, const void *);
+ #define IMPLEMENT_LHASH_COMP_FN(f_name,o_type) \
+         int f_name##_LHASH_COMP(const void *arg1, const void *arg2) { \
+                 o_type a = (o_type)arg1; \
+                 o_type b = (o_type)arg2; \
+                 return f_name(a,b); }
+ #define LHASH_COMP_FN(f_name) f_name##_LHASH_COMP
+
+ #define DECLARE_LHASH_DOALL_FN(f_name,o_type) \
+         void f_name##_LHASH_DOALL(const void *);
+ #define IMPLEMENT_LHASH_DOALL_FN(f_name,o_type) \
+         void f_name##_LHASH_DOALL(const void *arg) { \
+                 o_type a = (o_type)arg; \
+                 f_name(a); }
+ #define LHASH_DOALL_FN(f_name) f_name##_LHASH_DOALL
+
+ #define DECLARE_LHASH_DOALL_ARG_FN(f_name,o_type,a_type) \
+         void f_name##_LHASH_DOALL_ARG(const void *, const void *);
+ #define IMPLEMENT_LHASH_DOALL_ARG_FN(f_name,o_type,a_type) \
+         void f_name##_LHASH_DOALL_ARG(const void *arg1, const void *arg2) { \
+                 o_type a = (o_type)arg1; \
+                 a_type b = (a_type)arg2; \
+                 f_name(a,b); }
+ #define LHASH_DOALL_ARG_FN(f_name) f_name##_LHASH_DOALL_ARG
+
+An example of a hash table storing (pointers to) structures of type 'STUFF'
+could be defined as follows;
+
+ /* Calculates the hash value of 'tohash' (implemented elsewhere) */
+ unsigned long STUFF_hash(const STUFF *tohash);
+ /* Orders 'arg1' and 'arg2' (implemented elsewhere) */
+ int STUFF_cmp(const STUFF *arg1, const STUFF *arg2);
+ /* Create the type-safe wrapper functions for use in the LHASH internals */
+ static IMPLEMENT_LHASH_HASH_FN(STUFF_hash, const STUFF *)
+ static IMPLEMENT_LHASH_COMP_FN(STUFF_cmp, const STUFF *);
+ /* ... */
+ int main(int argc, char *argv[]) {
+         /* Create the new hash table using the hash/compare wrappers */
+         LHASH *hashtable = lh_new(LHASH_HASH_FN(STUFF_hash),
+                                   LHASH_COMP_FN(STUFF_cmp));
+         /* ... */
+ }
 
 lh_free() frees the B<LHASH> structure B<table>. Allocated hash table
 entries will not be freed; consider using lh_doall() to deallocate any
-remaining entries in the hash table.
+remaining entries in the hash table (see below).
 
 lh_insert() inserts the structure pointed to by B<data> into B<table>.
 If there already is an entry with the same key, the old value is
@@ -52,23 +117,53 @@ a structure with the key field(s) set; the function will return a
 pointer to a fully populated structure.
 
 lh_doall() will, for every entry in the hash table, call B<func> with
-the data item as parameters.
-This function can be quite useful when used as follows:
- void cleanup(STUFF *a)
-  { STUFF_free(a); }
- lh_doall(hash,cleanup);
- lh_free(hash);
-This can be used to free all the entries. lh_free() then cleans up the
-'buckets' that point to nothing. When doing this, be careful if you
-delete entries from the hash table in B<func>: the table may decrease
-in size, moving item that you are currently on down lower in the hash
-table.  This could cause some entries to be skipped.  The best
-solution to this problem is to set hash-E<gt>down_load=0 before you
-start.  This will stop the hash table ever being decreased in size.
-
-lh_doall_arg() is the same as lh_doall() except that B<func> will
-be called with B<arg> as the second argument.
-
+the data item as its parameter.  For lh_doall() and lh_doall_arg(),
+function pointer casting should be avoided in the callbacks (see
+B<NOTE>) - instead, either declare the callbacks to match the
+prototype required in lh_new() or use the declare/implement macros to
+create type-safe wrappers that cast variables prior to calling your
+type-specific callbacks.  An example of this is illustrated here where
+the callback is used to cleanup resources for items in the hash table
+prior to the hashtable itself being deallocated:
+
+ /* Cleans up resources belonging to 'a' (this is implemented elsewhere) */
+ void STUFF_cleanup(STUFF *a);
+ /* Implement a prototype-compatible wrapper for "STUFF_cleanup" */
+ IMPLEMENT_LHASH_DOALL_FN(STUFF_cleanup, STUFF *)
+         /* ... then later in the code ... */
+ /* So to run "STUFF_cleanup" against all items in a hash table ... */
+ lh_doall(hashtable, LHASH_DOALL_FN(STUFF_cleanup));
+ /* Then the hash table itself can be deallocated */
+ lh_free(hashtable);
+
+When doing this, be careful if you delete entries from the hash table
+in your callbacks: the table may decrease in size, moving the item
+that you are currently on down lower in the hash table - this could
+cause some entries to be skipped during the iteration.  The second
+best solution to this problem is to set hash-E<gt>down_load=0 before
+you start (which will stop the hash table ever decreasing in size).
+The best solution is probably to avoid deleting items from the hash
+table inside a "doall" callback!
+
+lh_doall_arg() is the same as lh_doall() except that B<func> will be
+called with B<arg> as the second argument and B<func> should be of
+type B<LHASH_DOALL_ARG_FN_TYPE> (a callback prototype that is passed
+both the table entry and an extra argument).  As with lh_doall(), you
+can instead choose to declare your callback with a prototype matching
+the types you are dealing with and use the declare/implement macros to
+create compatible wrappers that cast variables before calling your
+type-specific callbacks.  An example of this is demonstrated here
+(printing all hash table entries to a BIO that is provided by the
+caller):
+
+ /* Prints item 'a' to 'output_bio' (this is implemented elsewhere) */
+ void STUFF_print(const STUFF *a, BIO *output_bio);
+ /* Implement a prototype-compatible wrapper for "STUFF_print" */
+ static IMPLEMENT_LHASH_DOALL_ARG_FN(STUFF_print, const STUFF *, BIO *)
+         /* ... then later in the code ... */
+ /* Print out the entire hashtable to a particular BIO */
+ lh_doall_arg(hashtable, LHASH_DOALL_ARG_FN(STUFF_print), logging_bio);
+ 
 lh_error() can be used to determine if an error occurred in the last
 operation. lh_error() is a macro.
 
@@ -91,6 +186,45 @@ otherwise.
 
 lh_free(), lh_doall() and lh_doall_arg() return no values.
 
+=head1 NOTE
+
+The various LHASH macros and callback types exist to make it possible
+to write type-safe code without resorting to function-prototype
+casting - an evil that makes application code much harder to
+audit/verify and also opens the window of opportunity for stack
+corruption and other hard-to-find bugs.  It also, apparently, violates
+ANSI-C.
+
+The LHASH code regards table entries as constant data.  As such, it
+internally represents lh_insert()'d items with a "const void *"
+pointer type.  This is why callbacks such as those used by lh_doall()
+and lh_doall_arg() declare their prototypes with "const", even for the
+parameters that pass back the table items' data pointers - for
+consistency, user-provided data is "const" at all times as far as the
+LHASH code is concerned.  However, as callers are themselves providing
+these pointers, they can choose whether they too should be treating
+all such parameters as constant.
+
+As an example, a hash table may be maintained by code that, for
+reasons of encapsulation, has only "const" access to the data being
+indexed in the hash table (ie. it is returned as "const" from
+elsewhere in their code) - in this case the LHASH prototypes are
+appropriate as-is.  Conversely, if the caller is responsible for the
+life-time of the data in question, then they may well wish to make
+modifications to table item passed back in the lh_doall() or
+lh_doall_arg() callbacks (see the "STUFF_cleanup" example above).  If
+so, the caller can either cast the "const" away (if they're providing
+the raw callbacks themselves) or use the macros to declare/implement
+the wrapper functions without "const" types.
+
+Callers that only have "const" access to data they're indexing in a
+table, yet declare callbacks without constant types (or cast the
+"const" away themselves), are therefore creating their own risks/bugs
+without being encouraged to do so by the API.  On a related note,
+those auditing code should pay special attention to any instances of
+DECLARE/IMPLEMENT_LHASH_DOALL_[ARG_]_FN macros that provide types
+without any "const" qualifiers.
+
 =head1 BUGS
 
 lh_insert() returns B<NULL> both for success and error.
@@ -131,7 +265,7 @@ generating hashes that are the same for different values.  It is
 probably worth changing your hash function if this is the case because
 even if your hash table has 10 items in a 'bucket', it can be searched
 with 10 B<unsigned long> compares and 10 linked list traverses.  This
-will be much less expensive that 10 calls to you compare function.
+will be much less expensive that 10 calls to your compare function.
 
 lh_strhash() is a demo string hashing function:
 
diff --git a/src/lib/libssl/src/doc/crypto/pem.pod b/src/lib/libssl/src/doc/crypto/pem.pod
new file mode 100644
index 0000000000..a4f8cc3337
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/pem.pod
@@ -0,0 +1,476 @@
+=pod
+
+=head1 NAME
+
+PEM - PEM routines
+
+=head1 SYNOPSIS
+
+ #include <openssl/pem.h>
+
+ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY **x,
+                                        pem_password_cb *cb, void *u);
+
+ EVP_PKEY *PEM_read_PrivateKey(FILE *fp, EVP_PKEY **x,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PrivateKey(BIO *bp, EVP_PKEY *x, const EVP_CIPHER *enc,
+                                        unsigned char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_PrivateKey(FILE *fp, EVP_PKEY *x, const EVP_CIPHER *enc,
+                                        unsigned char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PKCS8PrivateKey(BIO *bp, EVP_PKEY *x, const EVP_CIPHER *enc,
+                                        char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_PKCS8PrivateKey(FILE *fp, EVP_PKEY *x, const EVP_CIPHER *enc,
+                                        char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PKCS8PrivateKey_nid(BIO *bp, EVP_PKEY *x, int nid,
+                                        char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_PKCS8PrivateKey_nid(FILE *fp, EVP_PKEY *x, int nid,
+                                        char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ EVP_PKEY *PEM_read_bio_PUBKEY(BIO *bp, EVP_PKEY **x,
+                                        pem_password_cb *cb, void *u);
+
+ EVP_PKEY *PEM_read_PUBKEY(FILE *fp, EVP_PKEY **x,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PUBKEY(BIO *bp, EVP_PKEY *x);
+ int PEM_write_PUBKEY(FILE *fp, EVP_PKEY *x);
+
+ RSA *PEM_read_bio_RSAPrivateKey(BIO *bp, RSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ RSA *PEM_read_RSAPrivateKey(FILE *fp, RSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_RSAPrivateKey(BIO *bp, RSA *x, const EVP_CIPHER *enc,
+                                        unsigned char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_RSAPrivateKey(FILE *fp, RSA *x, const EVP_CIPHER *enc,
+                                        unsigned char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ RSA *PEM_read_bio_RSAPublicKey(BIO *bp, RSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ RSA *PEM_read_RSAPublicKey(FILE *fp, RSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_RSAPublicKey(BIO *bp, RSA *x);
+
+ int PEM_write_RSAPublicKey(FILE *fp, RSA *x);
+
+ RSA *PEM_read_bio_RSA_PUBKEY(BIO *bp, RSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ RSA *PEM_read_RSA_PUBKEY(FILE *fp, RSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_RSA_PUBKEY(BIO *bp, RSA *x);
+
+ int PEM_write_RSA_PUBKEY(FILE *fp, RSA *x);
+
+ DSA *PEM_read_bio_DSAPrivateKey(BIO *bp, DSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ DSA *PEM_read_DSAPrivateKey(FILE *fp, DSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_DSAPrivateKey(BIO *bp, DSA *x, const EVP_CIPHER *enc,
+                                        unsigned char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_DSAPrivateKey(FILE *fp, DSA *x, const EVP_CIPHER *enc,
+                                        unsigned char *kstr, int klen,
+                                        pem_password_cb *cb, void *u);
+
+ DSA *PEM_read_bio_DSA_PUBKEY(BIO *bp, DSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ DSA *PEM_read_DSA_PUBKEY(FILE *fp, DSA **x,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_DSA_PUBKEY(BIO *bp, DSA *x);
+
+ int PEM_write_DSA_PUBKEY(FILE *fp, DSA *x);
+
+ DSA *PEM_read_bio_DSAparams(BIO *bp, DSA **x, pem_password_cb *cb, void *u);
+
+ DSA *PEM_read_DSAparams(FILE *fp, DSA **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_DSAparams(BIO *bp, DSA *x);
+
+ int PEM_write_DSAparams(FILE *fp, DSA *x);
+
+ DH *PEM_read_bio_DHparams(BIO *bp, DH **x, pem_password_cb *cb, void *u);
+
+ DH *PEM_read_DHparams(FILE *fp, DH **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_DHparams(BIO *bp, DH *x);
+
+ int PEM_write_DHparams(FILE *fp, DH *x);
+
+ X509 *PEM_read_bio_X509(BIO *bp, X509 **x, pem_password_cb *cb, void *u);
+
+ X509 *PEM_read_X509(FILE *fp, X509 **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_X509(BIO *bp, X509 *x);
+
+ int PEM_write_X509(FILE *fp, X509 *x);
+
+ X509 *PEM_read_bio_X509_AUX(BIO *bp, X509 **x, pem_password_cb *cb, void *u);
+
+ X509 *PEM_read_X509_AUX(FILE *fp, X509 **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_X509_AUX(BIO *bp, X509 *x);
+
+ int PEM_write_X509_AUX(FILE *fp, X509 *x);
+
+ X509_REQ *PEM_read_bio_X509_REQ(BIO *bp, X509_REQ **x,
+                                        pem_password_cb *cb, void *u);
+
+ X509_REQ *PEM_read_X509_REQ(FILE *fp, X509_REQ **x,
+                                        pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_X509_REQ(BIO *bp, X509_REQ *x);
+
+ int PEM_write_X509_REQ(FILE *fp, X509_REQ *x);
+
+ int PEM_write_bio_X509_REQ_NEW(BIO *bp, X509_REQ *x);
+
+ int PEM_write_X509_REQ_NEW(FILE *fp, X509_REQ *x);
+
+ X509_CRL *PEM_read_bio_X509_CRL(BIO *bp, X509_CRL **x,
+                                        pem_password_cb *cb, void *u);
+ X509_CRL *PEM_read_X509_CRL(FILE *fp, X509_CRL **x,
+                                        pem_password_cb *cb, void *u);
+ int PEM_write_bio_X509_CRL(BIO *bp, X509_CRL *x);
+ int PEM_write_X509_CRL(FILE *fp, X509_CRL *x);
+
+ PKCS7 *PEM_read_bio_PKCS7(BIO *bp, PKCS7 **x, pem_password_cb *cb, void *u);
+
+ PKCS7 *PEM_read_PKCS7(FILE *fp, PKCS7 **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PKCS7(BIO *bp, PKCS7 *x);
+
+ int PEM_write_PKCS7(FILE *fp, PKCS7 *x);
+
+ NETSCAPE_CERT_SEQUENCE *PEM_read_bio_NETSCAPE_CERT_SEQUENCE(BIO *bp,
+                                                NETSCAPE_CERT_SEQUENCE **x,
+                                                pem_password_cb *cb, void *u);
+
+ NETSCAPE_CERT_SEQUENCE *PEM_read_NETSCAPE_CERT_SEQUENCE(FILE *fp,
+                                                NETSCAPE_CERT_SEQUENCE **x,
+                                                pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_NETSCAPE_CERT_SEQUENCE(BIO *bp, NETSCAPE_CERT_SEQUENCE *x);
+
+ int PEM_write_NETSCAPE_CERT_SEQUENCE(FILE *fp, NETSCAPE_CERT_SEQUENCE *x);
+
+=head1 DESCRIPTION
+
+The PEM functions read or write structures in PEM format. In
+this sense PEM format is simply base64 encoded data surrounded
+by header lines.
+
+For more details about the meaning of arguments see the
+B<PEM FUNCTION ARGUMENTS> section.
+
+Each operation has four functions associated with it. For
+clarity the term "B<foobar> functions" will be used to collectively
+refer to the PEM_read_bio_foobar(), PEM_read_foobar(),
+PEM_write_bio_foobar() and PEM_write_foobar() functions.
+
+The B<PrivateKey> functions read or write a private key in
+PEM format using an EVP_PKEY structure. The write routines use
+"traditional" private key format and can handle both RSA and DSA
+private keys. The read functions can additionally transparently
+handle PKCS#8 format encrypted and unencrypted keys too.
+
+PEM_write_bio_PKCS8PrivateKey() and PEM_write_PKCS8PrivateKey()
+write a private key in an EVP_PKEY structure in PKCS#8
+EncryptedPrivateKeyInfo format using PKCS#5 v2.0 password based encryption
+algorithms. The B<cipher> argument specifies the encryption algoritm to
+use: unlike all other PEM routines the encryption is applied at the
+PKCS#8 level and not in the PEM headers. If B<cipher> is NULL then no
+encryption is used and a PKCS#8 PrivateKeyInfo structure is used instead.
+
+PEM_write_bio_PKCS8PrivateKey_nid() and PEM_write_PKCS8PrivateKey_nid()
+also write out a private key as a PKCS#8 EncryptedPrivateKeyInfo however
+it uses PKCS#5 v1.5 or PKCS#12 encryption algorithms instead. The algorithm
+to use is specified in the B<nid> parameter and should be the NID of the
+corresponding OBJECT IDENTIFIER (see NOTES section).
+
+The B<PUBKEY> functions process a public key using an EVP_PKEY
+structure. The public key is encoded as a SubjectPublicKeyInfo
+structure.
+
+The B<RSAPrivateKey> functions process an RSA private key using an
+RSA structure. It handles the same formats as the B<PrivateKey>
+functions but an error occurs if the private key is not RSA.
+
+The B<RSAPublicKey> functions process an RSA public key using an
+RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey
+structure.
+
+The B<RSA_PUBKEY> functions also process an RSA public key using
+an RSA structure. However the public key is encoded using a
+SubjectPublicKeyInfo structure and an error occurs if the public
+key is not RSA.
+
+The B<DSAPrivateKey> functions process a DSA private key using a
+DSA structure. It handles the same formats as the B<PrivateKey>
+functions but an error occurs if the private key is not DSA.
+
+The B<DSA_PUBKEY> functions process a DSA public key using
+a DSA structure. The public key is encoded using a
+SubjectPublicKeyInfo structure and an error occurs if the public
+key is not DSA.
+
+The B<DSAparams> functions process DSA parameters using a DSA
+structure. The parameters are encoded using a foobar structure.
+
+The B<DHparams> functions process DH parameters using a DH
+structure. The parameters are encoded using a PKCS#3 DHparameter
+structure.
+
+The B<X509> functions process an X509 certificate using an X509
+structure. They will also process a trusted X509 certificate but
+any trust settings are discarded.
+
+The B<X509_AUX> functions process a trusted X509 certificate using
+an X509 structure. 
+
+The B<X509_REQ> and B<X509_REQ_NEW> functions process a PKCS#10
+certificate request using an X509_REQ structure. The B<X509_REQ>
+write functions use B<CERTIFICATE REQUEST> in the header whereas
+the B<X509_REQ_NEW> functions use B<NEW CERTIFICATE REQUEST>
+(as required by some CAs). The B<X509_REQ> read functions will
+handle either form so there are no B<X509_REQ_NEW> read functions.
+
+The B<X509_CRL> functions process an X509 CRL using an X509_CRL
+structure.
+
+The B<PKCS7> functions process a PKCS#7 ContentInfo using a PKCS7
+structure.
+
+The B<NETSCAPE_CERT_SEQUENCE> functions process a Netscape Certificate
+Sequence using a NETSCAPE_CERT_SEQUENCE structure.
+
+=head1 PEM FUNCTION ARGUMENTS
+
+The PEM functions have many common arguments.
+
+The B<bp> BIO parameter (if present) specifies the BIO to read from
+or write to.
+
+The B<fp> FILE parameter (if present) specifies the FILE pointer to
+read from or write to.
+
+The PEM read functions all take an argument B<TYPE **x> and return
+a B<TYPE *> pointer. Where B<TYPE> is whatever structure the function
+uses. If B<x> is NULL then the parameter is ignored. If B<x> is not
+NULL but B<*x> is NULL then the structure returned will be written
+to B<*x>. If neither B<x> nor B<*x> is NULL then an attempt is made
+to reuse the structure at B<*x> (but see BUGS and EXAMPLES sections).
+Irrespective of the value of B<x> a pointer to the structure is always
+returned (or NULL if an error occurred).
+
+The PEM functions which write private keys take an B<enc> parameter
+which specifies the encryption algorithm to use, encryption is done
+at the PEM level. If this parameter is set to NULL then the private
+key is written in unencrypted form.
+
+The B<cb> argument is the callback to use when querying for the pass
+phrase used for encrypted PEM structures (normally only private keys).
+
+For the PEM write routines if the B<kstr> parameter is not NULL then
+B<klen> bytes at B<kstr> are used as the passphrase and B<cb> is
+ignored.
+
+If the B<cb> parameters is set to NULL and the B<u> parameter is not
+NULL then the B<u> parameter is interpreted as a null terminated string
+to use as the passphrase. If both B<cb> and B<u> are NULL then the
+default callback routine is used which will typically prompt for the
+passphrase on the current terminal with echoing turned off.
+
+The default passphrase callback is sometimes inappropriate (for example
+in a GUI application) so an alternative can be supplied. The callback
+routine has the following form:
+
+ int cb(char *buf, int size, int rwflag, void *u);
+
+B<buf> is the buffer to write the passphrase to. B<size> is the maximum
+length of the passphrase (i.e. the size of buf). B<rwflag> is a flag
+which is set to 0 when reading and 1 when writing. A typical routine
+will ask the user to verify the passphrase (for example by prompting
+for it twice) if B<rwflag> is 1. The B<u> parameter has the same
+value as the B<u> parameter passed to the PEM routine. It allows
+arbitrary data to be passed to the callback by the application
+(for example a window handle in a GUI application). The callback
+B<must> return the number of characters in the passphrase or 0 if
+an error occurred.
+
+=head1 EXAMPLES
+
+Although the PEM routines take several arguments in almost all applications
+most of them are set to 0 or NULL.
+
+Read a certificate in PEM format from a BIO:
+
+ X509 *x;
+ x = PEM_read_bio(bp, NULL, 0, NULL);
+ if (x == NULL)
+        {
+        /* Error */
+        }
+
+Alternative method:
+
+ X509 *x = NULL;
+ if (!PEM_read_bio_X509(bp, &x, 0, NULL))
+        {
+        /* Error */
+        }
+
+Write a certificate to a BIO:
+
+ if (!PEM_write_bio_X509(bp, x))
+        {
+        /* Error */
+        }
+
+Write an unencrypted private key to a FILE pointer:
+
+ if (!PEM_write_PrivateKey(fp, key, NULL, NULL, 0, 0, NULL))
+        {
+        /* Error */
+        }
+
+Write a private key (using traditional format) to a BIO using
+triple DES encryption, the pass phrase is prompted for:
+
+ if (!PEM_write_bio_PrivateKey(bp, key, EVP_des_ede3_cbc(), NULL, 0, 0, NULL))
+        {
+        /* Error */
+        }
+
+Write a private key (using PKCS#8 format) to a BIO using triple
+DES encryption, using the pass phrase "hello":
+
+ if (!PEM_write_bio_PKCS8PrivateKey(bp, key, EVP_des_ede3_cbc(), NULL, 0, 0, "hello"))
+        {
+        /* Error */
+        }
+
+Read a private key from a BIO using the pass phrase "hello":
+
+ key = PEM_read_bio_PrivateKey(bp, NULL, 0, "hello");
+ if (key == NULL)
+        {
+        /* Error */
+        }
+
+Read a private key from a BIO using a pass phrase callback:
+
+ key = PEM_read_bio_PrivateKey(bp, NULL, pass_cb, "My Private Key");
+ if (key == NULL)
+        {
+        /* Error */
+        }
+
+Skeleton pass phrase callback:
+
+ int pass_cb(char *buf, int size, int rwflag, void *u);
+        {
+        int len;
+        char *tmp;
+        /* We'd probably do something else if 'rwflag' is 1 */
+        printf("Enter pass phrase for \"%s\"\n", u);
+
+        /* get pass phrase, length 'len' into 'tmp' */
+        tmp = "hello";
+        len = strlen(tmp);
+
+        if (len <= 0) return 0;
+        /* if too long, truncate */
+        if (len > size) len = size;
+        memcpy(buf, tmp, len);
+        return len;
+        }
+
+=head1 NOTES
+
+The old B<PrivateKey> write routines are retained for compatibility.
+New applications should write private keys using the
+PEM_write_bio_PKCS8PrivateKey() or PEM_write_PKCS8PrivateKey() routines
+because they are more secure (they use an iteration count of 2048 whereas
+the traditional routines use a count of 1) unless compatibility with older
+versions of OpenSSL is important.
+
+The B<PrivateKey> read routines can be used in all applications because
+they handle all formats transparently.
+
+A frequent cause of problems is attempting to use the PEM routines like
+this:
+
+ X509 *x;
+ PEM_read_bio_X509(bp, &x, 0, NULL);
+
+this is a bug because an attempt will be made to reuse the data at B<x>
+which is an uninitialised pointer.
+
+=head1 PEM ENCRYPTION FORMAT
+
+This old B<PrivateKey> routines use a non standard technique for encryption.
+
+The private key (or other data) takes the following form: 
+
+ -----BEGIN RSA PRIVATE KEY-----
+ Proc-Type: 4,ENCRYPTED
+ DEK-Info: DES-EDE3-CBC,3F17F5316E2BAC89
+
+ ...base64 encoded data...
+ -----END RSA PRIVATE KEY-----
+
+The line beginning DEK-Info contains two comma separated pieces of information:
+the encryption algorithm name as used by EVP_get_cipherbyname() and an 8
+byte B<salt> encoded as a set of hexadecimal digits.
+
+After this is the base64 encoded encrypted data.
+
+The encryption key is determined using EVP_bytestokey(), using B<salt> and an
+iteration count of 1. The IV used is the value of B<salt> and *not* the IV
+returned by EVP_bytestokey().
+
+=head1 BUGS
+
+The PEM read routines in some versions of OpenSSL will not correctly reuse
+an existing structure. Therefore the following:
+
+ PEM_read_bio(bp, &x, 0, NULL);
+
+where B<x> already contains a valid certificate, may not work, whereas: 
+
+ X509_free(x);
+ x = PEM_read_bio(bp, NULL, 0, NULL);
+
+is guaranteed to work.
+
+=head1 RETURN CODES
+
+The read routines return either a pointer to the structure read or NULL
+is an error occurred.
+
+The write routines return 1 for success or 0 for failure.
diff --git a/src/lib/libssl/src/doc/crypto/rsa.pod b/src/lib/libssl/src/doc/crypto/rsa.pod
index ef0d4df205..09ad30cab1 100644
--- a/src/lib/libssl/src/doc/crypto/rsa.pod
+++ b/src/lib/libssl/src/doc/crypto/rsa.pod
@@ -37,7 +37,6 @@ rsa - RSA public key cryptosystem
  int RSA_set_method(RSA *rsa, ENGINE *engine);
  RSA_METHOD *RSA_get_method(RSA *rsa);
  RSA_METHOD *RSA_PKCS1_SSLeay(void);
- RSA_METHOD *RSA_PKCS1_RSAref(void);
  RSA_METHOD *RSA_null_method(void);
  int RSA_flags(RSA *rsa);
  RSA *RSA_new_method(ENGINE *engine);
diff --git a/src/lib/libssl/src/doc/crypto/threads.pod b/src/lib/libssl/src/doc/crypto/threads.pod
index bc7ff9b705..afa45cd76c 100644
--- a/src/lib/libssl/src/doc/crypto/threads.pod
+++ b/src/lib/libssl/src/doc/crypto/threads.pod
@@ -53,8 +53,10 @@ OpenSSL can safely be used in multi-threaded applications provided
 that at least two callback functions are set.
 
 locking_function(int mode, int n, const char *file, int line) is
-needed to perform locking on shared data structures. Multi-threaded
-applications will crash at random if it is not set.
+needed to perform locking on shared data structures. 
+(Note that OpenSSL uses a number of global data structures that
+will be implicitly shared whenever multiple threads use OpenSSL.)
+Multi-threaded applications will crash at random if it is not set.
 
 locking_function() must be able to handle up to CRYPTO_num_locks()
 different mutex locks. It sets the B<n>-th lock if B<mode> &
diff --git a/src/lib/libssl/src/doc/crypto/ui.pod b/src/lib/libssl/src/doc/crypto/ui.pod
new file mode 100644
index 0000000000..2b3535a746
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ui.pod
@@ -0,0 +1,194 @@
+=pod
+
+=head1 NAME
+
+UI_new, UI_new_method, UI_free, UI_add_input_string, UI_dup_input_string,
+UI_add_verify_string, UI_dup_verify_string, UI_add_input_boolean,
+UI_dup_input_boolean, UI_add_info_string, UI_dup_info_string,
+UI_add_error_string, UI_dup_error_string, UI_construct_prompt
+UI_add_user_data, UI_get0_user_data, UI_get0_result, UI_process,
+UI_ctrl, UI_set_default_method, UI_get_default_method, UI_get_method,
+UI_set_method, UI_OpenSSL, ERR_load_UI_strings - New User Interface
+
+=head1 SYNOPSIS
+
+ #include <openssl/ui.h>
+
+ typedef struct ui_st UI;
+ typedef struct ui_method_st UI_METHOD;
+
+ UI *UI_new(void);
+ UI *UI_new_method(const UI_METHOD *method);
+ void UI_free(UI *ui);
+
+ int UI_add_input_string(UI *ui, const char *prompt, int flags,
+        char *result_buf, int minsize, int maxsize);
+ int UI_dup_input_string(UI *ui, const char *prompt, int flags,
+        char *result_buf, int minsize, int maxsize);
+ int UI_add_verify_string(UI *ui, const char *prompt, int flags,
+        char *result_buf, int minsize, int maxsize, const char *test_buf);
+ int UI_dup_verify_string(UI *ui, const char *prompt, int flags,
+        char *result_buf, int minsize, int maxsize, const char *test_buf);
+ int UI_add_input_boolean(UI *ui, const char *prompt, const char *action_desc,
+        const char *ok_chars, const char *cancel_chars,
+        int flags, char *result_buf);
+ int UI_dup_input_boolean(UI *ui, const char *prompt, const char *action_desc,
+        const char *ok_chars, const char *cancel_chars,
+        int flags, char *result_buf);
+ int UI_add_info_string(UI *ui, const char *text);
+ int UI_dup_info_string(UI *ui, const char *text);
+ int UI_add_error_string(UI *ui, const char *text);
+ int UI_dup_error_string(UI *ui, const char *text);
+
+ /* These are the possible flags.  They can be or'ed together. */
+ #define UI_INPUT_FLAG_ECHO             0x01
+ #define UI_INPUT_FLAG_DEFAULT_PWD      0x02
+
+ char *UI_construct_prompt(UI *ui_method,
+        const char *object_desc, const char *object_name);
+
+ void *UI_add_user_data(UI *ui, void *user_data);
+ void *UI_get0_user_data(UI *ui);
+
+ const char *UI_get0_result(UI *ui, int i);
+
+ int UI_process(UI *ui);
+
+ int UI_ctrl(UI *ui, int cmd, long i, void *p, void (*f)());
+ #define UI_CTRL_PRINT_ERRORS           1
+ #define UI_CTRL_IS_REDOABLE            2
+
+ void UI_set_default_method(const UI_METHOD *meth);
+ const UI_METHOD *UI_get_default_method(void);
+ const UI_METHOD *UI_get_method(UI *ui);
+ const UI_METHOD *UI_set_method(UI *ui, const UI_METHOD *meth);
+
+ UI_METHOD *UI_OpenSSL(void);
+
+=head1 DESCRIPTION
+
+UI stands for User Interface, and is general purpose set of routines to
+prompt the user for text-based information.  Through user-written methods
+(see L<ui_create(3)|ui_create(3)>), prompting can be done in any way
+imaginable, be it plain text prompting, through dialog boxes or from a
+cell phone.
+
+All the functions work through a context of the type UI.  This context
+contains all the information needed to prompt correctly as well as a
+reference to a UI_METHOD, which is an ordered vector of functions that
+carry out the actual prompting.
+
+The first thing to do is to create a UI with UI_new() or UI_new_method(),
+then add information to it with the UI_add or UI_dup functions.  Also,
+user-defined random data can be passed down to the underlying method
+through calls to UI_add_user_data.  The default UI method doesn't care
+about these data, but other methods might.  Finally, use UI_process()
+to actually perform the prompting and UI_get0_result() to find the result
+to the prompt.
+
+A UI can contain more than one prompt, which are performed in the given
+sequence.  Each prompt gets an index number which is returned by the
+UI_add and UI_dup functions, and has to be used to get the corresponding
+result with UI_get0_result().
+
+The functions are as follows:
+
+UI_new() creates a new UI using the default UI method.  When done with
+this UI, it should be freed using UI_free().
+
+UI_new_method() creates a new UI using the given UI method.  When done with
+this UI, it should be freed using UI_free().
+
+UI_OpenSSL() returns the built-in UI method (note: not the default one,
+since the default can be changed.  See further on).  This method is the
+most machine/OS dependent part of OpenSSL and normally generates the
+most problems when porting.
+
+UI_free() removes a UI from memory, along with all other pieces of memory
+that's connected to it, like duplicated input strings, results and others.
+
+UI_add_input_string() and UI_add_verify_string() add a prompt to the UI,
+as well as flags and a result buffer and the desired minimum and maximum
+sizes of the result.  The given information is used to prompt for
+information, for example a password, and to verify a password (i.e. having
+the user enter it twice and check that the same string was entered twice).
+UI_add_verify_string() takes and extra argument that should be a pointer
+to the result buffer of the input string that it's supposed to verify, or
+verification will fail.
+
+UI_add_input_boolean() adds a prompt to the UI that's supposed to be answered
+in a boolean way, with a single character for yes and a different character
+for no.  A set of characters that can be used to cancel the prompt is given
+as well.  The prompt itself is really divided in two, one part being the
+descriptive text (given through the I<prompt> argument) and one describing
+the possible answers (given through the I<action_desc> argument).
+
+UI_add_info_string() and UI_add_error_string() add strings that are shown at
+the same time as the prompt for extra information or to show an error string.
+The difference between the two is only conceptual.  With the builtin method,
+there's no technical difference between them.  Other methods may make a
+difference between them, however.
+
+The flags currently supported are UI_INPUT_FLAG_ECHO, which is relevant for
+UI_add_input_string() and will have the users response be echoed (when
+prompting for a password, this flag should obviously not be used, and
+UI_INPUT_FLAG_DEFAULT_PWD, which means that a default password of some
+sort will be used (completely depending on the application and the UI
+method).
+
+UI_dup_input_string(), UI_dup_verify_string(), UI_dup_input_boolean(),
+UI_dup_info_string() and UI_dup_error_string() are basically the same
+as their UI_add counterparts, except that they make their own copies
+of all strings.
+
+UI_construct_prompt() is a helper function that can be used to create
+a prompt from two pieces of information: an description and a name.
+The default constructor (if there is none provided by the method used)
+creates a string "Enter I<description> for I<name>:".  With the
+description "pass phrase" and the file name "foo.key", that becomes
+"Enter pass phrase for foo.key:".  Other methods may create whatever
+string and may include encodings that will be processed by the other
+method functions.
+
+UI_add_user_data() adds a piece of memory for the method to use at any
+time.  The builtin UI method doesn't care about this info.  Note that several
+calls to this function doesn't add data, it replaces the previous blob
+with the one given as argument.
+
+UI_get0_user_data() retrieves the data that has last been given to the
+UI with UI_add_user_data().
+
+UI_get0_result() returns a pointer to the result buffer associated with
+the information indexed by I<i>.
+
+UI_process() goes through the information given so far, does all the printing
+and prompting and returns.
+
+UI_ctrl() adds extra control for the application author.  For now, it
+understands two commands: UI_CTRL_PRINT_ERRORS, which makes UI_process()
+print the OpenSSL error stack as part of processing the UI, and
+UI_CTRL_IS_REDOABLE, which returns a flag saying if the used UI can
+be used again or not.
+
+UI_set_default_method() changes the default UI method to the one given.
+
+UI_get_default_method() returns a pointer to the current default UI method.
+
+UI_get_method() returns the UI method associated with a given UI.
+
+UI_set_method() changes the UI method associated with a given UI.
+
+=head1 SEE ALSO
+
+L<ui_create(3)|ui_create(3)>, L<ui_compat(3)|ui_compat(3)>
+
+=head1 HISTORY
+
+The UI section was first introduced in OpenSSL 0.9.7.
+
+=head1 AUTHOR
+
+Richard Levitte (richard@levitte.org) for the OpenSSL project
+(http://www.openssl.org).
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/ui_compat.pod b/src/lib/libssl/src/doc/crypto/ui_compat.pod
new file mode 100644
index 0000000000..9ab3c69bf2
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ui_compat.pod
@@ -0,0 +1,55 @@
+=pod
+
+=head1 NAME
+
+des_read_password, des_read_2passwords, des_read_pw_string, des_read_pw -
+Compatibility user interface functions
+
+=head1 SYNOPSIS
+
+ int des_read_password(DES_cblock *key,const char *prompt,int verify);
+ int des_read_2passwords(DES_cblock *key1,DES_cblock *key2,
+        const char *prompt,int verify);
+
+ int des_read_pw_string(char *buf,int length,const char *prompt,int verify);
+ int des_read_pw(char *buf,char *buff,int size,const char *prompt,int verify);
+
+=head1 DESCRIPTION
+
+The DES library contained a few routines to prompt for passwords.  These
+aren't necessarely dependent on DES, and have therefore become part of the
+UI compatibility library.
+
+des_read_pw() writes the string specified by I<prompt> to standard output
+turns echo off and reads an input string from the terminal.  The string is
+returned in I<buf>, which must have spac for at least I<size> bytes.
+If I<verify> is set, the user is asked for the password twice and unless
+the two copies match, an error is returned.  The second password is stored
+in I<buff>, which must therefore also be at least I<size> bytes.  A return
+code of -1 indicates a system error, 1 failure due to use interaction, and
+0 is success.  All other functions described here use des_read_pw() to do
+the work.
+
+des_read_pw_string() is a variant of des_read_pw() that provides a buffer
+for you if I<verify> is set.
+
+des_read_password() calls des_read_pw() and converts the password to a
+DES key by calling DES_string_to_key(); des_read_2password() operates in
+the same way as des_read_password() except that it generates two keys
+by using the DES_string_to_2key() function.
+
+=head1 NOTES
+
+des_read_pw_string() is available in the MIT Kerberos library as well, and
+is also available under the name EVP_read_pw_string().
+
+=head1 SEE ALSO
+
+L<ui(3)|ui(3)>, L<ui_create(3)|ui_create(3)>
+
+=head1 AUTHOR
+
+Richard Levitte (richard@levitte.org) for the OpenSSL project
+(http://www.openssl.org).
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_COMP_add_compression_method.pod b/src/lib/libssl/src/doc/ssl/SSL_COMP_add_compression_method.pod
new file mode 100644
index 0000000000..2a98739114
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_COMP_add_compression_method.pod
@@ -0,0 +1,70 @@
+=pod
+
+=head1 NAME
+
+SSL_COMP_add_compression_method - handle SSL/TLS integrated compression methods
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_COMP_add_compression_method(int id, COMP_METHOD *cm);
+
+=head1 DESCRIPTION
+
+SSL_COMP_add_compression_method() adds the compression method B<cm> with
+the identifier B<id> to the list of available compression methods. This
+list is globally maintained for all SSL operations within this application.
+It cannot be set for specific SSL_CTX or SSL objects.
+
+=head1 NOTES
+
+The TLS standard (or SSLv3) allows the integration of compression methods
+into the communication. The TLS RFC does however not specify compression
+methods or their corresponding identifiers, so there is currently no compatible
+way to integrate compression with unknown peers. It is therefore currently not
+recommended to integrate compression into applications. Applications for
+non-public use may agree on certain compression methods. Using different
+compression methods with the same identifier will lead to connection failure.
+
+An OpenSSL client speaking a protocol that allows compression (SSLv3, TLSv1)
+will unconditionally send the list of all compression methods enabled with
+SSL_COMP_add_compression_method() to the server during the handshake.
+Unlike the mechanisms to set a cipher list, there is no method available to
+restrict the list of compression method on a per connection basis.
+
+An OpenSSL server will match the identifiers listed by a client against
+its own compression methods and will unconditionally activate compression
+when a matching identifier is found. There is no way to restrict the list
+of compression methods supported on a per connection basis.
+
+The OpenSSL library has the compression methods B<COMP_rle()> and (when
+especially enabled during compilation) B<COMP_zlib()> available.
+
+=head1 WARNINGS
+
+Once the identities of the compression methods for the TLS protocol have
+been standardized, the compression API will most likely be changed. Using
+it in the current state is not recommended.
+
+=head1 RETURN VALUES
+
+SSL_COMP_add_compression_method() may return the following values:
+
+=over 4
+
+=item 1
+
+The operation succeeded.
+
+=item 0
+
+The operation failed. Check the error queue to find out the reason.
+
+=back
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_add_extra_chain_cert.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_add_extra_chain_cert.pod
index 21a9db0e2a..ee28f5ccc3 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_add_extra_chain_cert.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_add_extra_chain_cert.pod
@@ -33,6 +33,7 @@ error stack to find out the reason for failure otherwise.
 
 L<ssl(3)|ssl(3)>,
 L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>,
+L<SSL_CTX_set_client_cert_cb(3)|SSL_CTX_set_client_cert_cb(3)>,
 L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_ctrl.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_ctrl.pod
new file mode 100644
index 0000000000..fb6adcf50c
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_ctrl.pod
@@ -0,0 +1,34 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_ctrl, SSL_CTX_callback_ctrl, SSL_ctrl, SSL_callback_ctrl - internal handling functions for SSL_CTX and SSL objects
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ long SSL_CTX_ctrl(SSL_CTX *ctx, int cmd, long larg, void *parg);
+ long SSL_CTX_callback_ctrl(SSL_CTX *, int cmd, void (*fp)());
+
+ long SSL_ctrl(SSL *ssl, int cmd, long larg, void *parg);
+ long SSL_callback_ctrl(SSL *, int cmd, void (*fp)());
+
+=head1 DESCRIPTION
+
+The SSL_*_ctrl() family of functions is used to manipulate settings of
+the SSL_CTX and SSL objects. Depending on the command B<cmd> the arguments
+B<larg>, B<parg>, or B<fp> are evaluated. These functions should never
+be called directly. All functionalities needed are made available via
+other functions or macros.
+
+=head1 RETURN VALUES
+
+The return values of the SSL*_ctrl() functions depend on the command
+supplied via the B<cmd> parameter.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_free.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_free.pod
index c716cde164..55e592f5f8 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_free.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_free.pod
@@ -24,6 +24,8 @@ the certificates and keys.
 
 SSL_CTX_free() does not provide diagnostic information.
 
+=head1 SEE ALSO
+
 L<SSL_CTX_new(3)|SSL_CTX_new(3)>, L<ssl(3)|ssl(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod
index 0f63537e78..84a799fc71 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_load_verify_locations.pod
@@ -58,7 +58,7 @@ failure.
 In server mode, when requesting a client certificate, the server must send
 the list of CAs of which it will accept client certificates. This list
 is not influenced by the contents of B<CAfile> or B<CApath> and must
-explicitely be set using the
+explicitly be set using the
 L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)>
 family of functions.
 
@@ -118,7 +118,7 @@ L<ssl(3)|ssl(3)>,
 L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)>,
 L<SSL_get_client_CA_list(3)|SSL_get_client_CA_list(3)>,
 L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>,
-L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>
-
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>,
+L<SSL_CTX_set_cert_store(3)|SSL_CTX_set_cert_store(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_new.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_new.pod
index 1dae8b0bdd..465220a75c 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_new.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_new.pod
@@ -59,10 +59,6 @@ choice when compatibility is a concern.
 
 =back
 
-If a generic method is used, it is necessary to explicitly set client or
-server mode with L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>
-or SSL_set_accept_state().
-
 The list of protocols available can later be limited using the SSL_OP_NO_SSLv2,
 SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the B<SSL_CTX_set_options()> or
 B<SSL_set_options()> functions. Using these options it is possible to choose
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_sess_set_get_cb.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_sess_set_get_cb.pod
index b6f15b4404..6e0ef00632 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_sess_set_get_cb.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_sess_set_get_cb.pod
@@ -70,12 +70,16 @@ proposed by the client. The get_session_cb() is always called, also when
 session caching was disabled. The get_session_cb() is passed the
 B<ssl> connection, the session id of length B<length> at the memory location
 B<data>. With the parameter B<copy> the callback can require the
-SSL engine to increment the reference count of the SSL_SESSION object.
+SSL engine to increment the reference count of the SSL_SESSION object,
+Normally the reference count is not incremented and therefore the
+session must not be explicitly freed with
+L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>.
 
 =head1 SEE ALSO
 
 L<ssl(3)|ssl(3)>, L<d2i_SSL_SESSION(3)|d2i_SSL_SESSION(3)>,
 L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>,
-L<SSL_CTX_flush_sessions(3)|<SSL_CTX_flush_sessions(3)>
+L<SSL_CTX_flush_sessions(3)|<SSL_CTX_flush_sessions(3)>,
+L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cert_store.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cert_store.pod
new file mode 100644
index 0000000000..81286ee650
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cert_store.pod
@@ -0,0 +1,57 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_cert_store, SSL_CTX_get_cert_store - manipulate X509 certificate verification storage
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_cert_store(SSL_CTX *ctx, X509_STORE *store);
+ X509_STORE *SSL_CTX_get_cert_store(SSL_CTX *ctx);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_cert_store() sets/replaces the certificate verification storage
+of B<ctx> to/with B<store>. If another X505_STORE object is currently
+set in B<ctx>, it will be X509_STORE_free()ed.
+
+SSL_CTX_get_cert_store() returns a pointer to the current certificate
+verification storage.
+
+=head1 NOTES
+
+In order to verify the certificates presented by the peer, trusted CA
+certificates must be accessed. These CA certificates are made available
+via lookup methods, handled inside the X509_STORE. From the X509_STORE
+the X509_STORE_CTX used when verifying certificates is created.
+
+Typically the trusted certificate store is handled indirectly via using
+L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>.
+Using the SSL_CTX_set_cert_store() and SSL_CTX_get_cert_store() functions
+it is possible to manipulate the X509_STORE object beyond the
+L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>
+call.
+
+Currently no detailed documentation on how to use the X509_STORE
+object is available. Not all members of the X509_STORE are used when
+the verification takes place. So will e.g. the verify_callback() be
+overridden with the verify_callback() set via the
+L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)> family of functions.
+This document must therefore be updated when documentation about the
+X509_STORE object and its handling becomes available.
+
+=head1 RETURN VALUES
+
+SSL_CTX_set_cert_store() does not return diagnostic output.
+
+SSL_CTX_get_cert_store() returns the current setting.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>,
+L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>,
+L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cert_verify_callback.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cert_verify_callback.pod
new file mode 100644
index 0000000000..c0f4f85708
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cert_verify_callback.pod
@@ -0,0 +1,75 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_cert_verify_callback - set peer certificate verification procedure
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_cert_verify_callback(SSL_CTX *ctx, int (*callback)(X509_STORE_CTX *,void *), void *arg);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_cert_verify_callback() sets the verification callback function for
+I<ctx>. SSL objects that are created from I<ctx> inherit the setting valid at
+the time when L<SSL_new(3)|SSL_new(3)> is called.
+
+=head1 NOTES
+
+Whenever a certificate is verified during a SSL/TLS handshake, a verification
+function is called. If the application does not explicitly specify a
+verification callback function, the built-in verification function is used.
+If a verification callback I<callback> is specified via
+SSL_CTX_set_cert_verify_callback(), the supplied callback function is called
+instead. By setting I<callback> to NULL, the default behaviour is restored.
+
+When the verification must be performed, I<callback> will be called with
+the arguments callback(X509_STORE_CTX *x509_store_ctx, void *arg). The 
+argument I<arg> is specified by the application when setting I<callback>.
+
+I<callback> should return 1 to indicate verification success and 0 to
+indicate verification failure. If SSL_VERIFY_PEER is set and I<callback>
+returns 0, the handshake will fail. As the verification procedure may
+allow to continue the connection in case of failure (by always returning 1)
+the verification result must be set in any case using the B<error>
+member of I<x509_store_ctx> so that the calling application will be informed
+about the detailed result of the verification procedure! 
+
+Within I<x509_store_ctx>, I<callback> has access to the I<verify_callback>
+function set using L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>.
+
+=head1 WARNINGS
+
+Do not mix the verification callback described in this function with the
+B<verify_callback> function called during the verification process. The
+latter is set using the L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>
+family of functions.
+
+Providing a complete verification procedure including certificate purpose
+settings etc is a complex task. The built-in procedure is quite powerful
+and in most cases it should be sufficient to modify its behaviour using
+the B<verify_callback> function.
+
+=head1 BUGS
+
+=head1 RETURN VALUES
+
+SSL_CTX_set_cert_verify_callback() does not provide diagnostic information.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>,
+L<SSL_get_verify_result(3)|SSL_get_verify_result(3)>,
+L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>
+
+=head1 HISTORY
+
+Previous to OpenSSL 0.9.7, the I<arg> argument to B<SSL_CTX_set_cert_verify_callback>
+was ignored, and I<callback> was called simply as
+ int (*callback)(X509_STORE_CTX *)
+To compile software written for previous versions of OpenSSL, a dummy
+argument will have to be added to I<callback>.
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cipher_list.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cipher_list.pod
index 9a29eeeb95..ed64f64157 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cipher_list.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_cipher_list.pod
@@ -34,9 +34,25 @@ a necessary condition. On the client side, the inclusion into the list is
 also sufficient. On the server side, additional restrictions apply. All ciphers
 have additional requirements. ADH ciphers don't need a certificate, but
 DH-parameters must have been set. All other ciphers need a corresponding
-certificate and key. A RSA cipher can only be chosen, when a RSA certificate is
-available, the respective is valid for DSA ciphers. Ciphers using EDH need
-a certificate and key and DH-parameters.
+certificate and key.
+
+A RSA cipher can only be chosen, when a RSA certificate is available.
+RSA export ciphers with a keylength of 512 bits for the RSA key require
+a temporary 512 bit RSA key, as typically the supplied key has a length
+of 1024 bit (see
+L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>).
+RSA ciphers using EDH need a certificate and key and additional DH-parameters
+(see L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
+
+A DSA cipher can only be chosen, when a DSA certificate is available.
+DSA ciphers always use DH key exchange and therefore need DH-parameters
+(see L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
+
+When these conditions are not met for any cipher in the list (e.g. a
+client only supports export RSA ciphers with a asymmetric key length
+of 512 bits and the server is not configured to use temporary RSA
+keys), the "no shared cipher" (SSL_R_NO_SHARED_CIPHER) error is generated
+and the handshake will fail.
 
 =head1 RETURN VALUES
 
@@ -47,6 +63,8 @@ could be selected and 0 on complete failure.
 
 L<ssl(3)|ssl(3)>, L<SSL_get_ciphers(3)|SSL_get_ciphers(3)>,
 L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>,
+L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>,
+L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>,
 L<ciphers(1)|ciphers(1)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_client_cert_cb.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_client_cert_cb.pod
new file mode 100644
index 0000000000..53e1827713
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_client_cert_cb.pod
@@ -0,0 +1,90 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_client_cert_cb, SSL_CTX_get_client_cert_cb - handle client certificate callback function
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_client_cert_cb(SSL_CTX *ctx, int (*client_cert_cb)(SSL *ssl, X509 **x509, EVP_PKEY **pkey));
+ int (*SSL_CTX_get_client_cert_cb(SSL_CTX *ctx))(SSL *ssl, X509 **x509, EVP_PKEY **pkey);
+ int (*client_cert_cb)(SSL *ssl, X509 **x509, EVP_PKEY **pkey);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_client_cert_cb() sets the B<client_cert_cb()> callback, that is
+called when a client certificate is requested by a server.
+When B<client_cert_cb()> is NULL, not callback function is used.
+
+SSL_CTX_get_client_cert_cb() returns a pointer to the currently set callback
+function.
+
+client_cert_cb() is the application defined callback. If it wants to
+set a certificate, a certificate/private key combination must be set
+using the B<x509> and B<pkey> arguments and "1" must be returned. The
+certificate will be installed into B<ssl>, see the NOTES and BUGS sections.
+If no certificate should be set, "0" has to be returned and the default
+certificate will be sent. A fatal error can be indicated by returning
+a negative value, in which case the handshake will be canceled.
+
+=head1 NOTES
+
+During a handshake (or renegotiation) a server may request a certificate
+from the client. A client certificate must only be sent, when the server
+did send the request.
+
+When no callback function is set, an OpenSSL client will send the certificate
+that was set using the
+L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)> family of functions.
+The TLS standard requires that only a certificate is sent, if it matches
+the list of acceptable CAs sent by the server. This constraint is
+violated by the default behavior of the OpenSSL library. Using the
+callback function it is possible to implement a proper selection routine
+or to allow a user interaction to choose the certificate to be sent.
+The callback function can obtain the list of acceptable CAs using the
+L<SSL_get_client_CA_list(3)|SSL_get_client_CA_list(3)> function.
+
+If a callback function is defined, the callback function will be called.
+If the callback function returns a certificate, the OpenSSL library
+will try to load the private key and certificate data into the SSL
+object using SSL_use_certificate() and SSL_use_private_key() functions.
+Thus it will permanently override the certificate and key previously
+installed and will not be reset by calling L<SSL_clear(3)|SSL_clear(3)>.
+If the callback returns no certificate, the OpenSSL library will send
+the certificate previously installed for the SSL_CTX object or the specific
+certificate of the SSL object, if available.
+
+=head1 BUGS
+
+The client_cert_cb() cannot return a complete certificate chain, it can
+only return one client certificate. If the chain only has a length of 2,
+the root CA certificate may be omitted according to the TLS standard and
+thus a standard conforming answer can be sent to the server. For a
+longer chain, the client must send the complete chain (with the option
+to leave out the root CA certificate). This can only be accomplished by
+either adding the intermediate CA certificates into the trusted
+certificate store for the SSL_CTX object (resulting in having to add
+CA certificates that otherwise maybe would not be trusted), or by adding
+the chain certificates using the
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>
+function, which is only available for the SSL_CTX object as a whole and that
+therefore probably can only apply for one client certificate, making
+the concept of the callback function (to allow the choice from several
+certificates) questionable.
+
+Once the SSL object has been used in conjunction with the callback function,
+the certificate will be set for the SSL object and will not be cleared
+even when L<SSL_clear(3)|SSL_clear(3)> is being called. It is therefore
+mandatory to destroy the SSL object using L<SSL_free(3)|SSL_free(3)>
+and create a new one to return to the previous state.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>,
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>,
+L<SSL_get_client_CA_list(3)|SSL_get_client_CA_list(3)>,
+L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_default_passwd_cb.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_default_passwd_cb.pod
index a5343a1cf3..2b87f01ca1 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_default_passwd_cb.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_default_passwd_cb.pod
@@ -40,6 +40,12 @@ then keep it in memory and use it several times. In the last case, the
 password could be stored into the B<userdata> storage and the
 pem_passwd_cb() only returns the password already stored.
 
+When asking for the password interactively, pem_passwd_cb() can use
+B<rwflag> to check, whether an item shall be encrypted (rwflag=1).
+In this case the password dialog may ask for the same password twice
+for comparison in order to catch typos, that would make decryption
+impossible.
+
 Other items in PEM formatting (certificates) can also be encrypted, it is
 however not usual, as certificate information is considered public.
 
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_generate_session_id.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_generate_session_id.pod
new file mode 100644
index 0000000000..798e8443a7
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_generate_session_id.pod
@@ -0,0 +1,150 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_generate_session_id, SSL_set_generate_session_id, SSL_has_matching_session_id - manipulate generation of SSL session IDs (server only)
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ typedef int (*GEN_SESSION_CB)(const SSL *ssl, unsigned char *id,
+                               unsigned int *id_len);
+
+ int SSL_CTX_set_generate_session_id(SSL_CTX *ctx, GEN_SESSION_CB cb);
+ int SSL_set_generate_session_id(SSL *ssl, GEN_SESSION_CB, cb);
+ int SSL_has_matching_session_id(const SSL *ssl, const unsigned char *id,
+                                 unsigned int id_len);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_generate_session_id() sets the callback function for generating
+new session ids for SSL/TLS sessions for B<ctx> to be B<cb>.
+
+SSL_set_generate_session_id() sets the callback function for generating
+new session ids for SSL/TLS sessions for B<ssl> to be B<cb>.
+
+SSL_has_matching_session_id() checks, whether a session with id B<id>
+(of length B<id_len>) is already contained in the internal session cache
+of the parent context of B<ssl>.
+
+=head1 NOTES
+
+When a new session is established between client and server, the server
+generates a session id. The session id is an arbitrary sequence of bytes.
+The length of the session id is 16 bytes for SSLv2 sessions and between
+1 and 32 bytes for SSLv3/TLSv1. The session id is not security critical
+but must be unique for the server. Additionally, the session id is
+transmitted in the clear when reusing the session so it must not contain
+sensitive information.
+
+Without a callback being set, an OpenSSL server will generate a unique
+session id from pseudo random numbers of the maximum possible length.
+Using the callback function, the session id can be changed to contain
+additional information like e.g. a host id in order to improve load balancing
+or external caching techniques.
+
+The callback function receives a pointer to the memory location to put
+B<id> into and a pointer to the maximum allowed length B<id_len>. The
+buffer at location B<id> is only guaranteed to have the size B<id_len>.
+The callback is only allowed to generate a shorter id and reduce B<id_len>;
+the callback B<must never> increase B<id_len> or write to the location
+B<id> exceeding the given limit.
+
+If a SSLv2 session id is generated and B<id_len> is reduced, it will be
+restored after the callback has finished and the session id will be padded
+with 0x00. It is not recommended to change the B<id_len> for SSLv2 sessions.
+The callback can use the L<SSL_get_version(3)|SSL_get_version(3)> function
+to check, whether the session is of type SSLv2.
+
+The location B<id> is filled with 0x00 before the callback is called, so the
+callback may only fill part of the possible length and leave B<id_len>
+untouched while maintaining reproducibility.
+
+Since the sessions must be distinguished, session ids must be unique.
+Without the callback a random number is used, so that the probability
+of generating the same session id is extremely small (2^128 possible ids
+for an SSLv2 session, 2^256 for SSLv3/TLSv1). In order to assure the
+uniqueness of the generated session id, the callback must call
+SSL_has_matching_session_id() and generate another id if a conflict occurs.
+If an id conflict is not resolved, the handshake will fail.
+If the application codes e.g. a unique host id, a unique process number, and
+a unique sequence number into the session id, uniqueness could easily be
+achieved without randomness added (it should however be taken care that
+no confidential information is leaked this way). If the application can not
+guarantee uniqueness, it is recommended to use the maximum B<id_len> and
+fill in the bytes not used to code special information with random data
+to avoid collisions.
+
+SSL_has_matching_session_id() will only query the internal session cache,
+not the external one. Since the session id is generated before the
+handshake is completed, it is not immediately added to the cache. If
+another thread is using the same internal session cache, a race condition
+can occur in that another thread generates the same session id.
+Collisions can also occur when using an external session cache, since
+the external cache is not tested with SSL_has_matching_session_id()
+and the same race condition applies.
+
+When calling SSL_has_matching_session_id() for an SSLv2 session with
+reduced B<id_len>, the match operation will be performed using the
+fixed length required and with a 0x00 padded id.
+
+The callback must return 0 if it cannot generate a session id for whatever
+reason and return 1 on success.
+
+=head1 EXAMPLES
+
+The callback function listed will generate a session id with the
+server id given, and will fill the rest with pseudo random bytes:
+
+ const char session_id_prefix = "www-18";
+
+ #define MAX_SESSION_ID_ATTEMPTS 10
+ static int generate_session_id(const SSL *ssl, unsigned char *id,
+                              unsigned int *id_len)
+      {
+      unsigned int count = 0;
+      const char *version;
+
+      version = SSL_get_version(ssl);
+      if (!strcmp(version, "SSLv2"))
+          /* we must not change id_len */;
+
+      do      {
+              RAND_pseudo_bytes(id, *id_len);
+              /* Prefix the session_id with the required prefix. NB: If our
+               * prefix is too long, clip it - but there will be worse effects
+               * anyway, eg. the server could only possibly create 1 session
+               * ID (ie. the prefix!) so all future session negotiations will
+               * fail due to conflicts. */
+              memcpy(id, session_id_prefix,
+                      (strlen(session_id_prefix) < *id_len) ?
+                      strlen(session_id_prefix) : *id_len);
+              }
+      while(SSL_has_matching_session_id(ssl, id, *id_len) &&
+              (++count < MAX_SESSION_ID_ATTEMPTS));
+      if(count >= MAX_SESSION_ID_ATTEMPTS)
+              return 0;
+      return 1;
+      }
+
+
+=head1 RETURN VALUES
+
+SSL_CTX_set_generate_session_id() and SSL_set_generate_session_id()
+always return 1.
+
+SSL_has_matching_session_id() returns 1 if another session with the
+same id is already in the cache.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_get_version(3)|SSL_get_version(3)>
+
+=head1 HISTORY
+
+SSL_CTX_set_generate_session_id(), SSL_set_generate_session_id()
+and SSL_has_matching_session_id() have been introduced in
+OpenSSL 0.9.7.
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_info_callback.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_info_callback.pod
new file mode 100644
index 0000000000..63d0b8d33f
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_info_callback.pod
@@ -0,0 +1,153 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_info_callback, SSL_CTX_get_info_callback, SSL_set_info_callback, SSL_get_info_callback - handle information callback for SSL connections
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_info_callback(SSL_CTX *ctx, void (*callback)());
+ void (*SSL_CTX_get_info_callback(SSL_CTX *ctx))();
+
+ void SSL_set_info_callback(SSL *ssl, void (*callback)());
+ void (*SSL_get_info_callback(SSL *ssl))();
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_info_callback() sets the B<callback> function, that can be used to
+obtain state information for SSL objects created from B<ctx> during connection
+setup and use. The setting for B<ctx> is overridden from the setting for
+a specific SSL object, if specified.
+When B<callback> is NULL, not callback function is used.
+
+SSL_set_info_callback() sets the B<callback> function, that can be used to
+obtain state information for B<ssl> during connection setup and use.
+When B<callback> is NULL, the callback setting currently valid for
+B<ctx> is used.
+
+SSL_CTX_get_info_callback() returns a pointer to the currently set information
+callback function for B<ctx>.
+
+SSL_get_info_callback() returns a pointer to the currently set information
+callback function for B<ssl>.
+
+=head1 NOTES
+
+When setting up a connection and during use, it is possible to obtain state
+information from the SSL/TLS engine. When set, an information callback function
+is called whenever the state changes, an alert appears, or an error occurs.
+
+The callback function is called as B<callback(SSL *ssl, int where, int ret)>.
+The B<where> argument specifies information about where (in which context)
+the callback function was called. If B<ret> is 0, an error condition occurred.
+If an alert is handled, SSL_CB_ALERT is set and B<ret> specifies the alert
+information.
+
+B<where> is a bitmask made up of the following bits:
+
+=over 4
+
+=item SSL_CB_LOOP
+
+Callback has been called to indicate state change inside a loop.
+
+=item SSL_CB_EXIT
+
+Callback has been called to indicate error exit of a handshake function.
+(May be soft error with retry option for non-blocking setups.)
+
+=item SSL_CB_READ
+
+Callback has been called during read operation.
+
+=item SSL_CB_WRITE
+
+Callback has been called during write operation.
+
+=item SSL_CB_ALERT
+
+Callback has been called due to an alert being sent or received.
+
+=item SSL_CB_READ_ALERT               (SSL_CB_ALERT|SSL_CB_READ)
+
+=item SSL_CB_WRITE_ALERT              (SSL_CB_ALERT|SSL_CB_WRITE)
+
+=item SSL_CB_ACCEPT_LOOP              (SSL_ST_ACCEPT|SSL_CB_LOOP)
+
+=item SSL_CB_ACCEPT_EXIT              (SSL_ST_ACCEPT|SSL_CB_EXIT)
+
+=item SSL_CB_CONNECT_LOOP             (SSL_ST_CONNECT|SSL_CB_LOOP)
+
+=item SSL_CB_CONNECT_EXIT             (SSL_ST_CONNECT|SSL_CB_EXIT)
+
+=item SSL_CB_HANDSHAKE_START
+
+Callback has been called because a new handshake is started.
+
+=item SSL_CB_HANDSHAKE_DONE           0x20
+
+Callback has been called because a handshake is finished.
+
+=back
+
+The current state information can be obtained using the
+L<SSL_state_string(3)|SSL_state_string(3)> family of functions.
+
+The B<ret> information can be evaluated using the
+L<SSL_alert_type_string(3)|SSL_alert_type_string(3)> family of functions.
+
+=head1 RETURN VALUES
+
+SSL_set_info_callback() does not provide diagnostic information.
+
+SSL_get_info_callback() returns the current setting.
+
+=head1 EXAMPLES
+
+The following example callback function prints state strings, information
+about alerts being handled and error messages to the B<bio_err> BIO.
+
+ void apps_ssl_info_callback(SSL *s, int where, int ret)
+        {
+        const char *str;
+        int w;
+
+        w=where& ~SSL_ST_MASK;
+
+        if (w & SSL_ST_CONNECT) str="SSL_connect";
+        else if (w & SSL_ST_ACCEPT) str="SSL_accept";
+        else str="undefined";
+
+        if (where & SSL_CB_LOOP)
+                {
+                BIO_printf(bio_err,"%s:%s\n",str,SSL_state_string_long(s));
+                }
+        else if (where & SSL_CB_ALERT)
+                {
+                str=(where & SSL_CB_READ)?"read":"write";
+                BIO_printf(bio_err,"SSL3 alert %s:%s:%s\n",
+                        str,
+                        SSL_alert_type_string_long(ret),
+                        SSL_alert_desc_string_long(ret));
+                }
+        else if (where & SSL_CB_EXIT)
+                {
+                if (ret == 0)
+                        BIO_printf(bio_err,"%s:failed in %s\n",
+                                str,SSL_state_string_long(s));
+                else if (ret < 0)
+                        {
+                        BIO_printf(bio_err,"%s:error in %s\n",
+                                str,SSL_state_string_long(s));
+                        }
+                }
+        }
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_state_string(3)|SSL_state_string(3)>,
+L<SSL_alert_type_string(3)|SSL_alert_type_string(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_max_cert_list.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_max_cert_list.pod
new file mode 100644
index 0000000000..da68cb9fc2
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_max_cert_list.pod
@@ -0,0 +1,77 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_max_cert_list, SSL_CTX_get_max_cert_list, SSL_set_max_cert_list, SSL_get_max_cert_list, - manipulate allowed for the peer's certificate chain
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ long SSL_CTX_set_max_cert_list(SSL_CTX *ctx, long size);
+ long SSL_CTX_get_max_cert_list(SSL_CTX *ctx);
+
+ long SSL_set_max_cert_list(SSL *ssl, long size);
+ long SSL_get_max_cert_list(SSL *ctx);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_max_cert_list() sets the maximum size allowed for the peer's
+certificate chain for all SSL objects created from B<ctx> to be <size> bytes.
+The SSL objects inherit the setting valid for B<ctx> at the time
+L<SSL_new(3)|SSL_new(3)> is being called.
+
+SSL_CTX_get_max_cert_list() returns the currently set maximum size for B<ctx>.
+
+SSL_set_max_cert_list() sets the maximum size allowed for the peer's
+certificate chain for B<ssl> to be <size> bytes. This setting stays valid
+until a new value is set.
+
+SSL_get_max_cert_list() returns the currently set maximum size for B<ssl>.
+
+=head1 NOTES
+
+During the handshake process, the peer may send a certificate chain.
+The TLS/SSL standard does not give any maximum size of the certificate chain.
+The OpenSSL library handles incoming data by a dynamically allocated buffer.
+In order to prevent this buffer from growing without bounds due to data
+received from a faulty or malicious peer, a maximum size for the certificate
+chain is set.
+
+The default value for the maximum certificate chain size is 100kB (30kB
+on the 16bit DOS platform). This should be sufficient for usual certificate
+chains (OpenSSL's default maximum chain length is 10, see
+L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>, and certificates
+without special extensions have a typical size of 1-2kB).
+
+For special applications it can be necessary to extend the maximum certificate
+chain size allowed to be sent by the peer, see e.g. the work on
+"Internet X.509 Public Key Infrastructure Proxy Certificate Profile"
+and "TLS Delegation Protocol" at http://www.ietf.org/ and
+http://www.globus.org/ .
+
+Under normal conditions it should never be necessary to set a value smaller
+than the default, as the buffer is handled dynamically and only uses the
+memory actually required by the data sent by the peer.
+
+If the maximum certificate chain size allowed is exceeded, the handshake will
+fail with a SSL_R_EXCESSIVE_MESSAGE_SIZE error.
+
+=head1 RETURN VALUES
+
+SSL_CTX_set_max_cert_list() and SSL_set_max_cert_list() return the previously
+set value.
+
+SSL_CTX_get_max_cert_list() and SSL_get_max_cert_list() return the currently
+set value.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>,
+L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>
+
+=head1 HISTORY
+
+SSL*_set/get_max_cert_list() have been introduced in OpenSSL 0.9.7.
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_mode.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_mode.pod
index 9a035bb4d1..9822544e5e 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_mode.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_mode.pod
@@ -37,6 +37,9 @@ The following mode changes are available:
 Allow SSL_write(..., n) to return r with 0 < r < n (i.e. report success
 when just a single record has been written). When not set (the default),
 SSL_write() will only report success once the complete chunk was written.
+Once SSL_write() returns with r, r bytes have been successfully written
+and the next call to SSL_write() must only send the n-r bytes left,
+imitating the behaviour of write().
 
 =item SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
 
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_msg_callback.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_msg_callback.pod
new file mode 100644
index 0000000000..a423932d0a
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_msg_callback.pod
@@ -0,0 +1,97 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_msg_callback, SSL_CTX_set_msg_callback_arg, SSL_set_msg_callback, SSL_get_msg_callback_arg - install callback for observing protocol messages
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_msg_callback(SSL_CTX *ctx, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg));
+ void SSL_CTX_set_msg_callback_arg(SSL_CTX *ctx, void *arg);
+
+ void SSL_set_msg_callback(SSL_CTX *ctx, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg));
+ void SSL_set_msg_callback_arg(SSL_CTX *ctx, void *arg);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_msg_callback() or SSL_set_msg_callback() can be used to
+define a message callback function I<cb> for observing all SSL/TLS
+protocol messages (such as handshake messages) that are received or
+sent.  SSL_CTX_set_msg_callback_arg() and SSL_set_msg_callback_arg()
+can be used to set argument I<arg> to the callback function, which is
+available for arbitrary application use.
+
+SSL_CTX_set_msg_callback() and SSL_CTX_set_msg_callback_arg() specify
+default settings that will be copied to new B<SSL> objects by
+L<SSL_new(3)|SSL_new(3)>. SSL_set_msg_callback() and
+SSL_set_msg_callback_arg() modify the actual settings of an B<SSL>
+object. Using a B<0> pointer for I<cb> disables the message callback.
+
+When I<cb> is called by the SSL/TLS library for a protocol message,
+the function arguments have the following meaning:
+
+=over 4
+
+=item I<write_p>
+
+This flag is B<0> when a protocol message has been received and B<1>
+when a protocol message has been sent.
+
+=item I<version>
+
+The protocol version according to which the protocol message is
+interpreted by the library. Currently, this is one of
+B<SSL2_VERSION>, B<SSL3_VERSION> and B<TLS1_VERSION> (for SSL 2.0, SSL
+3.0 and TLS 1.0, respectively).
+
+=item I<content_type>
+
+In the case of SSL 2.0, this is always B<0>.  In the case of SSL 3.0
+or TLS 1.0, this is one of the B<ContentType> values defined in the
+protocol specification (B<change_cipher_spec(20)>, B<alert(21)>,
+B<handshake(22)>; but never B<application_data(23)> because the
+callback will only be called for protocol messages).
+
+=item I<buf>, I<len>
+
+I<buf> points to a buffer containing the protocol message, which
+consists of I<len> bytes. The buffer is no longer valid after the
+callback function has returned.
+
+=item I<ssl>
+
+The B<SSL> object that received or sent the message.
+
+=item I<arg>
+
+The user-defined argument optionally defined by
+SSL_CTX_set_msg_callback_arg() or SSL_set_msg_callback_arg().
+
+=head1 NOTES
+
+Protocol messages are passed to the callback function after decryption
+and fragment collection where applicable. (Thus record boundaries are
+not visible.)
+
+If processing a received protocol message results in an error,
+the callback function may not be called.  For example, the callback
+function will never see messages that are considered too large to be
+processed.
+
+Due to automatic protocol version negotiation, I<version> is not
+necessarily the protocol version used by the sender of the message: If
+a TLS 1.0 ClientHello message is received by an SSL 3.0-only server,
+I<version> will be B<SSL3_VERSION>.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>
+
+=head1 HISTORY
+
+SSL_CTX_set_msg_callback(), SSL_CTX_set_msg_callback_arg(),
+SSL_set_msg_callback() and SSL_get_msg_callback_arg() were added in OpenSSL 0.9.7.
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_options.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_options.pod
index 3dc7cc74ad..c10055c6e7 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_options.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_options.pod
@@ -17,10 +17,10 @@ SSL_CTX_set_options, SSL_set_options, SSL_CTX_get_options, SSL_get_options - man
 =head1 DESCRIPTION
 
 SSL_CTX_set_options() adds the options set via bitmask in B<options> to B<ctx>.
-Options already set before are not cleared.
+Options already set before are not cleared!
 
 SSL_set_options() adds the options set via bitmask in B<options> to B<ssl>.
-Options already set before are not cleared.
+Options already set before are not cleared!
 
 SSL_CTX_get_options() returns the options set for B<ctx>.
 
@@ -32,7 +32,12 @@ The behaviour of the SSL library can be changed by setting several options.
 The options are coded as bitmasks and can be combined by a logical B<or>
 operation (|). Options can only be added but can never be reset.
 
-During a handshake, the option settings of the SSL object used. When
+SSL_CTX_set_options() and SSL_set_options() affect the (external)
+protocol behaviour of the SSL library. The (internal) behaviour of
+the API can be changed by using the similar
+L<SSL_CTX_set_modes(3)|SSL_CTX_set_modes(3)> and SSL_set_modes() functions.
+
+During a handshake, the option settings of the SSL object are used. When
 a new SSL object is created from a context using SSL_new(), the current
 option setting is copied. Changes to B<ctx> do not affect already created
 SSL objects. SSL_clear() does not affect the settings.
@@ -95,38 +100,62 @@ doing a re-connect, always takes the first cipher in the cipher list.
 
 ...
 
-=item SSL_OP_TLS_ROLLBACK_BUG
-
-Disable version rollback attack detection.
-
-During the client key exchange, the client must send the same information
-about acceptable SSL/TLS protocol levels as during the first hello. Some
-clients violate this rule by adapting to the server's answer. (Example:
-the client sends a SSLv2 hello and accepts up to SSLv3.1=TLSv1, the server
-only understands up to SSLv3. In this case the client must still use the
-same SSLv3.1=TLSv1 announcement. Some clients step down to SSLv3 with respect
-to the server's answer and violate the version rollback protection.)
-
 =item SSL_OP_ALL
 
 All of the above bug workarounds.
 
 =back
 
-It is save and recommended to use SSL_OP_ALL to enable the bug workaround
+It is safe and recommended to use B<SSL_OP_ALL> to enable the bug workaround
 options.
 
 The following B<modifying> options are available:
 
 =over 4
 
+=item SSL_OP_TLS_ROLLBACK_BUG
+
+Disable version rollback attack detection.
+
+During the client key exchange, the client must send the same information
+about acceptable SSL/TLS protocol levels as during the first hello. Some
+clients violate this rule by adapting to the server's answer. (Example:
+the client sends a SSLv2 hello and accepts up to SSLv3.1=TLSv1, the server
+only understands up to SSLv3. In this case the client must still use the
+same SSLv3.1=TLSv1 announcement. Some clients step down to SSLv3 with respect
+to the server's answer and violate the version rollback protection.)
+
 =item SSL_OP_SINGLE_DH_USE
 
-Always create a new key when using temporary DH parameters.
+Always create a new key when using temporary/ephemeral DH parameters
+(see L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
+This option must be used to prevent small subgroup attacks, when
+the DH parameters were not generated using "strong" primes
+(e.g. when using DSA-parameters, see L<dhparam(1)|dhparam(1)>).
+If "strong" primes were used, it is not strictly necessary to generate
+a new DH key during each handshake but it is also recommended.
+B<SSL_OP_SINGLE_DH_USE> should therefore be enabled whenever
+temporary/ephemeral DH parameters are used.
 
 =item SSL_OP_EPHEMERAL_RSA
 
-Also use the temporary RSA key when doing RSA operations.
+Always use ephemeral (temporary) RSA key when doing RSA operations
+(see L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>).
+According to the specifications this is only done, when a RSA key
+can only be used for signature operations (namely under export ciphers
+with restricted RSA keylength). By setting this option, ephemeral
+RSA keys are always used. This option breaks compatibility with the
+SSL/TLS specifications and may lead to interoperability problems with
+clients and should therefore never be used. Ciphers with EDH (ephemeral
+Diffie-Hellman) key exchange should be used instead.
+
+=item SSL_OP_CIPHER_SERVER_PREFERENCE
+
+When choosing a cipher, use the server's preferences instead of the client
+preferences. When not set, the SSL server will always follow the clients
+preferences. When set, the SSLv3/TLSv1 server will choose following its
+own preferences. Because of the different protocol, for SSLv2 the server
+will send his list of preferences to the client and the client chooses.
 
 =item SSL_OP_PKCS1_CHECK_1
 
@@ -142,11 +171,6 @@ If we accept a netscape connection, demand a client cert, have a
 non-self-sighed CA which does not have it's CA in netscape, and the
 browser has a cert, it will crash/hang.  Works for 3.x and 4.xbeta 
 
-=item SSL_OP_NON_EXPORT_FIRST
-
-On servers try to use non-export (stronger) ciphers first. This option does
-not work under all circumstances (in the code it is declared "broken").
-
 =item SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG
 
 ...
@@ -163,6 +187,12 @@ Do not use the SSLv3 protocol.
 
 Do not use the TLSv1 protocol.
 
+=item SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
+
+When performing renegotiation as a server, always start a new session
+(i.e., session resumption requests are only accepted in the initial
+handshake).  This option is not needed for clients.
+
 =back
 
 =head1 RETURN VALUES
@@ -174,10 +204,19 @@ SSL_CTX_get_options() and SSL_get_options() return the current bitmask.
 
 =head1 SEE ALSO
 
-L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>, L<SSL_clear(3)|SSL_clear(3)>
+L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>, L<SSL_clear(3)|SSL_clear(3)>,
+L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>,
+L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>,
+L<dhparam(1)|dhparam(1)>
 
 =head1 HISTORY
 
-SSL_OP_TLS_ROLLBACK_BUG has been added in OpenSSL 0.9.6.
+B<SSL_OP_CIPHER_SERVER_PREFERENCE> and
+B<SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION> have been added in
+OpenSSL 0.9.7.
+
+B<SSL_OP_TLS_ROLLBACK_BUG> has been added in OpenSSL 0.9.6 and was automatically
+enabled with B<SSL_OP_ALL>. As of 0.9.7, it is no longer included in B<SSL_OP_ALL>
+and must be explicitly set.
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_quiet_shutdown.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_quiet_shutdown.pod
new file mode 100644
index 0000000000..1d0526d59a
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_quiet_shutdown.pod
@@ -0,0 +1,63 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_quiet_shutdown, SSL_CTX_get_quiet_shutdown, SSL_set_quiet_shutdown, SSL_get_quiet_shutdown - manipulate shutdown behaviour
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_quiet_shutdown(SSL_CTX *ctx, int mode);
+ int SSL_CTX_get_quiet_shutdown(SSL_CTX *ctx);
+
+ void SSL_set_quiet_shutdown(SSL *ssl, int mode);
+ int SSL_get_quiet_shutdown(SSL *ssl);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_quiet_shutdown() sets the "quiet shutdown" flag for B<ctx> to be
+B<mode>. SSL objects created from B<ctx> inherit the B<mode> valid at the time
+L<SSL_new(3)|SSL_new(3)> is called. B<mode> may be 0 or 1.
+
+SSL_CTX_get_quiet_shutdown() returns the "quiet shutdown" setting of B<ctx>.
+
+SSL_set_quiet_shutdown() sets the "quiet shutdown" flag for B<ssl> to be
+B<mode>. The setting stays valid until B<ssl> is removed with
+L<SSL_free(3)|SSL_free(3)> or SSL_set_quiet_shutdown() is called again.
+It is not changed when L<SSL_clear(3)|SSL_clear(3)> is called.
+B<mode> may be 0 or 1.
+
+SSL_get_quiet_shutdown() returns the "quiet shutdown" setting of B<ssl>.
+
+=head1 NOTES
+
+Normally when a SSL connection is finished, the parties must send out
+"close notify" alert messages using L<SSL_shutdown(3)|SSL_shutdown(3)>
+for a clean shutdown.
+
+When setting the "quiet shutdown" flag to 1, L<SSL_shutdown(3)|SSL_shutdown(3)>
+will set the internal flags to SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN.
+(L<SSL_shutdown(3)|SSL_shutdown(3)> then behaves like
+L<SSL_set_shutdown(3)|SSL_set_shutdown(3)> called with
+SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN.)
+The session is thus considered to be shutdown, but no "close notify" alert
+is sent to the peer. This behaviour violates the TLS standard.
+
+The default is normal shutdown behaviour as described by the TLS standard.
+
+=head1 RETURN VALUES
+
+SSL_CTX_set_quiet_shutdown() and SSL_set_quiet_shutdown() do not return
+diagnostic information.
+
+SSL_CTX_get_quiet_shutdown() and SSL_get_quiet_shutdown return the current
+setting.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_shutdown(3)|SSL_shutdown(3)>,
+L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>, L<SSL_new(3)|SSL_new(3)>,
+L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_session_cache_mode.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_session_cache_mode.pod
index 8bbfc78720..9aa6c6b2e3 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_session_cache_mode.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_session_cache_mode.pod
@@ -97,6 +97,7 @@ SSL_CTX_get_session_cache_mode() returns the currently set cache mode.
 =head1 SEE ALSO
 
 L<ssl(3)|ssl(3)>, L<SSL_set_session(3)|SSL_set_session(3)>,
+L<SSL_session_reused(3)|SSL_session_reused(3)>,
 L<SSL_CTX_sess_number(3)|SSL_CTX_sess_number(3)>,
 L<SSL_CTX_sess_set_cache_size(3)|SSL_CTX_sess_set_cache_size(3)>,
 L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)>,
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_timeout.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_timeout.pod
index 21faed12d4..e3de27c473 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_timeout.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_timeout.pod
@@ -37,7 +37,10 @@ L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)> is called, either
 directly by the application or automatically (see
 L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>)
 
-The default value for session timeout is 300 seconds.
+The default value for session timeout is decided on a per protocol
+basis, see L<SSL_get_default_timeout(3)|SSL_get_default_timeout(3)>.
+All currently supported protocols have the same default timeout value
+of 300 seconds.
 
 =head1 RETURN VALUES
 
@@ -50,6 +53,7 @@ SSL_CTX_get_timeout() returns the currently set timeout value.
 L<ssl(3)|ssl(3)>,
 L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>,
 L<SSL_SESSION_get_time(3)|SSL_SESSION_get_time(3)>,
-L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)>
+L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)>,
+L<SSL_get_default_timeout(3)|SSL_get_default_timeout(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod
new file mode 100644
index 0000000000..29d1f8a6fb
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod
@@ -0,0 +1,170 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_tmp_dh_callback, SSL_CTX_set_tmp_dh, SSL_set_tmp_dh_callback, SSL_set_tmp_dh - handle DH keys for ephemeral key exchange
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_tmp_dh_callback(SSL_CTX *ctx,
+            DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength));
+ long SSL_CTX_set_tmp_dh(SSL_CTX *ctx, DH *dh);
+
+ void SSL_set_tmp_dh_callback(SSL_CTX *ctx,
+            DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength));
+ long SSL_set_tmp_dh(SSL *ssl, DH *dh)
+
+ DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength));
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_tmp_dh_callback() sets the callback function for B<ctx> to be
+used when a DH parameters are required to B<tmp_dh_callback>.
+The callback is inherited by all B<ssl> objects created from B<ctx>.
+
+SSL_CTX_set_tmp_dh() sets DH parameters to be used to be B<dh>.
+The key is inherited by all B<ssl> objects created from B<ctx>.
+
+SSL_set_tmp_dh_callback() sets the callback only for B<ssl>.
+
+SSL_set_tmp_dh() sets the parameters only for B<ssl>.
+
+These functions apply to SSL/TLS servers only.
+
+=head1 NOTES
+
+When using a cipher with RSA authentication, an ephemeral DH key exchange
+can take place. Ciphers with DSA keys always use ephemeral DH keys as well.
+In these cases, the session data are negotiated using the
+ephemeral/temporary DH key and the key supplied and certified
+by the certificate chain is only used for signing.
+Anonymous ciphers (without a permanent server key) also use ephemeral DH keys.
+
+Using ephemeral DH key exchange yields forward secrecy, as the connection
+can only be decrypted, when the DH key is known. By generating a temporary
+DH key inside the server application that is lost when the application
+is left, it becomes impossible for an attacker to decrypt past sessions,
+even if he gets hold of the normal (certified) key, as this key was
+only used for signing.
+
+In order to perform a DH key exchange the server must use a DH group
+(DH parameters) and generate a DH key. The server will always generate a new
+DH key during the negotiation, when the DH parameters are supplied via
+callback and/or when the SSL_OP_SINGLE_DH_USE option of
+L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)> is set. It will
+immediately create a DH key, when DH parameters are supplied via
+SSL_CTX_set_tmp_dh() and SSL_OP_SINGLE_DH_USE is not set. In this case,
+it may happen that a key is generated on initialization without later
+being needed, while on the other hand the computer time during the
+negotiation is being saved.
+
+If "strong" primes were used to generate the DH parameters, it is not strictly
+necessary to generate a new key for each handshake but it does improve forward
+secrecy. If it is not assured, that "strong" primes were used (see especially
+the section about DSA parameters below), SSL_OP_SINGLE_DH_USE must be used
+in order to prevent small subgroup attacks. Always using SSL_OP_SINGLE_DH_USE
+has an impact on the computer time needed during negotiation, but it is not
+very large, so application authors/users should consider to always enable
+this option.
+
+As generating DH parameters is extremely time consuming, an application
+should not generate the parameters on the fly but supply the parameters.
+DH parameters can be reused, as the actual key is newly generated during
+the negotiation. The risk in reusing DH parameters is that an attacker
+may specialize on a very often used DH group. Applications should therefore
+generate their own DH parameters during the installation process using the
+openssl L<dhparam(1)|dhparam(1)> application. In order to reduce the computer
+time needed for this generation, it is possible to use DSA parameters
+instead (see L<dhparam(1)|dhparam(1)>), but in this case SSL_OP_SINGLE_DH_USE
+is mandatory.
+
+Application authors may compile in DH parameters. Files dh512.pem,
+dh1024.pem, dh2048.pem, and dh4096 in the 'apps' directory of current
+version of the OpenSSL distribution contain the 'SKIP' DH parameters,
+which use safe primes and were generated verifiably pseudo-randomly.
+These files can be converted into C code using the B<-C> option of the
+L<dhparam(1)|dhparam(1)> application.
+Authors may also generate their own set of parameters using
+L<dhparam(1)|dhparam(1)>, but a user may not be sure how the parameters were
+generated. The generation of DH parameters during installation is therefore
+recommended.
+
+An application may either directly specify the DH parameters or
+can supply the DH parameters via a callback function. The callback approach
+has the advantage, that the callback may supply DH parameters for different
+key lengths.
+
+The B<tmp_dh_callback> is called with the B<keylength> needed and
+the B<is_export> information. The B<is_export> flag is set, when the
+ephemeral DH key exchange is performed with an export cipher.
+
+=head1 EXAMPLES
+
+Handle DH parameters for key lengths of 512 and 1024 bits. (Error handling
+partly left out.)
+
+ ...
+ /* Set up ephemeral DH stuff */
+ DH *dh_512 = NULL;
+ DH *dh_1024 = NULL;
+ FILE *paramfile;
+
+ ...
+ /* "openssl dhparam -out dh_param_512.pem -2 512" */
+ paramfile = fopen("dh_param_512.pem", "r");
+ if (paramfile) {
+   dh_512 = PEM_read_DHparams(paramfile, NULL, NULL, NULL);
+   fclose(paramfile);
+ }
+ /* "openssl dhparam -out dh_param_1024.pem -2 1024" */
+ paramfile = fopen("dh_param_1024.pem", "r");
+ if (paramfile) {
+   dh_1024 = PEM_read_DHparams(paramfile, NULL, NULL, NULL);
+   fclose(paramfile);
+ }
+ ...
+
+ /* "openssl dhparam -C -2 512" etc... */
+ DH *get_dh512() { ... }
+ DH *get_dh1024() { ... }
+
+ DH *tmp_dh_callback(SSL *s, int is_export, int keylength)
+ {
+    DH *dh_tmp=NULL;
+
+    switch (keylength) {
+    case 512:
+      if (!dh_512)
+        dh_512 = get_dh512();
+      dh_tmp = dh_512;
+      break;
+    case 1024:
+      if (!dh_1024) 
+        dh_1024 = get_dh1024();
+      dh_tmp = dh_1024;
+      break;
+    default:
+      /* Generating a key on the fly is very costly, so use what is there */
+      setup_dh_parameters_like_above();
+    }
+    return(dh_tmp);
+ }
+
+=head1 RETURN VALUES
+
+SSL_CTX_set_tmp_dh_callback() and SSL_set_tmp_dh_callback() do not return
+diagnostic output.
+
+SSL_CTX_set_tmp_dh() and SSL_set_tmp_dh() do return 1 on success and 0
+on failure. Check the error queue to find out the reason of failure.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>,
+L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>,
+L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>,
+L<ciphers(1)|ciphers(1)>, L<dhparam(1)|dhparam(1)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod
new file mode 100644
index 0000000000..f85775927d
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod
@@ -0,0 +1,166 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_tmp_rsa_callback, SSL_CTX_set_tmp_rsa, SSL_CTX_need_tmp_rsa, SSL_set_tmp_rsa_callback, SSL_set_tmp_rsa, SSL_need_tmp_rsa - handle RSA keys for ephemeral key exchange
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_tmp_rsa_callback(SSL_CTX *ctx,
+            RSA *(*tmp_rsa_callback)(SSL *ssl, int is_export, int keylength));
+ long SSL_CTX_set_tmp_rsa(SSL_CTX *ctx, RSA *rsa);
+ long SSL_CTX_need_tmp_rsa(SSL_CTX *ctx);
+
+ void SSL_set_tmp_rsa_callback(SSL_CTX *ctx,
+            RSA *(*tmp_rsa_callback)(SSL *ssl, int is_export, int keylength));
+ long SSL_set_tmp_rsa(SSL *ssl, RSA *rsa)
+ long SSL_need_tmp_rsa(SSL *ssl)
+
+ RSA *(*tmp_rsa_callback)(SSL *ssl, int is_export, int keylength));
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_tmp_rsa_callback() sets the callback function for B<ctx> to be
+used when a temporary/ephemeral RSA key is required to B<tmp_rsa_callback>.
+The callback is inherited by all SSL objects newly created from B<ctx>
+with <SSL_new(3)|SSL_new(3)>. Already created SSL objects are not affected.
+
+SSL_CTX_set_tmp_rsa() sets the temporary/ephemeral RSA key to be used to be
+B<rsa>. The key is inherited by all SSL objects newly created from B<ctx>
+with <SSL_new(3)|SSL_new(3)>. Already created SSL objects are not affected.
+
+SSL_CTX_need_tmp_rsa() returns 1, if a temporary/ephemeral RSA key is needed
+for RSA-based strength-limited 'exportable' ciphersuites because a RSA key
+with a keysize larger than 512 bits is installed.
+
+SSL_set_tmp_rsa_callback() sets the callback only for B<ssl>.
+
+SSL_set_tmp_rsa() sets the key only for B<ssl>.
+
+SSL_need_tmp_rsa() returns 1, if a temporary/ephemeral RSA key is needed,
+for RSA-based strength-limited 'exportable' ciphersuites because a RSA key
+with a keysize larger than 512 bits is installed.
+
+These functions apply to SSL/TLS servers only.
+
+=head1 NOTES
+
+When using a cipher with RSA authentication, an ephemeral RSA key exchange
+can take place. In this case the session data are negotiated using the
+ephemeral/temporary RSA key and the RSA key supplied and certified
+by the certificate chain is only used for signing.
+
+Under previous export restrictions, ciphers with RSA keys shorter (512 bits)
+than the usual key length of 1024 bits were created. To use these ciphers
+with RSA keys of usual length, an ephemeral key exchange must be performed,
+as the normal (certified) key cannot be directly used.
+
+Using ephemeral RSA key exchange yields forward secrecy, as the connection
+can only be decrypted, when the RSA key is known. By generating a temporary
+RSA key inside the server application that is lost when the application
+is left, it becomes impossible for an attacker to decrypt past sessions,
+even if he gets hold of the normal (certified) RSA key, as this key was
+used for signing only. The downside is that creating a RSA key is
+computationally expensive.
+
+Additionally, the use of ephemeral RSA key exchange is only allowed in
+the TLS standard, when the RSA key can be used for signing only, that is
+for export ciphers. Using ephemeral RSA key exchange for other purposes
+violates the standard and can break interoperability with clients.
+It is therefore strongly recommended to not use ephemeral RSA key
+exchange and use EDH (Ephemeral Diffie-Hellman) key exchange instead
+in order to achieve forward secrecy (see
+L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
+
+On OpenSSL servers ephemeral RSA key exchange is therefore disabled by default
+and must be explicitly enabled  using the SSL_OP_EPHEMERAL_RSA option of
+L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>, violating the TLS/SSL
+standard. When ephemeral RSA key exchange is required for export ciphers,
+it will automatically be used without this option!
+
+An application may either directly specify the key or can supply the key via
+a callback function. The callback approach has the advantage, that the
+callback may generate the key only in case it is actually needed. As the
+generation of a RSA key is however costly, it will lead to a significant
+delay in the handshake procedure.  Another advantage of the callback function
+is that it can supply keys of different size (e.g. for SSL_OP_EPHEMERAL_RSA
+usage) while the explicit setting of the key is only useful for key size of
+512 bits to satisfy the export restricted ciphers and does give away key length
+if a longer key would be allowed.
+
+The B<tmp_rsa_callback> is called with the B<keylength> needed and
+the B<is_export> information. The B<is_export> flag is set, when the
+ephemeral RSA key exchange is performed with an export cipher.
+
+=head1 EXAMPLES
+
+Generate temporary RSA keys to prepare ephemeral RSA key exchange. As the
+generation of a RSA key costs a lot of computer time, they saved for later
+reuse. For demonstration purposes, two keys for 512 bits and 1024 bits
+respectively are generated.
+
+ ...
+ /* Set up ephemeral RSA stuff */
+ RSA *rsa_512 = NULL;
+ RSA *rsa_1024 = NULL;
+
+ rsa_512 = RSA_generate_key(512,RSA_F4,NULL,NULL);
+ if (rsa_512 == NULL)
+     evaluate_error_queue();
+
+ rsa_1024 = RSA_generate_key(1024,RSA_F4,NULL,NULL);
+ if (rsa_1024 == NULL)
+   evaluate_error_queue();
+
+ ...
+
+ RSA *tmp_rsa_callback(SSL *s, int is_export, int keylength)
+ {
+    RSA *rsa_tmp=NULL;
+
+    switch (keylength) {
+    case 512:
+      if (rsa_512)
+        rsa_tmp = rsa_512;
+      else { /* generate on the fly, should not happen in this example */
+        rsa_tmp = RSA_generate_key(keylength,RSA_F4,NULL,NULL);
+        rsa_512 = rsa_tmp; /* Remember for later reuse */
+      }
+      break;
+    case 1024:
+      if (rsa_1024)
+        rsa_tmp=rsa_1024;
+      else
+        should_not_happen_in_this_example();
+      break;
+    default:
+      /* Generating a key on the fly is very costly, so use what is there */
+      if (rsa_1024)
+        rsa_tmp=rsa_1024;
+      else
+        rsa_tmp=rsa_512; /* Use at least a shorter key */
+    }
+    return(rsa_tmp);
+ }
+
+=head1 RETURN VALUES
+
+SSL_CTX_set_tmp_rsa_callback() and SSL_set_tmp_rsa_callback() do not return
+diagnostic output.
+
+SSL_CTX_set_tmp_rsa() and SSL_set_tmp_rsa() do return 1 on success and 0
+on failure. Check the error queue to find out the reason of failure.
+
+SSL_CTX_need_tmp_rsa() and SSL_need_tmp_rsa() return 1 if a temporary
+RSA key is needed and 0 otherwise.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>,
+L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>,
+L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>,
+L<SSL_new(3)|SSL_new(3)>, L<ciphers(1)|ciphers(1)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_verify.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_verify.pod
index fc0b76118f..5bb21ca535 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_verify.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_verify.pod
@@ -59,14 +59,14 @@ The handshake will be continued regardless of the verification result.
 
 B<Server mode:> the server sends a client certificate request to the client.
 The certificate returned (if any) is checked. If the verification process
-fails as indicated by B<verify_callback>, the TLS/SSL handshake is
+fails, the TLS/SSL handshake is
 immediately terminated with an alert message containing the reason for
 the verification failure.
 The behaviour can be controlled by the additional
 SSL_VERIFY_FAIL_IF_NO_PEER_CERT and SSL_VERIFY_CLIENT_ONCE flags.
 
 B<Client mode:> the server certificate is verified. If the verification process
-fails as indicated by B<verify_callback>, the TLS/SSL handshake is
+fails, the TLS/SSL handshake is
 immediately terminated with an alert message containing the reason for
 the verification failure. If no server certificate is sent, because an
 anonymous cipher is used, SSL_VERIFY_PEER is ignored.
@@ -92,6 +92,15 @@ B<Client mode:> ignored
 Exactly one of the B<mode> flags SSL_VERIFY_NONE and SSL_VERIFY_PEER must be
 set at any time.
 
+The actual verification procedure is performed either using the built-in
+verification procedure or using another application provided verification
+function set with
+L<SSL_CTX_set_cert_verify_callback(3)|SSL_CTX_set_cert_verify_callback(3)>.
+The following descriptions apply in the case of the built-in procedure. An
+application provided procedure also has access to the verify depth information
+and the verify_callback() function, but the way this information is used
+may be different.
+
 SSL_CTX_set_verify_depth() and SSL_set_verify_depth() set the limit up
 to which depth certificates in a chain are used during the verification
 procedure. If the certificate chain is longer than allowed, the certificates
@@ -278,6 +287,7 @@ L<SSL_CTX_get_verify_mode(3)|SSL_CTX_get_verify_mode(3)>,
 L<SSL_get_verify_result(3)|SSL_get_verify_result(3)>,
 L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>,
 L<SSL_get_peer_certificate(3)|SSL_get_peer_certificate(3)>,
+L<SSL_CTX_set_cert_verify_callback(3)|SSL_CTX_set_cert_verify_callback(3)>,
 L<SSL_get_ex_data_X509_STORE_CTX_idx(3)|SSL_get_ex_data_X509_STORE_CTX_idx(3)>,
 L<SSL_get_ex_new_index(3)|SSL_get_ex_new_index(3)>
 
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_use_certificate.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_use_certificate.pod
index 3b2fe6fc50..b8868f18bf 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_use_certificate.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_use_certificate.pod
@@ -149,6 +149,7 @@ L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>, L<SSL_clear(3)|SSL_clear(3)>,
 L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>,
 L<SSL_CTX_set_default_passwd_cb(3)|SSL_CTX_set_default_passwd_cb(3)>,
 L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>,
+L<SSL_CTX_set_client_cert_cb(3)|SSL_CTX_set_client_cert_cb(3)>,
 L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_SESSION_free.pod b/src/lib/libssl/src/doc/ssl/SSL_SESSION_free.pod
index df30ccbb32..558de01df9 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_SESSION_free.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_SESSION_free.pod
@@ -16,10 +16,40 @@ SSL_SESSION_free() decrements the reference count of B<session> and removes
 the B<SSL_SESSION> structure pointed to by B<session> and frees up the allocated
 memory, if the the reference count has reached 0.
 
+=head1 NOTES
+
+SSL_SESSION objects are allocated, when a TLS/SSL handshake operation
+is successfully completed. Depending on the settings, see
+L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>,
+the SSL_SESSION objects are internally referenced by the SSL_CTX and
+linked into its session cache. SSL objects may be using the SSL_SESSION object;
+as a session may be reused, several SSL objects may be using one SSL_SESSION
+object at the same time. It is therefore crucial to keep the reference
+count (usage information) correct and not delete a SSL_SESSION object
+that is still used, as this may lead to program failures due to
+dangling pointers. These failures may also appear delayed, e.g.
+when an SSL_SESSION object was completely freed as the reference count
+incorrectly became 0, but it is still referenced in the internal
+session cache and the cache list is processed during a
+L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)> operation.
+
+SSL_SESSION_free() must only be called for SSL_SESSION objects, for
+which the reference count was explicitly incremented (e.g.
+by calling SSL_get1_session(), see L<SSL_get_session(3)|SSL_get_session(3)>)
+or when the SSL_SESSION object was generated outside a TLS handshake
+operation, e.g. by using L<d2i_SSL_SESSION(3)|d2i_SSL_SESSION(3)>.
+It must not be called on other SSL_SESSION objects, as this would cause
+incorrect reference counts and therefore program failures.
+
 =head1 RETURN VALUES
 
 SSL_SESSION_free() does not provide diagnostic information.
 
-L<ssl(3)|ssl(3)>, L<SSL_get_session(3)|SSL_get_session(3)>
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_get_session(3)|SSL_get_session(3)>,
+L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>,
+L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)>,
+ L<d2i_SSL_SESSION(3)|d2i_SSL_SESSION(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_SESSION_get_time.pod b/src/lib/libssl/src/doc/ssl/SSL_SESSION_get_time.pod
index cd33b73aa3..ea3c2bcfe6 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_SESSION_get_time.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_SESSION_get_time.pod
@@ -58,6 +58,7 @@ If any of the function is passed the NULL pointer for the session B<s>,
 =head1 SEE ALSO
 
 L<ssl(3)|ssl(3)>,
-L<SSL_CTX_set_timeout(3)|SSL_CTX_set_timeout(3)>
+L<SSL_CTX_set_timeout(3)|SSL_CTX_set_timeout(3)>,
+L<SSL_get_default_timeout(3)|SSL_get_default_timeout(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_accept.pod b/src/lib/libssl/src/doc/ssl/SSL_accept.pod
index 86f980de41..ac6caf9baa 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_accept.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_accept.pod
@@ -37,11 +37,6 @@ nothing is to be done, but select() can be used to check for the required
 condition. When using a buffering BIO, like a BIO pair, data must be written
 into or retrieved out of the BIO before being able to continue.
 
-When using a generic method (see L<SSL_CTX_new(3)|SSL_CTX_new(3)>), it
-is necessary to call SSL_set_accept_state()
-before calling SSL_accept() to explicitly switch the B<ssl> to server
-mode.
-
 =head1 RETURN VALUES
 
 The following return values can occur:
diff --git a/src/lib/libssl/src/doc/ssl/SSL_alert_type_string.pod b/src/lib/libssl/src/doc/ssl/SSL_alert_type_string.pod
new file mode 100644
index 0000000000..94e28cc307
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_alert_type_string.pod
@@ -0,0 +1,228 @@
+=pod
+
+=head1 NAME
+
+SSL_alert_type_string, SSL_alert_type_string_long, SSL_alert_desc_string, SSL_alert_desc_string_long - get textual description of alert information
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ const char *SSL_alert_type_string(int value);
+ const char *SSL_alert_type_string_long(int value);
+
+ const char *SSL_alert_desc_string(int value);
+ const char *SSL_alert_desc_string_long(int value);
+
+=head1 DESCRIPTION
+
+SSL_alert_type_string() returns a one letter string indicating the
+type of the alert specified by B<value>.
+
+SSL_alert_type_string_long() returns a string indicating the type of the alert
+specified by B<value>.
+
+SSL_alert_desc_string() returns a two letter string as a short form
+describing the reason of the alert specified by B<value>.
+
+SSL_alert_desc_string_long() returns a string describing the reason
+of the alert specified by B<value>.
+
+=head1 NOTES
+
+When one side of an SSL/TLS communication wants to inform the peer about
+a special situation, it sends an alert. The alert is sent as a special message
+and does not influence the normal data stream (unless its contents results
+in the communication being canceled).
+
+A warning alert is sent, when a non-fatal error condition occurs. The
+"close notify" alert is sent as a warning alert. Other examples for
+non-fatal errors are certificate errors ("certificate expired",
+"unsupported certificate"), for which a warning alert may be sent.
+(The sending party may however decide to send a fatal error.) The
+receiving side may cancel the connection on reception of a warning
+alert on it discretion.
+
+Several alert messages must be sent as fatal alert messages as specified
+by the TLS RFC. A fatal alert always leads to a connection abort.
+
+=head1 RETURN VALUES
+
+The following strings can occur for SSL_alert_type_string() or
+SSL_alert_type_string_long():
+
+=over 4
+
+=item "W"/"warning"
+
+=item "F"/"fatal"
+
+=item "U"/"unknown"
+
+This indicates that no support is available for this alert type.
+Probably B<value> does not contain a correct alert message.
+
+=back
+
+The following strings can occur for SSL_alert_desc_string() or
+SSL_alert_desc_string_long():
+
+=over 4
+
+=item "CN"/"close notify"
+
+The connection shall be closed. This is a warning alert.
+
+=item "UM"/"unexpected message"
+
+An inappropriate message was received. This alert is always fatal
+and should never be observed in communication between proper
+implementations.
+
+=item "BM"/"bad record mac"
+
+This alert is returned if a record is received with an incorrect
+MAC. This message is always fatal.
+
+=item "DF"/"decompression failure"
+
+The decompression function received improper input (e.g. data
+that would expand to excessive length). This message is always
+fatal.
+
+=item "HF"/"handshake failure"
+
+Reception of a handshake_failure alert message indicates that the
+sender was unable to negotiate an acceptable set of security
+parameters given the options available. This is a fatal error.
+
+=item "NC"/"no certificate"
+
+A client, that was asked to send a certificate, does not send a certificate
+(SSLv3 only).
+
+=item "BC"/"bad certificate"
+
+A certificate was corrupt, contained signatures that did not
+verify correctly, etc
+
+=item "UC"/"unsupported certificate"
+
+A certificate was of an unsupported type.
+
+=item "CR"/"certificate revoked"
+
+A certificate was revoked by its signer.
+
+=item "CE"/"certificate expired"
+
+A certificate has expired or is not currently valid.
+
+=item "CU"/"certificate unknown"
+
+Some other (unspecified) issue arose in processing the
+certificate, rendering it unacceptable.
+
+=item "IP"/"illegal parameter"
+
+A field in the handshake was out of range or inconsistent with
+other fields. This is always fatal.
+
+=item "DC"/"decryption failed"
+
+A TLSCiphertext decrypted in an invalid way: either it wasn't an
+even multiple of the block length or its padding values, when
+checked, weren't correct. This message is always fatal.
+
+=item "RO"/"record overflow"
+
+A TLSCiphertext record was received which had a length more than
+2^14+2048 bytes, or a record decrypted to a TLSCompressed record
+with more than 2^14+1024 bytes. This message is always fatal.
+
+=item "CA"/"unknown CA"
+
+A valid certificate chain or partial chain was received, but the
+certificate was not accepted because the CA certificate could not
+be located or couldn't be matched with a known, trusted CA.  This
+message is always fatal.
+
+=item "AD"/"access denied"
+
+A valid certificate was received, but when access control was
+applied, the sender decided not to proceed with negotiation.
+This message is always fatal.
+
+=item "DE"/"decode error"
+
+A message could not be decoded because some field was out of the
+specified range or the length of the message was incorrect. This
+message is always fatal.
+
+=item "CY"/"decrypt error"
+
+A handshake cryptographic operation failed, including being
+unable to correctly verify a signature, decrypt a key exchange,
+or validate a finished message.
+
+=item "ER"/"export restriction"
+
+A negotiation not in compliance with export restrictions was
+detected; for example, attempting to transfer a 1024 bit
+ephemeral RSA key for the RSA_EXPORT handshake method. This
+message is always fatal.
+
+=item "PV"/"protocol version"
+
+The protocol version the client has attempted to negotiate is
+recognized, but not supported. (For example, old protocol
+versions might be avoided for security reasons). This message is
+always fatal.
+
+=item "IS"/"insufficient security"
+
+Returned instead of handshake_failure when a negotiation has
+failed specifically because the server requires ciphers more
+secure than those supported by the client. This message is always
+fatal.
+
+=item "IE"/"internal error"
+
+An internal error unrelated to the peer or the correctness of the
+protocol makes it impossible to continue (such as a memory
+allocation failure). This message is always fatal.
+
+=item "US"/"user canceled"
+
+This handshake is being canceled for some reason unrelated to a
+protocol failure. If the user cancels an operation after the
+handshake is complete, just closing the connection by sending a
+close_notify is more appropriate. This alert should be followed
+by a close_notify. This message is generally a warning.
+
+=item "NR"/"no renegotiation"
+
+Sent by the client in response to a hello request or by the
+server in response to a client hello after initial handshaking.
+Either of these would normally lead to renegotiation; when that
+is not appropriate, the recipient should respond with this alert;
+at that point, the original requester can decide whether to
+proceed with the connection. One case where this would be
+appropriate would be where a server has spawned a process to
+satisfy a request; the process might receive security parameters
+(key length, authentication, etc.) at startup and it might be
+difficult to communicate changes to these parameters after that
+point. This message is always a warning.
+
+=item "UK"/"unknown"
+
+This indicates that no description is available for this alert type.
+Probably B<value> does not contain a correct alert message.
+
+=back
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_CTX_set_info_callback(3)|SSL_CTX_set_info_callback(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_clear.pod b/src/lib/libssl/src/doc/ssl/SSL_clear.pod
index 8b735d81dc..8e077e31c9 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_clear.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_clear.pod
@@ -25,6 +25,25 @@ if L<SSL_shutdown(3)|SSL_shutdown(3)> was not called for the connection
 or at least L<SSL_set_shutdown(3)|SSL_set_shutdown(3)> was used to
 set the SSL_SENT_SHUTDOWN state.
 
+If a session was closed cleanly, the session object will be kept and all
+settings corresponding. This explicitly means, that e.g. the special method
+used during the session will be kept for the next handshake. So if the
+session was a TLSv1 session, a SSL client object will use a TLSv1 client
+method for the next handshake and a SSL server object will use a TLSv1
+server method, even if SSLv23_*_methods were chosen on startup. This
+will might lead to connection failures (see L<SSL_new(3)|SSL_new(3)>)
+for a description of the method's properties.
+
+=head1 WARNINGS
+
+SSL_clear() resets the SSL object to allow for another connection. The
+reset operation however keeps several settings of the last sessions
+(some of these settings were made automatically during the last
+handshake). It only makes sense when opening a new session (or reusing
+an old one) with the same peer that shares these settings.
+SSL_clear() is not a short form for the sequence
+L<SSL_free(3)|SSL_free(3)>; L<SSL_new(3)|SSL_new(3)>; .
+
 =head1 RETURN VALUES
 
 The following return values can occur:
@@ -44,6 +63,7 @@ The SSL_clear() operation was successful.
 
 L<SSL_new(3)|SSL_new(3)>, L<SSL_free(3)|SSL_free(3)>,
 L<SSL_shutdown(3)|SSL_shutdown(3)>, L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>,
-L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>, L<ssl(3)|ssl(3)>
+L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>, L<ssl(3)|ssl(3)>,
+L<SSL_CTX_set_client_cert_cb(3)|SSL_CTX_set_client_cert_cb(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_connect.pod b/src/lib/libssl/src/doc/ssl/SSL_connect.pod
index bcc167745b..766f1876aa 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_connect.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_connect.pod
@@ -34,11 +34,6 @@ nothing is to be done, but select() can be used to check for the required
 condition. When using a buffering BIO, like a BIO pair, data must be written
 into or retrieved out of the BIO before being able to continue.
 
-When using a generic method (see L<SSL_CTX_new(3)|SSL_CTX_new(3)>), it
-is necessary to call L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>
-before calling SSL_connect() to explicitly switch the B<ssl> to client
-mode.
-
 =head1 RETURN VALUES
 
 The following return values can occur:
diff --git a/src/lib/libssl/src/doc/ssl/SSL_get_SSL_CTX.pod b/src/lib/libssl/src/doc/ssl/SSL_get_SSL_CTX.pod
new file mode 100644
index 0000000000..52d0227b19
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_get_SSL_CTX.pod
@@ -0,0 +1,26 @@
+=pod
+
+=head1 NAME
+
+SSL_get_SSL_CTX - get the SSL_CTX from which an SSL is created
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ SSL_CTX *SSL_get_SSL_CTX(SSL *ssl);
+
+=head1 DESCRIPTION
+
+SSL_get_SSL_CTX() returns a pointer to the SSL_CTX object, from which
+B<ssl> was created with L<SSL_new(3)|SSL_new(3)>.
+
+=head1 RETURN VALUES
+
+The pointer to the SSL_CTX object is returned.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_get_client_CA_list.pod b/src/lib/libssl/src/doc/ssl/SSL_get_client_CA_list.pod
index 40e01cf9c8..5693fdebb2 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_get_client_CA_list.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_get_client_CA_list.pod
@@ -47,6 +47,7 @@ the server did not send a list of CAs (client mode).
 =head1 SEE ALSO
 
 L<ssl(3)|ssl(3)>,
-L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)>
+L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)>,
+L<SSL_CTX_set_client_cert_cb(3)|SSL_CTX_set_client_cert_cb(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_get_default_timeout.pod b/src/lib/libssl/src/doc/ssl/SSL_get_default_timeout.pod
new file mode 100644
index 0000000000..8d43b31345
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_get_default_timeout.pod
@@ -0,0 +1,41 @@
+=pod
+
+=head1 NAME
+
+SSL_get_default_timeout - get default session timeout value
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ long SSL_get_default_timeout(SSL *ssl);
+
+=head1 DESCRIPTION
+
+SSL_get_default_timeout() returns the default timeout value assigned to
+SSL_SESSION objects negotiated for the protocol valid for B<ssl>.
+
+=head1 NOTES
+
+Whenever a new session is negotiated, it is assigned a timeout value,
+after which it will not be accepted for session reuse. If the timeout
+value was not explicitly set using
+L<SSL_CTX_set_timeout(3)|SSL_CTX_set_timeout(3)>, the hardcoded default
+timeout for the protocol will be used.
+
+SSL_get_default_timeout() return this hardcoded value, which is 300 seconds
+for all currently supported protocols (SSLv2, SSLv3, and TLSv1).
+
+=head1 RETURN VALUES
+
+See description.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>,
+L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>,
+L<SSL_SESSION_get_time(3)|SSL_SESSION_get_time(3)>,
+L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)>,
+L<SSL_get_default_timeout(3)|SSL_get_default_timeout(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_get_error.pod b/src/lib/libssl/src/doc/ssl/SSL_get_error.pod
index d95eec78aa..f700bf0ace 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_get_error.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_get_error.pod
@@ -69,13 +69,13 @@ to read data.  This is mainly because TLS/SSL handshakes may occur at any
 time during the protocol (initiated by either the client or the server);
 SSL_read(), SSL_peek(), and SSL_write() will handle any pending handshakes.
 
-=item SSL_ERROR_WANT_CONNECT
+=item SSL_ERROR_WANT_CONNECT, SSL_ERROR_WANT_ACCEPT
 
 The operation did not complete; the same TLS/SSL I/O function should be
 called again later. The underlying BIO was not connected yet to the peer
-and the call would block in connect(). The SSL function should be
-called again when the connection is established. This messages can only
-appear with a BIO_s_connect() BIO.
+and the call would block in connect()/accept(). The SSL function should be
+called again when the connection is established. These messages can only
+appear with a BIO_s_connect() or BIO_s_accept() BIO, respectively.
 In order to find out, when the connection has been successfully established,
 on many platforms select() or poll() for writing on the socket file descriptor
 can be used.
diff --git a/src/lib/libssl/src/doc/ssl/SSL_get_peer_certificate.pod b/src/lib/libssl/src/doc/ssl/SSL_get_peer_certificate.pod
index 18d1db5183..60635a9660 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_get_peer_certificate.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_get_peer_certificate.pod
@@ -19,7 +19,7 @@ peer presented. If the peer did not present a certificate, NULL is returned.
 
 Due to the protocol definition, a TLS/SSL server will always send a
 certificate, if present. A client will only send a certificate when
-explicitely requested to do so by the server (see
+explicitly requested to do so by the server (see
 L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>). If an anonymous cipher
 is used, no certificates are sent.
 
diff --git a/src/lib/libssl/src/doc/ssl/SSL_get_session.pod b/src/lib/libssl/src/doc/ssl/SSL_get_session.pod
index a0266e2ac6..dd9aba40b6 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_get_session.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_get_session.pod
@@ -37,8 +37,16 @@ if the session is valid, it can be removed at any time due to timeout
 during L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)>.
 
 If the data is to be kept, SSL_get1_session() will increment the reference
-count and the session will stay in memory until explicitly freed with
-L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>, regardless of its state.
+count, so that the session will not be implicitly removed by other operations
+but stays in memory. In order to remove the session
+L<SSL_SESSION_free(3)|SSL_SESSION_free(3)> must be explicitly called once
+to decrement the reference count again.
+
+SSL_SESSION objects keep internal link information about the session cache
+list, when being inserted into one SSL_CTX object's session cache.
+One SSL_SESSION object, regardless of its reference count, must therefore
+only be used with one SSL_CTX object (and the SSL objects created
+from this SSL_CTX object).
 
 =head1 RETURN VALUES
 
diff --git a/src/lib/libssl/src/doc/ssl/SSL_new.pod b/src/lib/libssl/src/doc/ssl/SSL_new.pod
index 3b084e867d..25300e978f 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_new.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_new.pod
@@ -38,6 +38,7 @@ The return value points to an allocated SSL structure.
 
 L<SSL_free(3)|SSL_free(3)>, L<SSL_clear(3)|SSL_clear(3)>,
 L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>,
+L<SSL_get_SSL_CTX(3)|SSL_get_SSL_CTX(3)>,
 L<ssl(3)|ssl(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_read.pod b/src/lib/libssl/src/doc/ssl/SSL_read.pod
index cc7aa1a547..f6c37f77e4 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_read.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_read.pod
@@ -25,11 +25,10 @@ the SSL_read() operation. The behaviour of SSL_read() depends on the
 underlying BIO. 
 
 For the transparent negotiation to succeed, the B<ssl> must have been
-initialized to client or server mode. This is not the case if a generic
-method is being used (see L<SSL_CTX_new(3)|SSL_CTX_new(3)>, so that
+initialized to client or server mode. This is being done by calling
 L<SSL_set_connect_state(3)|SSL_set_connect_state(3)> or SSL_set_accept_state()
-must be used before the first call to an SSL_read() or
-L<SSL_write(3)|SSL_write(3)> function).
+before the first call to an SSL_read() or L<SSL_write(3)|SSL_write(3)>
+function.
 
 SSL_read() works based on the SSL/TLS records. The data are received in
 records (with a maximum record size of 16kB for SSLv3/TLSv1). Only when a
@@ -84,9 +83,20 @@ bytes actually read from the TLS/SSL connection.
 
 =item 0
 
-The read operation was not successful, probably because no data was
-available. Call SSL_get_error() with the return value B<ret> to find out,
-whether an error occurred.
+The read operation was not successful. The reason may either be a clean
+shutdown due to a "close notify" alert sent by the peer (in which case
+the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state is set
+(see L<SSL_shutdown(3)|SSL_shutdown(3)>,
+L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>). It is also possible, that
+the peer simply shut down the underlying transport and the shutdown is
+incomplete. Call SSL_get_error() with the return value B<ret> to find out,
+whether an error occurred or the connection was shut down cleanly
+(SSL_ERROR_ZERO_RETURN).
+
+SSLv2 (deprecated) does not support a shutdown alert protocol, so it can
+only be detected, whether the underlying connection was closed. It cannot
+be checked, whether the closure was initiated by the peer or by something
+else.
 
 =item E<lt>0
 
@@ -102,6 +112,7 @@ L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_write(3)|SSL_write(3)>,
 L<SSL_CTX_set_mode(3)|SSL_CTX_set_mode(3)>, L<SSL_CTX_new(3)|SSL_CTX_new(3)>,
 L<SSL_connect(3)|SSL_connect(3)>, L<SSL_accept(3)|SSL_accept(3)>
 L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>,
+L<SSL_shutdown(3)|SSL_shutdown(3)>, L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>,
 L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_rstate_string.pod b/src/lib/libssl/src/doc/ssl/SSL_rstate_string.pod
new file mode 100644
index 0000000000..bdb8a1fcd5
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_rstate_string.pod
@@ -0,0 +1,59 @@
+=pod
+
+=head1 NAME
+
+SSL_rstate_string, SSL_rstate_string_long - get textual description of state of an SSL object during read operation
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ const char *SSL_rstate_string(SSL *ssl);
+ const char *SSL_rstate_string_long(SSL *ssl);
+
+=head1 DESCRIPTION
+
+SSL_rstate_string() returns a 2 letter string indicating the current read state
+of the SSL object B<ssl>.
+
+SSL_rstate_string_long() returns a string indicating the current read state of
+the SSL object B<ssl>.
+
+=head1 NOTES
+
+When performing a read operation, the SSL/TLS engine must parse the record,
+consisting of header and body. When working in a blocking environment,
+SSL_rstate_string[_long]() should always return "RD"/"read done".
+
+This function should only seldom be needed in applications.
+
+=head1 RETURN VALUES
+
+SSL_rstate_string() and SSL_rstate_string_long() can return the following
+values:
+
+=over 4
+
+=item "RH"/"read header"
+
+The header of the record is being evaluated.
+
+=item "RB"/"read body"
+
+The body of the record is being evaluated.
+
+=item "RD"/"read done"
+
+The record has been completely processed.
+
+=item "unknown"/"unknown"
+
+The read state is unknown. This should never happen.
+
+=back
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_session_reused.pod b/src/lib/libssl/src/doc/ssl/SSL_session_reused.pod
new file mode 100644
index 0000000000..da7d06264d
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_session_reused.pod
@@ -0,0 +1,45 @@
+=pod
+
+=head1 NAME
+
+SSL_session_reused - query whether a reused session was negotiated during handshake
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_session_reused(SSL *ssl);
+
+=head1 DESCRIPTION
+
+Query, whether a reused session was negotiated during the handshake.
+
+=head1 NOTES
+
+During the negotiation, a client can propose to reuse a session. The server
+then looks up the session in its cache. If both client and server agree
+on the session, it will be reused and a flag is being set that can be
+queried by the application.
+
+=head1 RETURN VALUES
+
+The following return values can occur:
+
+=over 4
+
+=item 0
+
+A new session was negotiated.
+
+=item 1
+
+A session was reused.
+
+=back
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_set_session(3)|SSL_set_session(3)>,
+L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_set_connect_state.pod b/src/lib/libssl/src/doc/ssl/SSL_set_connect_state.pod
index a8c4463c64..7adf8adfed 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_set_connect_state.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_set_connect_state.pod
@@ -14,9 +14,9 @@ SSL_set_connect_state, SSL_get_accept_state - prepare SSL object to work in clie
 
 =head1 DESCRIPTION
 
-SSL_set_connect_state() B<ssl> to work in client mode.
+SSL_set_connect_state() sets B<ssl> to work in client mode.
 
-SSL_set_accept_state() B<ssl> to work in server mode.
+SSL_set_accept_state() sets B<ssl> to work in server mode.
 
 =head1 NOTES
 
@@ -27,12 +27,17 @@ server connections. (The method might have been changed with
 L<SSL_CTX_set_ssl_version(3)|SSL_CTX_set_ssl_version(3)> or
 SSL_set_ssl_method().)
 
-In order to successfully accomplish the handshake, the SSL routines need
-to know whether they should act in server or client mode. If the generic
-method was used, this is not clear from the method itself and must be set
-with either SSL_set_connect_state() or SSL_set_accept_state(). If these
-routines are not called, the default value set when L<SSL_new(3)|SSL_new(3)>
-is called is server mode.
+When beginning a new handshake, the SSL engine must know whether it must
+call the connect (client) or accept (server) routines. Even though it may
+be clear from the method chosen, whether client or server mode was
+requested, the handshake routines must be explicitly set.
+
+When using the L<SSL_connect(3)|SSL_connect(3)> or
+L<SSL_accept(3)|SSL_accept(3)> routines, the correct handshake
+routines are automatically set. When performing a transparent negotiation
+using L<SSL_write(3)|SSL_write(3)> or L<SSL_read(3)|SSL_read(3)>, the
+handshake routines must be explicitly set in advance using either
+SSL_set_connect_state() or SSL_set_accept_state().
 
 =head1 RETURN VALUES
 
@@ -42,6 +47,8 @@ information.
 =head1 SEE ALSO
 
 L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>, L<SSL_CTX_new(3)|SSL_CTX_new(3)>,
+L<SSL_connect(3)|SSL_connect(3)>, L<SSL_accept(3)|SSL_accept(3)>,
+L<SSL_write(3)|SSL_write(3)>, L<SSL_read(3)|SSL_read(3)>,
 L<SSL_CTX_set_ssl_version(3)|SSL_CTX_set_ssl_version(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_set_session.pod b/src/lib/libssl/src/doc/ssl/SSL_set_session.pod
index c4f7878579..5f54714ad8 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_set_session.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_set_session.pod
@@ -16,12 +16,21 @@ SSL_set_session() sets B<session> to be used when the TLS/SSL connection
 is to be established. SSL_set_session() is only useful for TLS/SSL clients.
 When the session is set, the reference count of B<session> is incremented
 by 1. If the session is not reused, the reference count is decremented
-again during SSL_connect().
+again during SSL_connect(). Whether the session was reused can be queried
+with the L<SSL_session_reused(3)|SSL_session_reused(3)> call.
 
 If there is already a session set inside B<ssl> (because it was set with
 SSL_set_session() before or because the same B<ssl> was already used for
 a connection), SSL_SESSION_free() will be called for that session.
 
+=head1 NOTES
+
+SSL_SESSION objects keep internal link information about the session cache
+list, when being inserted into one SSL_CTX object's session cache.
+One SSL_SESSION object, regardless of its reference count, must therefore
+only be used with one SSL_CTX object (and the SSL objects created
+from this SSL_CTX object).
+
 =head1 RETURN VALUES
 
 The following return values can occur:
@@ -41,6 +50,8 @@ The operation succeeded.
 =head1 SEE ALSO
 
 L<ssl(3)|ssl(3)>, L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>,
+L<SSL_get_session(3)|SSL_get_session(3)>,
+L<SSL_session_reused(3)|SSL_session_reused(3)>,
 L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_set_shutdown.pod b/src/lib/libssl/src/doc/ssl/SSL_set_shutdown.pod
index 6b196c1f15..6289e635d9 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_set_shutdown.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_set_shutdown.pod
@@ -46,7 +46,10 @@ The shutdown state of the connection is used to determine the state of
 the ssl session. If the session is still open, when
 L<SSL_clear(3)|SSL_clear(3)> or L<SSL_free(3)|SSL_free(3)> is called,
 it is considered bad and removed according to RFC2246.
-The actual condition for a correctly closed session is SSL_SENT_SHUTDOWN.
+The actual condition for a correctly closed session is SSL_SENT_SHUTDOWN
+(according to the TLS RFC, it is acceptable to only send the "close notify"
+alert but to not wait for the peer's answer, when the underlying connection
+is closed).
 SSL_set_shutdown() can be used to set this state without sending a
 close alert to the peer (see L<SSL_shutdown(3)|SSL_shutdown(3)>).
 
@@ -63,6 +66,7 @@ SSL_get_shutdown() returns the current setting.
 =head1 SEE ALSO
 
 L<ssl(3)|ssl(3)>, L<SSL_shutdown(3)|SSL_shutdown(3)>,
+L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>,
 L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_shutdown.pod b/src/lib/libssl/src/doc/ssl/SSL_shutdown.pod
index c4ae6704e7..6b5012be7a 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_shutdown.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_shutdown.pod
@@ -22,10 +22,52 @@ Whether the operation succeeds or not, the SSL_SENT_SHUTDOWN flag is set and
 a currently open session is considered closed and good and will be kept in the
 session cache for further reuse.
 
-The behaviour of SSL_shutdown() depends on the underlying BIO. 
+The shutdown procedure consists of 2 steps: the sending of the "close notify"
+shutdown alert and the reception of the peer's "close notify" shutdown
+alert. According to the TLS standard, it is acceptable for an application
+to only send its shutdown alert and then close the underlying connection
+without waiting for the peer's response (this way resources can be saved,
+as the process can already terminate or serve another connection).
+When the underlying connection shall be used for more communications, the
+complete shutdown procedure (bidirectional "close notify" alerts) must be
+performed, so that the peers stay synchronized.
+
+SSL_shutdown() supports both uni- and bidirectional shutdown by its 2 step
+behaviour.
+
+=over 4
+
+=item When the application is the first party to send the "close notify"
+alert, SSL_shutdown() will only send the alert and the set the
+SSL_SENT_SHUTDOWN flag (so that the session is considered good and will
+be kept in cache). SSL_shutdown() will then return with 0. If a unidirectional
+shutdown is enough (the underlying connection shall be closed anyway), this
+first call to SSL_shutdown() is sufficient. In order to complete the
+bidirectional shutdown handshake, SSL_shutdown() must be called again.
+The second call will make SSL_shutdown() wait for the peer's "close notify"
+shutdown alert. On success, the second call to SSL_shutdown() will return
+with 1.
+
+=item If the peer already sent the "close notify" alert B<and> it was
+already processed implicitly inside another function
+(L<SSL_read(3)|SSL_read(3)>), the SSL_RECEIVED_SHUTDOWN flag is set.
+SSL_shutdown() will send the "close notify" alert, set the SSL_SENT_SHUTDOWN
+flag and will immediately return with 1.
+Whether SSL_RECEIVED_SHUTDOWN is already set can be checked using the
+SSL_get_shutdown() (see also L<SSL_set_shutdown(3)|SSL_set_shutdown(3)> call.
+
+=back
+
+It is therefore recommended, to check the return value of SSL_shutdown()
+and call SSL_shutdown() again, if the bidirectional shutdown is not yet
+complete (return value of the first call is 0). As the shutdown is not
+specially handled in the SSLv2 protocol, SSL_shutdown() will succeed on
+the first call.
+
+The behaviour of SSL_shutdown() additionally depends on the underlying BIO. 
 
 If the underlying BIO is B<blocking>, SSL_shutdown() will only return once the
-handshake has been finished or an error occurred.
+handshake step has been finished or an error occurred.
 
 If the underlying BIO is B<non-blocking>, SSL_shutdown() will also return
 when the underlying BIO could not satisfy the needs of SSL_shutdown()
@@ -38,6 +80,12 @@ nothing is to be done, but select() can be used to check for the required
 condition. When using a buffering BIO, like a BIO pair, data must be written
 into or retrieved out of the BIO before being able to continue.
 
+SSL_shutdown() can be modified to only set the connection to "shutdown"
+state but not actually send the "close notify" alert messages,
+see L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>.
+When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
+and return 1.
+
 =head1 RETURN VALUES
 
 The following return values can occur:
@@ -46,19 +94,23 @@ The following return values can occur:
 
 =item 1
 
-The shutdown was successfully completed.
+The shutdown was successfully completed. The "close notify" alert was sent
+and the peer's "close notify" alert was received.
 
 =item 0
 
-The shutdown was not successful. Call SSL_get_error() with the return
-value B<ret> to find out the reason.
+The shutdown is not yet finished. Call SSL_shutdown() for a second time,
+if a bidirectional shutdown shall be performed.
+The output of L<SSL_get_error(3)|SSL_get_error(3)> may be misleading, as an
+erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
 
 =item -1
 
 The shutdown was not successful because a fatal error occurred either
-at the protocol level or a connection failure occurred. It can also occur of
+at the protocol level or a connection failure occurred. It can also occur if
 action is need to continue the operation for non-blocking BIOs.
-Call SSL_get_error() with the return value B<ret> to find out the reason.
+Call L<SSL_get_error(3)|SSL_get_error(3)> with the return value B<ret>
+to find out the reason.
 
 =back
 
@@ -66,6 +118,7 @@ Call SSL_get_error() with the return value B<ret> to find out the reason.
 
 L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_connect(3)|SSL_connect(3)>,
 L<SSL_accept(3)|SSL_accept(3)>, L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>,
+L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>,
 L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>,
 L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>
 
diff --git a/src/lib/libssl/src/doc/ssl/SSL_state_string.pod b/src/lib/libssl/src/doc/ssl/SSL_state_string.pod
new file mode 100644
index 0000000000..b4be1aaa48
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_state_string.pod
@@ -0,0 +1,45 @@
+=pod
+
+=head1 NAME
+
+SSL_state_string, SSL_state_string_long - get textual description of state of an SSL object
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ const char *SSL_state_string(SSL *ssl);
+ const char *SSL_state_string_long(SSL *ssl);
+
+=head1 DESCRIPTION
+
+SSL_state_string() returns a 6 letter string indicating the current state
+of the SSL object B<ssl>.
+
+SSL_state_string_long() returns a string indicating the current state of
+the SSL object B<ssl>.
+
+=head1 NOTES
+
+During its use, an SSL objects passes several states. The state is internally
+maintained. Querying the state information is not very informative before
+or when a connection has been established. It however can be of significant
+interest during the handshake.
+
+When using non-blocking sockets, the function call performing the handshake
+may return with SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE condition,
+so that SSL_state_string[_long]() may be called.
+
+For both blocking or non-blocking sockets, the details state information
+can be used within the info_callback function set with the
+SSL_set_info_callback() call.
+
+=head1 RETURN VALUES
+
+Detailed description of possible states to be included later.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_CTX_set_info_callback(3)|SSL_CTX_set_info_callback(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_want.pod b/src/lib/libssl/src/doc/ssl/SSL_want.pod
new file mode 100644
index 0000000000..50cc89db80
--- /dev/null
+++ b/src/lib/libssl/src/doc/ssl/SSL_want.pod
@@ -0,0 +1,77 @@
+=pod
+
+=head1 NAME
+
+SSL_want, SSL_want_nothing, SSL_want_read, SSL_want_write, SSL_want_x509_lookup - obtain state information TLS/SSL I/O operation
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_want(SSL *ssl);
+ int SSL_want_nothing(SSL *ssl);
+ int SSL_want_read(SSL *ssl);
+ int SSL_want_write(SSL *ssl);
+ int SSL_want_x509_lookup(SSL *ssl);
+
+=head1 DESCRIPTION
+
+SSL_want() returns state information for the SSL object B<ssl>.
+
+The other SSL_want_*() calls are shortcuts for the possible states returned
+by SSL_want().
+
+=head1 NOTES
+
+SSL_want() examines the internal state information of the SSL object. Its
+return values are similar to that of L<SSL_get_error(3)|SSL_get_error(3)>.
+Unlike L<SSL_get_error(3)|SSL_get_error(3)>, which also evaluates the
+error queue, the results are obtained by examining an internal state flag
+only. The information must therefore only be used for normal operation under
+non-blocking I/O. Error conditions are not handled and must be treated
+using L<SSL_get_error(3)|SSL_get_error(3)>.
+
+The result returned by SSL_want() should always be consistent with
+the result of L<SSL_get_error(3)|SSL_get_error(3)>.
+
+=head1 RETURN VALUES
+
+The following return values can currently occur for SSL_want():
+
+=over 4
+
+=item SSL_NOTHING
+
+There is no data to be written or to be read.
+
+=item SSL_WRITING
+
+There are data in the SSL buffer that must be written to the underlying
+B<BIO> layer in order to complete the actual SSL_*() operation.
+A call to L<SSL_get_error(3)|SSL_get_error(3)> should return
+SSL_ERROR_WANT_WRITE.
+
+=item SSL_READING
+
+More data must be read from the underlying B<BIO> layer in order to
+complete the actual SSL_*() operation.
+A call to L<SSL_get_error(3)|SSL_get_error(3)> should return
+SSL_ERROR_WANT_READ.
+
+=item SSL_X509_LOOKUP
+
+The operation did not complete because an application callback set by
+SSL_CTX_set_client_cert_cb() has asked to be called again.
+A call to L<SSL_get_error(3)|SSL_get_error(3)> should return
+SSL_ERROR_WANT_X509_LOOKUP.
+
+=back
+
+SSL_want_nothing(), SSL_want_read(), SSL_want_write(), SSL_want_x509_lookup()
+return 1, when the corresponding condition is true or 0 otherwise.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<err(3)|err(3)>, L<SSL_get_error(3)|SSL_get_error(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_write.pod b/src/lib/libssl/src/doc/ssl/SSL_write.pod
index b0dfefae20..dfa42e9aee 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_write.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_write.pod
@@ -25,11 +25,9 @@ the SSL_write() operation. The behaviour of SSL_write() depends on the
 underlying BIO. 
 
 For the transparent negotiation to succeed, the B<ssl> must have been
-initialized to client or server mode. This is not the case if a generic
-method is being used (see L<SSL_CTX_new(3)|SSL_CTX_new(3)>, so that
+initialized to client or server mode. This is being done by calling
 L<SSL_set_connect_state(3)|SSL_set_connect_state(3)> or SSL_set_accept_state()
-must be used before the first call to an L<SSL_read(3)|SSL_read(3)>
-or SSL_write() function.
+before the first call to an L<SSL_read(3)|SSL_read(3)> or SSL_write() function.
 
 If the underlying BIO is B<blocking>, SSL_write() will only return, once the
 write operation has been finished or an error occurred, except when a
@@ -80,8 +78,14 @@ bytes actually written to the TLS/SSL connection.
 
 =item 0
 
-The write operation was not successful. Call SSL_get_error() with the return
-value B<ret> to find out, whether an error occurred.
+The write operation was not successful. Probably the underlying connection
+was closed. Call SSL_get_error() with the return value B<ret> to find out,
+whether an error occurred or the connection was shut down cleanly
+(SSL_ERROR_ZERO_RETURN).
+
+SSLv2 (deprecated) does not support a shutdown alert protocol, so it can
+only be detected, whether the underlying connection was closed. It cannot
+be checked, why the closure happened.
 
 =item E<lt>0
 
diff --git a/src/lib/libssl/src/doc/ssl/d2i_SSL_SESSION.pod b/src/lib/libssl/src/doc/ssl/d2i_SSL_SESSION.pod
index 9a1ba6c47b..0321a5a36f 100644
--- a/src/lib/libssl/src/doc/ssl/d2i_SSL_SESSION.pod
+++ b/src/lib/libssl/src/doc/ssl/d2i_SSL_SESSION.pod
@@ -30,7 +30,17 @@ session data on disk or into a database, it must be transformed into
 a binary ASN1 representation.
 
 When using d2i_SSL_SESSION(), the SSL_SESSION object is automatically
-allocated.
+allocated. The reference count is 1, so that the session must be
+explicitly removed using L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>,
+unless the SSL_SESSION object is completely taken over, when being called
+inside the get_session_cb() (see
+L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)>).
+
+SSL_SESSION objects keep internal link information about the session cache
+list, when being inserted into one SSL_CTX object's session cache.
+One SSL_SESSION object, regardless of its reference count, must therefore
+only be used with one SSL_CTX object (and the SSL objects created
+from this SSL_CTX object).
 
 When using i2d_SSL_SESSION(), the memory location pointed to by B<pp> must be
 large enough to hold the binary representation of the session. There is no
@@ -50,7 +60,7 @@ When the session is not valid, B<0> is returned and no operation is performed.
 
 =head1 SEE ALSO
 
-L<ssl(3)|ssl(3)>,
+L<ssl(3)|ssl(3)>, L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>,
 L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/ssl.pod b/src/lib/libssl/src/doc/ssl/ssl.pod
index 16292a05f2..ce41b3e17d 100644
--- a/src/lib/libssl/src/doc/ssl/ssl.pod
+++ b/src/lib/libssl/src/doc/ssl/ssl.pod
@@ -299,7 +299,7 @@ protocol context defined in the B<SSL_CTX> structure.
 
 =item void B<SSL_CTX_set_cert_store>(SSL_CTX *ctx, X509_STORE *cs);
 
-=item void B<SSL_CTX_set_cert_verify_cb>(SSL_CTX *ctx, int (*cb)(SSL_CTX *), char *arg)
+=item void B<SSL_CTX_set_cert_verify_cb>(SSL_CTX *ctx, int (*cb)(), char *arg)
 
 =item int B<SSL_CTX_set_cipher_list>(SSL_CTX *ctx, char *str);
 
@@ -317,6 +317,10 @@ protocol context defined in the B<SSL_CTX> structure.
 
 =item void B<SSL_CTX_set_info_callback>(SSL_CTX *ctx, void (*cb)(SSL *ssl, int cb, int ret));
 
+=item void B<SSL_CTX_set_msg_callback>(SSL_CTX *ctx, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg));
+
+=item void B<SSL_CTX_set_msg_callback_arg>(SSL_CTX *ctx, void *arg);
+
 =item void B<SSL_CTX_set_options>(SSL_CTX *ctx, unsigned long op);
 
 =item void B<SSL_CTX_set_quiet_shutdown>(SSL_CTX *ctx, int mode);
@@ -576,6 +580,10 @@ connection defined in the B<SSL> structure.
 
 =item void B<SSL_set_info_callback>(SSL *ssl, void (*cb);(void))
 
+=item void B<SSL_set_msg_callback>(SSL *ctx, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg));
+
+=item void B<SSL_set_msg_callback_arg>(SSL *ctx, void *arg);
+
 =item void B<SSL_set_options>(SSL *ssl, unsigned long op);
 
 =item void B<SSL_set_quiet_shutdown>(SSL *ssl, int mode);
@@ -650,8 +658,10 @@ L<openssl(1)|openssl(1)>, L<crypto(3)|crypto(3)>,
 L<SSL_accept(3)|SSL_accept(3)>, L<SSL_clear(3)|SSL_clear(3)>,
 L<SSL_connect(3)|SSL_connect(3)>,
 L<SSL_CIPHER_get_name(3)|SSL_CIPHER_get_name(3)>,
+L<SSL_COMP_add_compression_method(3)|SSL_COMP_add_compression_method(3)>,
 L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>,
 L<SSL_CTX_add_session(3)|SSL_CTX_add_session(3)>,
+L<SSL_CTX_ctrl(3)|SSL_CTX_ctrl(3)>,
 L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)>,
 L<SSL_CTX_get_ex_new_index(3)|SSL_CTX_get_ex_new_index(3)>,
 L<SSL_CTX_get_verify_mode(3)|SSL_CTX_get_verify_mode(3)>,
@@ -661,18 +671,32 @@ L<SSL_CTX_sess_number(3)|SSL_CTX_sess_number(3)>,
 L<SSL_CTX_sess_set_cache_size(3)|SSL_CTX_sess_set_cache_size(3)>,
 L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)>,
 L<SSL_CTX_sessions(3)|SSL_CTX_sessions(3)>,
+L<SSL_CTX_set_cert_store(3)|SSL_CTX_set_cert_store(3)>,
+L<SSL_CTX_set_cert_verify_callback(3)|SSL_CTX_set_cert_verify_callback(3)>,
+L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>,
 L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)>,
+L<SSL_CTX_set_client_cert_cb(3)|SSL_CTX_set_client_cert_cb(3)>,
 L<SSL_CTX_set_default_passwd_cb(3)|SSL_CTX_set_default_passwd_cb(3)>,
+L<SSL_CTX_set_generate_session_id(3)|SSL_CTX_set_generate_session_id(3)>,
+L<SSL_CTX_set_info_callback(3)|SSL_CTX_set_info_callback(3)>,
+L<SSL_CTX_set_max_cert_list(3)|SSL_CTX_set_max_cert_list(3)>,
 L<SSL_CTX_set_mode(3)|SSL_CTX_set_mode(3)>,
+L<SSL_CTX_set_msg_callback(3)|SSL_CTX_set_msg_callback(3)>,
 L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>,
+L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>,
 L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>,
 L<SSL_CTX_set_session_id_context(3)|SSL_CTX_set_session_id_context(3)>,
 L<SSL_CTX_set_ssl_version(3)|SSL_CTX_set_ssl_version(3)>,
 L<SSL_CTX_set_timeout(3)|SSL_CTX_set_timeout(3)>,
+L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>,
+L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>,
 L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>,
 L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>,
+L<SSL_alert_type_string(3)|SSL_alert_type_string(3)>,
+L<SSL_get_SSL_CTX(3)|SSL_get_SSL_CTX(3)>,
 L<SSL_get_ciphers(3)|SSL_get_ciphers(3)>,
 L<SSL_get_client_CA_list(3)|SSL_get_client_CA_list(3)>,
+L<SSL_get_default_timeout(3)|SSL_get_default_timeout(3)>,
 L<SSL_get_error(3)|SSL_get_error(3)>,
 L<SSL_get_ex_data_X509_STORE_CTX_idx(3)|SSL_get_ex_data_X509_STORE_CTX_idx(3)>,
 L<SSL_get_ex_new_index(3)|SSL_get_ex_new_index(3)>,
@@ -685,12 +709,19 @@ L<SSL_get_version(3)|SSL_get_version(3)>,
 L<SSL_library_init(3)|SSL_library_init(3)>,
 L<SSL_load_client_CA_file(3)|SSL_load_client_CA_file(3)>,
 L<SSL_new(3)|SSL_new(3)>,
-L<SSL_read(3)|SSL_read(3)>, L<SSL_set_bio(3)|SSL_set_bio(3)>,
+L<SSL_pending(3)|SSL_pending(3)>,
+L<SSL_read(3)|SSL_read(3)>,
+L<SSL_rstate_string(3)|SSL_rstate_string(3)>,
+L<SSL_session_reused(3)|SSL_session_reused(3)>,
+L<SSL_set_bio(3)|SSL_set_bio(3)>,
 L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>,
-L<SSL_set_fd(3)|SSL_set_fd(3)>, L<SSL_pending(3)|SSL_pending(3)>,
+L<SSL_set_fd(3)|SSL_set_fd(3)>,
 L<SSL_set_session(3)|SSL_set_session(3)>,
 L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>,
-L<SSL_shutdown(3)|SSL_shutdown(3)>, L<SSL_write(3)|SSL_write(3)>,
+L<SSL_shutdown(3)|SSL_shutdown(3)>,
+L<SSL_state_string(3)|SSL_state_string(3)>,
+L<SSL_want(3)|SSL_want(3)>,
+L<SSL_write(3)|SSL_write(3)>,
 L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>,
 L<SSL_SESSION_get_ex_new_index(3)|SSL_SESSION_get_ex_new_index(3)>,
 L<SSL_SESSION_get_time(3)|SSL_SESSION_get_time(3)>,
diff --git a/src/lib/libssl/src/doc/ssleay.txt b/src/lib/libssl/src/doc/ssleay.txt
index fab8d42c42..c6049d5e53 100644
--- a/src/lib/libssl/src/doc/ssleay.txt
+++ b/src/lib/libssl/src/doc/ssleay.txt
@@ -1,6 +1,22 @@
 
 Bundle of old SSLeay documentation files [OBSOLETE!]
 
+*** WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! ***
+
+OBSOLETE means that nothing in this document should be trusted.  This
+document is provided mostly for historical purposes (it wasn't even up
+to date at the time SSLeay 0.8.1 was released) and as inspiration.  If
+you copy some snippet of code from this document, please _check_ that
+it really is correct from all points of view.  For example, you can
+check with the other documents in this directory tree, or by comparing
+with relevant parts of the include files.
+
+People have done the mistake of trusting what's written here.  Please
+don't do that.
+
+*** WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! ***
+
+
 ==== readme ========================================================
 
 This is the old 0.6.6 docuementation.  Most of the cipher stuff is still
diff --git a/src/lib/libssl/src/doc/standards.txt b/src/lib/libssl/src/doc/standards.txt
index 61ccc5d7e0..596d9001e6 100644
--- a/src/lib/libssl/src/doc/standards.txt
+++ b/src/lib/libssl/src/doc/standards.txt
@@ -24,7 +24,8 @@ http://www.rsasecurity.com/rsalabs/pkcs/.
 Implemented:
 ------------
 
-These are documents that describe things that are implemented in OpenSSL.
+These are documents that describe things that are implemented (in
+whole or at least great parts) in OpenSSL.
 
 1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992.
      (Format: TXT=25661 bytes) (Status: INFORMATIONAL)
@@ -59,6 +60,11 @@ PKCS#8: Private-Key Information Syntax Standard
 
 PKCS#12: Personal Information Exchange Syntax Standard, version 1.0.
 
+2560 X.509 Internet Public Key Infrastructure Online Certificate
+     Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin,
+     C. Adams. June 1999. (Format: TXT=43243 bytes) (Status: PROPOSED
+     STANDARD)
+
 
 Related:
 --------
@@ -84,6 +90,10 @@ STARTTLS documents.
      Certification and Related Services. B. Kaliski. February 1993.
      (Format: TXT=17537 bytes) (Status: PROPOSED STANDARD)
 
+2256 A Summary of the X.500(96) User Schema for use with LDAPv3. M.
+     Wahl. December 1997. (Format: TXT=32377 bytes) (Status: PROPOSED
+     STANDARD)
+
 2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman.
      January 1999. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD)
 
@@ -114,8 +124,7 @@ To be implemented:
 These are documents that describe things that are planed to be
 implemented in the hopefully short future.
 
-2560 X.509 Internet Public Key Infrastructure Online Certificate
-     Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin,
-     C. Adams. June 1999. (Format: TXT=43243 bytes) (Status: PROPOSED
-     STANDARD)
+2712 Addition of Kerberos Cipher Suites to Transport Layer Security
+     (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes)
+     (Status: PROPOSED STANDARD)