ispell
This commit is contained in:
parent
54ff1e6ae5
commit
52d160d85d
12 changed files with 20 additions and 20 deletions
|
@ -41,7 +41,7 @@ does use the full 128 bits (which would be returned for B<alg_bits>), of
|
|||
which however 88bits are fixed. The search space is hence only 40 bits.
|
||||
|
||||
The string returned by SSL_CIPHER_description() in case of success consists
|
||||
of cleartext information seperated by one or more blanks in the following
|
||||
of cleartext information separated by one or more blanks in the following
|
||||
sequence:
|
||||
|
||||
=over 4
|
||||
|
@ -65,7 +65,7 @@ B<DH/RSA>, B<DH/DSS>, B<Fortezza>.
|
|||
Authentication method: B<RSA>, B<DSS>, B<DH>, B<None>. None is the
|
||||
representation of anonymous ciphers.
|
||||
|
||||
=item Enc=<symmectric encryption method>
|
||||
=item Enc=<symmetric encryption method>
|
||||
|
||||
Encryption method with number of secret bits: B<DES(40)>, B<DES(56)>,
|
||||
B<3DES(168)>, B<RC4(40)>, B<RC4(56)>, B<RC4(64)>, B<RC4(128)>,
|
||||
|
|
|
@ -17,7 +17,7 @@ SSL_CTX object pointed to by B<ctx> and frees up the allocated memory if the
|
|||
the reference count has reached 0.
|
||||
|
||||
It also calls the free()ing procedures for indirectly affected items, if
|
||||
applicable: the session cacahe, the list of ciphers, the list of Client CAs,
|
||||
applicable: the session cache, the list of ciphers, the list of Client CAs,
|
||||
the certificates and keys.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
|
|
@ -33,7 +33,7 @@ which can be used e.g. for descriptions of the certificates.
|
|||
The B<CAfile> is processed on execution of the SSL_CTX_load_verify_locations()
|
||||
function.
|
||||
|
||||
If on an TLS/SSL server no special setting is perfomed using *client_CA_list()
|
||||
If on an TLS/SSL server no special setting is performed using *client_CA_list()
|
||||
functions, the certificates contained in B<CAfile> are listed to the client
|
||||
as available CAs during the TLS/SSL handshake.
|
||||
|
||||
|
@ -64,7 +64,7 @@ failure.
|
|||
|
||||
When building its own certificate chain, an OpenSSL client/server will
|
||||
try to fill in missing certificates from B<CAfile>/B<CApath>, if the
|
||||
certificate chain was not explicitely specified (see
|
||||
certificate chain was not explicitly specified (see
|
||||
L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>,
|
||||
L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>.
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ client mode.
|
|||
SSL_CTX_sess_connect_good() returns the number of successfully established
|
||||
SSL/TLS sessions in client mode.
|
||||
|
||||
SSL_CTX_sess_connct_renegotiate() returns the number of start renegotiations
|
||||
SSL_CTX_sess_connect_renegotiate() returns the number of start renegotiations
|
||||
in client mode.
|
||||
|
||||
SSL_CTX_sess_accept() returns the number of started SSL/TLS handshakes in
|
||||
|
|
|
@ -20,7 +20,7 @@ internal session cache for B<ctx>.
|
|||
The sessions in the internal session cache are kept in an
|
||||
L<lhash(3)|lhash(3)> type database. It is possible to directly
|
||||
access this database e.g. for searching. In parallel, the sessions
|
||||
form a linked list which is maintained seperatly from the
|
||||
form a linked list which is maintained separately from the
|
||||
L<lhash(3)|lhash(3)> operations, so that the database must not be
|
||||
modified directly but by using the
|
||||
L<SSL_CTX_add_session(3)|SSL_CTX_add_session(3)> family of functions.
|
||||
|
|
|
@ -41,7 +41,7 @@ the CAs available using the B<CAfile> option in
|
|||
L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>
|
||||
are sent.
|
||||
|
||||
This list can be explicitely set using the SSL_CTX_set_client_CA_list() for
|
||||
This list can be explicitly set using the SSL_CTX_set_client_CA_list() for
|
||||
B<ctx> and SSL_set_client_CA_list() for the specific B<ssl>. The list
|
||||
specified overrides the previous setting. The CAs listed do not become
|
||||
trusted (B<list> only contains the names, not the complete certificates); use
|
||||
|
@ -74,7 +74,7 @@ The operation succeeded.
|
|||
|
||||
=item 0
|
||||
|
||||
A failure while manipulating the STACK_OF(X509_NAME) object occured or
|
||||
A failure while manipulating the STACK_OF(X509_NAME) object occurred or
|
||||
the X509_NAME could not be extracted from B<cacert>. Check the error stack
|
||||
to find out the reason.
|
||||
|
||||
|
|
|
@ -53,7 +53,7 @@ Netscape-Commerce/1.12, when talking SSLv2, accepts a 32 byte
|
|||
challenge but then appears to only use 16 bytes when generating the
|
||||
encryption keys. Using 16 bytes is ok but it should be ok to use 32.
|
||||
According to the SSLv3 spec, one should use 32 bytes for the challenge
|
||||
when opperating in SSLv2/v3 compatablity mode, but as mentioned above,
|
||||
when operating in SSLv2/v3 compatibility mode, but as mentioned above,
|
||||
this breaks this server so 16 bytes is the way to go.
|
||||
|
||||
=item SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG
|
||||
|
@ -133,7 +133,7 @@ Also use the temporary RSA key when doing RSA operations.
|
|||
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 procotol, for SSLv2 the server
|
||||
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
|
||||
|
|
|
@ -117,7 +117,7 @@ in the file to the certificate store. The other certificates are added
|
|||
to the store of chain certificates using
|
||||
L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>.
|
||||
There exists only one extra chain store, so that the same chain is appended
|
||||
to both types of certificates, RSA and DSA! If it is not intented to use
|
||||
to both types of certificates, RSA and DSA! If it is not intended to use
|
||||
both type of certificate at the same time, it is recommended to use the
|
||||
SSL_CTX_use_certificate_chain_file() instead of the
|
||||
SSL_CTX_use_certificate_file() function in order to allow the use of
|
||||
|
|
|
@ -13,10 +13,10 @@ SSL_get_client_CA_list, SSL_CTX_get_client_CA_list - get list of client CAs
|
|||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
SSL_CTX_get_client_CA_list() returns the list of client CAs explicitely set for
|
||||
SSL_CTX_get_client_CA_list() returns the list of client CAs explicitly set for
|
||||
B<ctx> using L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)>.
|
||||
|
||||
SSL_get_client_CA_list() returns the list of client CAs explicitely
|
||||
SSL_get_client_CA_list() returns the list of client CAs explicitly
|
||||
set for B<ssl> using SSL_set_client_CA_list() or B<ssl>'s SSL_CTX object with
|
||||
L<SSL_CTX_set_client_CA_list(3)|SSL_CTX_set_client_CA_list(3)>, when in
|
||||
server mode. In client mode, SSL_get_client_CA_list returns the list of
|
||||
|
@ -34,12 +34,12 @@ values:
|
|||
|
||||
=item STACK_OF(X509_NAMES)
|
||||
|
||||
List of CA names explicitely set (for B<ctx> or in server mode) or send
|
||||
List of CA names explicitly set (for B<ctx> or in server mode) or send
|
||||
by the server (client mode).
|
||||
|
||||
=item NULL
|
||||
|
||||
No client CA list was explicitely set (for B<ctx> or in server mode) or
|
||||
No client CA list was explicitly set (for B<ctx> or in server mode) or
|
||||
the server did not send a list of CAs (client mode).
|
||||
|
||||
=back
|
||||
|
|
|
@ -15,7 +15,7 @@ SSL_get_peer_cert_chain - get the X509 certificate chain of the peer
|
|||
SSL_get_peer_cert_chain() returns a pointer to STACKOF(X509) certificates
|
||||
forming the certificate chain of the peer. If called on the client side,
|
||||
the stack also contains the peer's certificate; if called on the server
|
||||
side, the peer's certificate must be obtained seperately using
|
||||
side, the peer's certificate must be obtained separately using
|
||||
L<SSL_get_peer_certificate(3)|SSL_get_peer_certificate(3)>.
|
||||
If the peer did not present a certificate, NULL is returned.
|
||||
|
||||
|
|
|
@ -23,7 +23,7 @@ to check the verification state.
|
|||
|
||||
The reference count of the X509 object is incremented by one, so that it
|
||||
will not be destroyed when the session containing the peer certificate is
|
||||
freed. The X509 object must be explicitely freed using X509_free().
|
||||
freed. The X509 object must be explicitly freed using X509_free().
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ X509 certificate presented by the peer, if any.
|
|||
|
||||
SSL_get_verify_result() can only return one error code while the verification
|
||||
of a certificate can fail because of many reasons at the same time. Only
|
||||
the last verification error that occured during the processing is available
|
||||
the last verification error that occurred during the processing is available
|
||||
from SSL_get_verify_result().
|
||||
|
||||
The verification result is part of the established session and is restored
|
||||
|
@ -28,7 +28,7 @@ when a session is reused.
|
|||
=head1 BUGS
|
||||
|
||||
If no peer certificate was presented, the returned result code is
|
||||
X509_V_OK. This is because no verification error occured, it does however
|
||||
X509_V_OK. This is because no verification error occurred, it does however
|
||||
not indicate success. SSL_get_verify_result() is only useful in connection
|
||||
with L<SSL_get_peer_certificate(3)|SSL_get_peer_certificate(3)>.
|
||||
|
||||
|
|
Loading…
Reference in a new issue