ispell

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<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)>,
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<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
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<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)>.
 
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<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.
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<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.
 
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<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
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<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
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<SSL_get_peer_certificate(3)|SSL_get_peer_certificate(3)>.
 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<SSL_get_peer_certificate(3)|SSL_get_peer_certificate(3)>.