Fix misspelling errors and typos reported by codespell

Fixes #10998

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11000)

5 files changed, 5 insertions, 5 deletions

diff --git a/doc/man1/openssl-s_client.pod.in b/doc/man1/openssl-s_client.pod.in
index 78a61482ac..0d3f54e1a2 100644
--- a/doc/man1/openssl-s_client.pod.in
+++ b/doc/man1/openssl-s_client.pod.in
@@ -353,7 +353,7 @@ at a positive depth or else "matched EE certificate" at depth 0.
 
 Use one or more times to specify the RRDATA fields of the DANE TLSA
 RRset associated with the target service.  The I<rrdata> value is
-specied in "presentation form", that is four whitespace separated
+specified in "presentation form", that is four whitespace separated
 fields that specify the usage, selector, matching type and associated
 data, with the last of these encoded in hexadecimal.  Optional
 whitespace is ignored in the associated data field.  For example:
diff --git a/doc/man1/openssl-sess_id.pod b/doc/man1/openssl-sess_id.pod
index ff90231fa2..bb49dbd56b 100644
--- a/doc/man1/openssl-sess_id.pod
+++ b/doc/man1/openssl-sess_id.pod
@@ -91,7 +91,7 @@ Typical output:
      Timeout   : 300 (sec)
      Verify return code 0 (ok)
 
-Theses are described below in more detail.
+These are described below in more detail.
 
 =over 4
 
diff --git a/doc/man3/ASN1_TYPE_get.pod b/doc/man3/ASN1_TYPE_get.pod
index c39d93d8d2..54644d35ad 100644
--- a/doc/man3/ASN1_TYPE_get.pod
+++ b/doc/man3/ASN1_TYPE_get.pod
@@ -70,7 +70,7 @@ If either or both of the parameters passed to ASN1_TYPE_cmp() is NULL the
 return value is nonzero. Technically if both parameters are NULL the two
 types could be absent OPTIONAL fields and so should match, however passing
 NULL values could also indicate a programming error (for example an
-unparseable type which returns NULL) for types which do B<not> match. So
+unparsable type which returns NULL) for types which do B<not> match. So
 applications should handle the case of two absent values separately.
 
 =head1 RETURN VALUES
diff --git a/doc/man3/OCSP_request_add1_nonce.pod b/doc/man3/OCSP_request_add1_nonce.pod
index 9d6c73171b..6620da645d 100644
--- a/doc/man3/OCSP_request_add1_nonce.pod
+++ b/doc/man3/OCSP_request_add1_nonce.pod
@@ -24,7 +24,7 @@ it adds a nonce to OCSP basic response B<resp>.
 
 OCSP_check_nonce() compares the nonce value in B<req> and B<resp>.
 
-OCSP_copy_nonce() copys any nonce value present in B<req> to B<resp>.
+OCSP_copy_nonce() copies any nonce value present in B<req> to B<resp>.
 
 =head1 RETURN VALUES
 
diff --git a/doc/man7/passphrase-encoding.pod b/doc/man7/passphrase-encoding.pod
index 4b4732faf2..1d1a7e99d4 100644
--- a/doc/man7/passphrase-encoding.pod
+++ b/doc/man7/passphrase-encoding.pod
@@ -65,7 +65,7 @@ A pass phrase encoded in ISO-8859-2 could very well have a sequence such as
 0xC3 0xAF (which is the two characters "LATIN CAPITAL LETTER A WITH BREVE"
 and "LATIN CAPITAL LETTER Z WITH DOT ABOVE" in ISO-8859-2 encoding), but would
 be misinterpreted as the perfectly valid UTF-8 encoded code point U+00EF (LATIN
-SMALL LETTER I WITH DIARESIS) I<if the pass phrase doesn't contain anything that
+SMALL LETTER I WITH DIAERESIS) I<if the pass phrase doesn't contain anything that
 would be invalid UTF-8>.
 A pass phrase that contains this kind of byte sequence will give a different
 outcome in OpenSSL 1.1.0 and newer than in OpenSSL older than 1.1.0.