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
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.
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.
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.
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.
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
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
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.
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.
SSL_SESSION_free() does not provide diagnostic information.
+=head1 SEE ALSO
+
L<ssl(3)|ssl(3)>, L<SSL_get_session(3)|SSL_get_session(3)>
=cut
=head1 DESCRIPTION
-SSL_alert_type_string() returns the a one letter string indicating the
+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 the a two letter string as a short form
+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 the a string describing the reason
+SSL_alert_desc_string_long() returns a string describing the reason
of the alert specified by B<value>.
=head1 NOTES
=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"
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"
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.
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.
=item 0
-The read operation was not successful, the SSL connection was closed by the
-peer by sending a "close notify" alert. 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)>).
-Call SSL_get_error() with the return value B<ret> to find out,
+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).
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
=item 0
-The write operation was not successful, because the write side of the
-SSL connection was shut down (the SSL_SENT_SHUTDOWN flag in the shutdown
-state is set) by calling L<SSL_shutdown(3)|SSL_shutdown(3)> or
-L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>. It is also possible, that the
-underlying connection was closed.
-Call SSL_get_error() with the return value B<ret> to find out,
+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).
projects / oweals / openssl.git / commitdiff