ispell
This commit is contained in:
parent
14cfde9c83
commit
3b80e3aa9e
12
INSTALL.VMS
12
INSTALL.VMS
@ -33,11 +33,11 @@ Checking the distribution:
|
||||
==========================
|
||||
|
||||
There have been reports of places where the distribution didn't quite get
|
||||
through, for example if you've copied the tree from a NFS-mounted unix
|
||||
through, for example if you've copied the tree from a NFS-mounted Unix
|
||||
mount point.
|
||||
|
||||
The easiest way to check if everything got through as it should is to check
|
||||
for oen of the following files:
|
||||
for one of the following files:
|
||||
|
||||
[.CRYPTO]OPENSSLCONF.H_IN
|
||||
[.CRYPTO]OPENSSLCONF_H.IN
|
||||
@ -69,7 +69,7 @@ for a command procedure name xxx-LIB.COM (in the library directories)
|
||||
or MAKExxx.COM (in the program directories) and read the comments at
|
||||
the top to understand how to use them. However, if you want to
|
||||
compile all you can get, the simplest is to use MAKEVMS.COM in the top
|
||||
directory. The syntax is trhe following:
|
||||
directory. The syntax is the following:
|
||||
|
||||
@MAKEVMS <option> <rsaref-p> <debug-p> [<compiler>]
|
||||
|
||||
@ -79,7 +79,7 @@ directory. The syntax is trhe following:
|
||||
CONFIG Just build the "[.CRYPTO]OPENSSLCONF.H" file.
|
||||
BUILDINF Just build the "[.INCLUDE]BUILDINF.H" file.
|
||||
SOFTLINKS Just copies some files, to simulate Unix soft links.
|
||||
BUILDALL Same as ALL, except CONFIG, BUILDINF and SOFTILNKS aren't done.
|
||||
BUILDALL Same as ALL, except CONFIG, BUILDINF and SOFTLINKS aren't done.
|
||||
RSAREF Just build the "[.xxx.EXE.RSAREF]LIBRSAGLUE.OLB" library.
|
||||
CRYPTO Just build the "[.xxx.EXE.CRYPTO]LIBCRYPTO.OLB" library.
|
||||
SSL Just build the "[.xxx.EXE.SSL]LIBSSL.OLB" library.
|
||||
@ -92,7 +92,7 @@ directory. The syntax is trhe following:
|
||||
RSAREF compile using the RSAREF Library
|
||||
NORSAREF compile without using RSAREF
|
||||
|
||||
Note 0: The RASREF library IS NO LONGER NEEDED. The RSA patent
|
||||
Note 0: The RSAREF library IS NO LONGER NEEDED. The RSA patent
|
||||
expires September 20, 2000, and RSA Security chose to make
|
||||
the algorithm public domain two weeks before that.
|
||||
|
||||
@ -264,7 +264,7 @@ following before you start compiling:
|
||||
The USER_CCDISABLEWARNINGS is there because otherwise, DEC C will complain
|
||||
that those macros have been changed.
|
||||
|
||||
Note: Currently, this is only usefull for library compilation. The
|
||||
Note: Currently, this is only useful for library compilation. The
|
||||
programs will still be linked with the current version of the
|
||||
C library shareable image, and will thus complain if they are
|
||||
faced with an older version of the same C library shareable image.
|
||||
|
@ -257,5 +257,5 @@
|
||||
malloc(), free() and realloc() as the application. However there are many
|
||||
standard library functions used by OpenSSL that call malloc() internally
|
||||
(e.g. fopen()), and OpenSSL cannot change these; so in general you cannot
|
||||
rely on CYRPTO_malloc_init() solving your problem, and you should
|
||||
rely on CRYPTO_malloc_init() solving your problem, and you should
|
||||
consistently use the multithreaded library.
|
||||
|
4
README
4
README
@ -62,7 +62,7 @@
|
||||
|
||||
X.509v3 certificates
|
||||
X509 encoding/decoding into/from binary ASN1 and a PEM
|
||||
based ascii-binary encoding which supports encryption with a
|
||||
based ASCII-binary encoding which supports encryption with a
|
||||
private key. Program to generate RSA and DSA certificate
|
||||
requests and to generate RSA and DSA certificates.
|
||||
|
||||
@ -97,7 +97,7 @@
|
||||
locations around the world. _YOU_ are responsible for ensuring that your use
|
||||
of any algorithms is legal by checking if there are any patents in your
|
||||
country. The file contains some of the patents that we know about or are
|
||||
rumoured to exist. This is not a definitive list.
|
||||
rumored to exist. This is not a definitive list.
|
||||
|
||||
RSA Security holds software patents on the RC5 algorithm. If you
|
||||
intend to use this cipher, you must contact RSA Security for
|
||||
|
@ -6,7 +6,7 @@
|
||||
crypto devices (eg. accelerator cards). This component is called ENGINE,
|
||||
and its presence in OpenSSL 0.9.6 (and subsequent bug-fix releases)
|
||||
caused a little confusion as 0.9.6** releases were rolled in two
|
||||
versions, a "standard" and an "engine" verion. In development for 0.9.7,
|
||||
versions, a "standard" and an "engine" version. In development for 0.9.7,
|
||||
the ENGINE code has been merged into the main branch and will be present
|
||||
in the standard releases from 0.9.7 forwards.
|
||||
|
||||
@ -139,7 +139,7 @@
|
||||
gets its own copy of it. As such, multi-threaded code (or code that
|
||||
multiplexes multiple uses of 'dynamic' in a single application in any
|
||||
way at all) does not get confused by 'dynamic' being used to do many
|
||||
independant things. Other ENGINEs typically don't do this so there is
|
||||
independent things. Other ENGINEs typically don't do this so there is
|
||||
only ever 1 ENGINE structure of its type (and reference counts are used
|
||||
to keep order). The dynamic ENGINE itself provides absolutely no
|
||||
cryptographic functionality, and any attempt to "initialise" the ENGINE
|
||||
@ -208,7 +208,7 @@
|
||||
"-pre" syntax in the "openssl engine" utility is that some commands
|
||||
might be issued to an ENGINE *after* it has been initialised for use.
|
||||
Eg. if an ENGINE implementation requires a smart-card to be inserted
|
||||
during intialisation (or a PIN to be typed, or whatever), there may be
|
||||
during initialisation (or a PIN to be typed, or whatever), there may be
|
||||
a control command you can issue afterwards to "forget" the smart-card
|
||||
so that additional initialisation is no longer possible. In
|
||||
applications such as web-servers, where potentially volatile code may
|
||||
@ -230,8 +230,8 @@
|
||||
hand such applications would only have the memory footprint of any
|
||||
ENGINEs explicitly loaded using user/admin provided control commands.
|
||||
The main advantage of not statically linking ENGINEs and only using
|
||||
"dynamic" for hardare support is that any installation using no
|
||||
"external" ENGINE suffers no unecessary memory footprint from unused
|
||||
"dynamic" for hardware support is that any installation using no
|
||||
"external" ENGINE suffers no unnecessary memory footprint from unused
|
||||
ENGINEs. Likewise, installations that do require an ENGINE incur the
|
||||
overheads from only *that* ENGINE once it has been loaded.
|
||||
|
||||
@ -243,7 +243,7 @@
|
||||
if OpenSSL itself is built as a shared library. The instructions are
|
||||
the same in each case, but in the former (statically linked any
|
||||
dependencies on OpenSSL) you must ensure OpenSSL is built with
|
||||
position-independant code ("PIC"). The default OpenSSL compilation may
|
||||
position-independent code ("PIC"). The default OpenSSL compilation may
|
||||
already specify the relevant flags to do this, but you should consult
|
||||
with your compiler documentation if you are in any doubt.
|
||||
|
||||
@ -282,7 +282,7 @@
|
||||
PROBLEMS
|
||||
========
|
||||
|
||||
It seems like the ENGINE part doesn't work too well with Cryptoswift on Win32.
|
||||
It seems like the ENGINE part doesn't work too well with CryptoSwift on Win32.
|
||||
A quick test done right before the release showed that trying "openssl speed
|
||||
-engine cswift" generated errors. If the DSO gets enabled, an attempt is made
|
||||
to write at memory address 0x00000002.
|
||||
|
@ -160,7 +160,7 @@ 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 muliple of the cipher
|
||||
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.
|
||||
|
@ -93,7 +93,7 @@ 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, reponse or both respectively.
|
||||
print out the text form of the OCSP request, response or both respectively.
|
||||
|
||||
=item B<-reqout file>, B<-respout file>
|
||||
|
||||
@ -124,14 +124,14 @@ the signature on the OCSP response.
|
||||
|
||||
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 reponse: this option can be used to supply the neccesary
|
||||
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 reponder certificate chain is not available or trusting a
|
||||
when the complete responder certificate chain is not available or trusting a
|
||||
root CA is not appropriate.
|
||||
|
||||
=item B<-VAfile file>
|
||||
@ -154,11 +154,11 @@ 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 respondes it will normally only be used for testing purposes.
|
||||
signatures on OCSP responses it will normally only be used for testing purposes.
|
||||
|
||||
=item B<-no_cert_verify>
|
||||
|
||||
don't verify the OCSP reponse signers certificate at all. Since this option allows
|
||||
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.
|
||||
|
||||
@ -171,7 +171,7 @@ certificates.
|
||||
|
||||
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 neccessary status information: as a result this option should
|
||||
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>
|
||||
@ -255,7 +255,7 @@ omitted meaning fresh revocation information is immediately available.
|
||||
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 reponder certificate's public key.
|
||||
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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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-----
|
||||
|
@ -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
|
||||
|
@ -179,7 +179,7 @@ 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 certifcate. This
|
||||
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.
|
||||
|
||||
|
@ -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
|
||||
|
@ -132,7 +132,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>
|
||||
@ -180,7 +180,7 @@ all others.
|
||||
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.
|
||||
|
||||
|
@ -195,7 +195,7 @@ 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 wih CRLF).
|
||||
are part of the HTTP response line and headers must end with CRLF).
|
||||
|
||||
=item B<-engine id>
|
||||
|
||||
|
@ -397,7 +397,7 @@ 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>
|
||||
@ -451,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>
|
||||
|
||||
|
@ -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
|
||||
|
@ -73,7 +73,7 @@ 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() substracts I<b> from I<a> modulo I<m> and places the
|
||||
BN_mod_sub() subtracts I<b> from I<a> modulo I<m> and places the
|
||||
non-negative result in I<r>.
|
||||
|
||||
BN_mod_mul() multiplies I<a> by I<b> and finds the non-negative
|
||||
|
@ -120,7 +120,7 @@ lh_doall() will, for every entry in the hash table, call B<func> with
|
||||
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 decare/implement macros to
|
||||
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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -43,7 +43,7 @@ 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 occured.
|
||||
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.
|
||||
|
||||
|
@ -133,7 +133,7 @@ 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 recommendet.
|
||||
a new DH key during each handshake but it is also recommended.
|
||||
SSL_OP_SINGLE_DH_USE should therefore be enabled whenever
|
||||
temporary/ephemeral DH parameters are used.
|
||||
|
||||
@ -209,6 +209,6 @@ SSL_OP_CIPHER_SERVER_PREFERENCE has been added in OpenSSL 0.9.7.
|
||||
|
||||
SSL_OP_TLS_ROLLBACK_BUG has been added in OpenSSL 0.9.6 and was automatically
|
||||
enabled with SSL_OP_ALL. As of 0.9.7 it is no longer included in SSL_OP_ALL
|
||||
and must be explicitely set.
|
||||
and must be explicitly set.
|
||||
|
||||
=cut
|
||||
|
@ -29,7 +29,7 @@ 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 paramters only for B<ssl>.
|
||||
SSL_set_tmp_dh() sets the parameters only for B<ssl>.
|
||||
|
||||
These functions apply to SSL/TLS servers only.
|
||||
|
||||
@ -54,7 +54,7 @@ In order to perform a DH key exchange the server must use a DH group
|
||||
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
|
||||
immediatly create a DH key, when DH parameters are supplied via
|
||||
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
|
||||
@ -74,7 +74,7 @@ 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 paramaters during the installation process using the
|
||||
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
|
||||
|
@ -31,7 +31,7 @@ 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 temporay/ephemeral RSA key is needed
|
||||
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.
|
||||
|
||||
@ -39,7 +39,7 @@ 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 temporay/ephemeral RSA key is needed,
|
||||
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.
|
||||
|
||||
|
@ -130,9 +130,9 @@ other fields. This is always fatal.
|
||||
|
||||
=item "DC"/"decryption failed"
|
||||
|
||||
A TLSCiphertext decrypted in an invalid way: either it wasn`t an
|
||||
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.
|
||||
checked, weren't correct. This message is always fatal.
|
||||
|
||||
=item "RO"/"record overflow"
|
||||
|
||||
@ -144,7 +144,7 @@ with more than 2^14+1024 bytes. This message is always fatal.
|
||||
|
||||
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
|
||||
be located or couldn't be matched with a known, trusted CA. This
|
||||
message is always fatal.
|
||||
|
||||
=item "AD"/"access denied"
|
||||
|
@ -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.
|
||||
|
||||
|
@ -36,7 +36,7 @@ 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 explicitely set in advance using either
|
||||
handshake routines must be explicitly set in advance using either
|
||||
SSL_set_connect_state() or SSL_set_accept_state().
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
Loading…
Reference in New Issue
Block a user