diff options
-rw-r--r-- | doc/man7/ossl-guide-quic-client-block.pod | 4 | ||||
-rw-r--r-- | doc/man7/ossl-guide-tls-client-block.pod | 12 | ||||
-rw-r--r-- | doc/man7/ossl-guide-tls-introduction.pod | 4 |
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 |