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
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)>,
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
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.
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)>.
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
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.
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
=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.
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
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
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
=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
=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
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.
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
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
=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)>.
projects / openssl.git / commitdiff