Fix new typos found by codespell in man pages

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21322)

3 files changed, 10 insertions, 10 deletions

diff --git a/doc/man7/ossl-guide-quic-client-block.pod b/doc/man7/ossl-guide-quic-client-block.pod
index 4506f88516..437c57b68a 100644
--- a/doc/man7/ossl-guide-quic-client-block.pod
+++ b/doc/man7/ossl-guide-quic-client-block.pod
@@ -222,7 +222,7 @@ address away for future use. Now we need to use it via the
 L<SSL_set_initial_peer_addr(3)> function.
 
     if (!SSL_set_initial_peer_addr(ssl, peer_addr)) {
-        printf("Failed to set the inital peer address\n");
+        printf("Failed to set the initial peer address\n");
         goto end;
     }
 
@@ -257,7 +257,7 @@ once:
     do {
         ret = SSL_shutdown(ssl);
         if (ret < 0) {
-            printf("Error shuting down: %d\n", ret);
+            printf("Error shutting down: %d\n", ret);
             goto end;
         }
     } while (ret != 1);
diff --git a/doc/man7/ossl-guide-tls-client-block.pod b/doc/man7/ossl-guide-tls-client-block.pod
index c4c19a98b5..1116b26cae 100644
--- a/doc/man7/ossl-guide-tls-client-block.pod
+++ b/doc/man7/ossl-guide-tls-client-block.pod
@@ -78,7 +78,7 @@ can safely be set to NULL to get the default handling.
     SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
 
 In order for certificate verification to be successful you must have configured
-where the trusted certifcate store to be used is located (see
+where the trusted certificate store to be used is located (see
 L<ossl-guide-tls-introduction(7)>). In most cases you just want to use the
 default store so we call L<SSL_CTX_set_default_verify_paths(3)>.
 
@@ -95,7 +95,7 @@ L<SSL_CTX_set_min_proto_version(3)>:
 
     /*
      * TLSv1.1 or earlier are deprecated by IETF and are generally to be
-     * avoided if possible. We require a mimimum TLS version of TLSv1.2.
+     * avoided if possible. We require a minimum TLS version of TLSv1.2.
      */
     if (!SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION)) {
         printf("Failed to set the minimum TLS protocol version\n");
@@ -411,7 +411,7 @@ L<SSL_get_error(3)> to determine the cause of the 0 return value.
 If L<SSL_get_error(3)> returns B<SSL_ERROR_ZERO_RETURN> then we know that the
 server has finished sending its data. Otherwise an error has occurred.
 
-=head2 Shuting down the connection
+=head2 Shutting down the connection
 
 Once we have finished reading data from the server then we are ready to close
 the connection down. We do this via the L<SSL_shutdown(3)> function which has
@@ -430,7 +430,7 @@ the server saying that we have finished writing data:
          * for one back". But we already know we got one from the peer
          * because of the SSL_ERROR_ZERO_RETURN above.
          */
-        printf("Error shuting down\n");
+        printf("Error shutting down\n");
         goto end;
     }
 
@@ -484,7 +484,7 @@ L<SSL_CTX_free(3)>.
 =head1 TROUBLESHOOTING
 
 There are a number of things that might go wrong when running the demo
-application. This section desribes some common things you might encounter.
+application. This section describes some common things you might encounter.
 
 =head2 Failure to connect the underlying socket
 
@@ -514,7 +514,7 @@ certificate store is correctly configured
 =item Unrecognised CA
 
 If the CA used by the server's certificate is not in the trusted certificate
-store for the client then this will cause a verfication failure during
+store for the client then this will cause a verification failure during
 connection. Often this can occur if the server is using a self-signed
 certificate (i.e. a test certificate that has not been signed by a CA at all).
 
diff --git a/doc/man7/ossl-guide-tls-introduction.pod b/doc/man7/ossl-guide-tls-introduction.pod
index 307b5eec91..1a8c489753 100644
--- a/doc/man7/ossl-guide-tls-introduction.pod
+++ b/doc/man7/ossl-guide-tls-introduction.pod
@@ -119,7 +119,7 @@ the server. There is a chain of trust between the root CA and the server.
 
 By default it is only the client that authenticates the server using this
 method. However it is also possible to set things up such that the server
-additionally autenticates the client. This is known as "client authentication".
+additionally authenticates the client. This is known as "client authentication".
 In this approach the client will still authenticate the server in the same way,
 but the server will request a certificate from the client. The client sends the
 server its certificate and the server authenticates it in the same way that the
@@ -215,7 +215,7 @@ object and then create multiple connections (i.e. B<SSL> objects) from it.
 Typically you can set up common configuration options on the B<SSL_CTX> so that
 all the B<SSL> object created from it inherit the same configuration options.
 
-Note that internaly to OpenSSL various items that are shared between multiple
+Note that internally to OpenSSL various items that are shared between multiple
 B<SSL> objects are cached in the B<SSL_CTX> for performance reasons. Therefore
 it is considered best practice to create one B<SSL_CTX> for use by multiple
 B<SSL> objects instead of having one B<SSL_CTX> for each B<SSL> object that you