From 52d160d85d2a4c57729540d409747071f6b952f7 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Ulf=20M=C3=B6ller?= Date: Fri, 16 Feb 2001 02:09:53 +0000 Subject: [PATCH] ispell --- doc/ssl/SSL_CIPHER_get_name.pod | 4 ++-- doc/ssl/SSL_CTX_free.pod | 2 +- doc/ssl/SSL_CTX_load_verify_locations.pod | 4 ++-- doc/ssl/SSL_CTX_sess_number.pod | 2 +- doc/ssl/SSL_CTX_sessions.pod | 2 +- doc/ssl/SSL_CTX_set_client_CA_list.pod | 4 ++-- doc/ssl/SSL_CTX_set_options.pod | 4 ++-- doc/ssl/SSL_CTX_use_certificate.pod | 2 +- doc/ssl/SSL_get_client_CA_list.pod | 8 ++++---- doc/ssl/SSL_get_peer_cert_chain.pod | 2 +- doc/ssl/SSL_get_peer_certificate.pod | 2 +- doc/ssl/SSL_get_verify_result.pod | 4 ++-- 12 files changed, 20 insertions(+), 20 deletions(-) diff --git a/doc/ssl/SSL_CIPHER_get_name.pod b/doc/ssl/SSL_CIPHER_get_name.pod index bf851dcea5..4b91c63ba0 100644 --- a/doc/ssl/SSL_CIPHER_get_name.pod +++ b/doc/ssl/SSL_CIPHER_get_name.pod @@ -41,7 +41,7 @@ does use the full 128 bits (which would be returned for B), 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, B, B. Authentication method: B, B, B, B. None is the representation of anonymous ciphers. -=item Enc= +=item Enc= Encryption method with number of secret bits: B, B, B<3DES(168)>, B, B, B, B, diff --git a/doc/ssl/SSL_CTX_free.pod b/doc/ssl/SSL_CTX_free.pod index de69672422..c716cde164 100644 --- a/doc/ssl/SSL_CTX_free.pod +++ b/doc/ssl/SSL_CTX_free.pod @@ -17,7 +17,7 @@ SSL_CTX object pointed to by B 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 diff --git a/doc/ssl/SSL_CTX_load_verify_locations.pod b/doc/ssl/SSL_CTX_load_verify_locations.pod index 0e2d2179c8..88f18bd5ff 100644 --- a/doc/ssl/SSL_CTX_load_verify_locations.pod +++ b/doc/ssl/SSL_CTX_load_verify_locations.pod @@ -33,7 +33,7 @@ which can be used e.g. for descriptions of the certificates. The B 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 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/B, if the -certificate chain was not explicitely specified (see +certificate chain was not explicitly specified (see L, L. diff --git a/doc/ssl/SSL_CTX_sess_number.pod b/doc/ssl/SSL_CTX_sess_number.pod index a5150c054e..19aa4e2902 100644 --- a/doc/ssl/SSL_CTX_sess_number.pod +++ b/doc/ssl/SSL_CTX_sess_number.pod @@ -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 diff --git a/doc/ssl/SSL_CTX_sessions.pod b/doc/ssl/SSL_CTX_sessions.pod index ad92a8c5d2..e05aab3c1b 100644 --- a/doc/ssl/SSL_CTX_sessions.pod +++ b/doc/ssl/SSL_CTX_sessions.pod @@ -20,7 +20,7 @@ internal session cache for B. The sessions in the internal session cache are kept in an L 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 operations, so that the database must not be modified directly but by using the L family of functions. diff --git a/doc/ssl/SSL_CTX_set_client_CA_list.pod b/doc/ssl/SSL_CTX_set_client_CA_list.pod index f27a291cb6..81e312761e 100644 --- a/doc/ssl/SSL_CTX_set_client_CA_list.pod +++ b/doc/ssl/SSL_CTX_set_client_CA_list.pod @@ -41,7 +41,7 @@ the CAs available using the B option in L 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 and SSL_set_client_CA_list() for the specific B. The list specified overrides the previous setting. The CAs listed do not become trusted (B 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. Check the error stack to find out the reason. diff --git a/doc/ssl/SSL_CTX_set_options.pod b/doc/ssl/SSL_CTX_set_options.pod index fe164feaab..5eb376eda8 100644 --- a/doc/ssl/SSL_CTX_set_options.pod +++ b/doc/ssl/SSL_CTX_set_options.pod @@ -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 diff --git a/doc/ssl/SSL_CTX_use_certificate.pod b/doc/ssl/SSL_CTX_use_certificate.pod index 58fa3e6a84..3b2fe6fc50 100644 --- a/doc/ssl/SSL_CTX_use_certificate.pod +++ b/doc/ssl/SSL_CTX_use_certificate.pod @@ -117,7 +117,7 @@ in the file to the certificate store. The other certificates are added to the store of chain certificates using L. 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 diff --git a/doc/ssl/SSL_get_client_CA_list.pod b/doc/ssl/SSL_get_client_CA_list.pod index d358bc352e..40e01cf9c8 100644 --- a/doc/ssl/SSL_get_client_CA_list.pod +++ b/doc/ssl/SSL_get_client_CA_list.pod @@ -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 using L. -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 using SSL_set_client_CA_list() or B's SSL_CTX object with L, 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 or in server mode) or send +List of CA names explicitly set (for B or in server mode) or send by the server (client mode). =item NULL -No client CA list was explicitely set (for B or in server mode) or +No client CA list was explicitly set (for B or in server mode) or the server did not send a list of CAs (client mode). =back diff --git a/doc/ssl/SSL_get_peer_cert_chain.pod b/doc/ssl/SSL_get_peer_cert_chain.pod index e93e8206fa..390ce0b41b 100644 --- a/doc/ssl/SSL_get_peer_cert_chain.pod +++ b/doc/ssl/SSL_get_peer_cert_chain.pod @@ -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. If the peer did not present a certificate, NULL is returned. diff --git a/doc/ssl/SSL_get_peer_certificate.pod b/doc/ssl/SSL_get_peer_certificate.pod index 79c089aa51..1102c7fba9 100644 --- a/doc/ssl/SSL_get_peer_certificate.pod +++ b/doc/ssl/SSL_get_peer_certificate.pod @@ -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 diff --git a/doc/ssl/SSL_get_verify_result.pod b/doc/ssl/SSL_get_verify_result.pod index 4d66236a05..e6bac9c35a 100644 --- a/doc/ssl/SSL_get_verify_result.pod +++ b/doc/ssl/SSL_get_verify_result.pod @@ -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. -- 2.34.1