Fix spelling errors in manpages

spelling: algorithm
spelling: anyway
spelling: assigned
spelling: authenticated
spelling: callback
spelling: certificate
spelling: compatibility
spelling: configuration
spelling: digest
spelling: encrypted
spelling: function
spelling: output
spelling: receive
spelling: renegotiation
spelling: signing
spelling: similar
spelling: string

(Merged from https://github.com/openssl/openssl/pull/3580)Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3580)

doc/man1/cms.pod

@@ -185,7 +185,7 @@ output an error.
 =item B<-EncryptedData_encrypt>
 
 Encrypt content using supplied symmetric key and algorithm using a CMS
-B<EncrytedData> type and output the content.
+B<EncryptedData> type and output the content.
 
 =item B<-sign_receipt>
 

doc/man3/BIO_set_callback.pod

@@ -20,8 +20,8 @@ BIO_callback_fn_ex, BIO_callback_fn
  void BIO_set_callback_ex(BIO *b, BIO_callback_fn_ex callback);
  BIO_callback_fn_ex BIO_get_callback_ex(const BIO *b);
 
- void BIO_set_callback(BIO *b, BIO_callack_fn cb);
- BIO_callack_fn BIO_get_callback(BIO *b);
+ void BIO_set_callback(BIO *b, BIO_callback_fn cb);
+ BIO_callback_fn BIO_get_callback(BIO *b);
  void BIO_set_callback_arg(BIO *b, char *arg);
  char *BIO_get_callback_arg(const BIO *b);
 
@@ -37,7 +37,7 @@ operation.
 
 BIO_set_callback() and BIO_get_callback() set and retrieve the old format BIO
 callback. New code should not use these functions, but they are retained for
-backwards compatbility. Any callback set via BIO_set_callback_ex() will get
+backwards compatibility. Any callback set via BIO_set_callback_ex() will get
 called in preference to any set by BIO_set_callback().
 
 BIO_set_callback_arg() and BIO_get_callback_arg() are macros which can be

doc/man3/EVP_DigestSignInit.pod

@@ -41,7 +41,7 @@ call is successful the signature is written to B<sig> and the amount of data
 written to B<siglen>.
 
 EVP_DigestSign() signs B<tbslen> bytes of data at B<tbs> and places the
-signature in B<sig> and its length in B<siglen> in a simiilar way to
+signature in B<sig> and its length in B<siglen> in a similar way to
 EVP_DigestSignFinal().
 
 =head1 RETURN VALUES

doc/man3/EVP_DigestVerifyInit.pod

@@ -35,7 +35,7 @@ using a macro.
 EVP_DigestVerifyFinal() verifies the data in B<ctx> against the signature in
 B<sig> of length B<siglen>.
 
-EVP_DogestVerify() verifies B<tbslen> bytes at B<tbs> against the signature
+EVP_DigestVerify() verifies B<tbslen> bytes at B<tbs> against the signature
 in B<sig> of length B<siglen>.
 
 =head1 RETURN VALUES
@@ -57,7 +57,7 @@ The B<EVP> interface to digital signatures should almost always be used in
 preference to the low level interfaces. This is because the code then becomes
 transparent to the algorithm used and much more flexible.
 
-EVP_DigesVerify() is a one shot operation which verifies a single block of
+EVP_DigestVerify() is a one shot operation which verifies a single block of
 data in one function. For algorithms that support streaming it is equivalent
 to calling EVP_DigestVerifyUpdate() and EVP_DigestVerifyFinal(). For
 algorithms which do not support streaming (e.g. PureEdDSA) it is the only way

doc/man3/PKCS7_sign.pod

@@ -47,7 +47,7 @@ required by the S/MIME specifications) if B<PKCS7_BINARY> is set no translation
 occurs. This option should be used if the supplied data is in binary format
 otherwise the translation will corrupt it.
 
-The signedData structure includes several PKCS#7 autenticatedAttributes
+The signedData structure includes several PKCS#7 authenticatedAttributes
 including the signing time, the PKCS#7 content type and the supported list of
 ciphers in an SMIMECapabilities attribute. If B<PKCS7_NOATTR> is set then no
 authenticatedAttributes will be used. If B<PKCS7_NOSMIMECAP> is set then just

doc/man3/PKCS7_sign_add_signer.pod

@@ -56,7 +56,7 @@ B<signcert> parameter though. This can reduce the size of the signature if the
 signers certificate can be obtained by other means: for example a previously
 signed message.
 
-The signedData structure includes several PKCS#7 autenticatedAttributes
+The signedData structure includes several PKCS#7 authenticatedAttributes
 including the signing time, the PKCS#7 content type and the supported list of
 ciphers in an SMIMECapabilities attribute. If B<PKCS7_NOATTR> is set then no
 authenticatedAttributes will be used. If B<PKCS7_NOSMIMECAP> is set then just

doc/man3/SSL_CTX_config.pod

@@ -40,7 +40,8 @@ If the file "config.cnf" contains the following:
  testapp = test_sect
 
  [test_sect]
- # list of confuration modules
+ # list of configuration modules
+
  ssl_conf = ssl_sect
 
  [ssl_sect]

doc/man3/SSL_CTX_set_early_cb.pod

@@ -82,7 +82,7 @@ SSL_early_isv2() returns 1 for SSLv2-format ClientHellos and 0 otherwise.
 
 SSL_early_get0_random(), SSL_early_get0_session_id(), SSL_early_get0_ciphers(),
 and SSL_early_get0_compression_methods() return the length of the corresponding
-ClientHello fields.  If zero is returned, the ouput pointer should not be
+ClientHello fields.  If zero is returned, the output pointer should not be
 assumed to be valid.
 
 SSL_early_get0_ext() returns 1 if the extension of type 'type' is present, and

doc/man3/SSL_CTX_set_record_padding_callback.pod

@@ -54,7 +54,7 @@ or SSL_set_record_padding_callback_arg().
 =head1 RETURN VALUES
 
 The SSL_CTX_get_record_padding_callback_arg() and SSL_get_record_padding_callback_arg()
-functions return the B<arg> value assignd in the corresponding set functions.
+functions return the B<arg> value assigned in the corresponding set functions.
 
 The SSL_CTX_set_block_padding() and SSL_set_block_padding() functions return 1 on success
 or 0 if B<block_size> is too large.

doc/man3/SSL_key_update.pod

@@ -74,7 +74,7 @@ new handshake. For historical reasons, DTLS clients will not attempt to resume
 the session in the new handshake.
 
 The SSL_renegotiate_pending() function returns 1 if a renegotiation or
-rengotiation request has been scheduled but not yet acted on, or 0 otherwise.
+renegotiation request has been scheduled but not yet acted on, or 0 otherwise.
 
 =head1 RETURN VALUES
 
@@ -84,7 +84,7 @@ on success or 0 on error.
 SSL_get_key_update_type() returns the update type of the pending key update
 operation or SSL_KEY_UPDATE_NONE if there is none.
 
-SSL_renegotiate_pending() returns 1 if a renegotiation or rengotiation request
+SSL_renegotiate_pending() returns 1 if a renegotiation or renegotiation request
 has been scheduled but not yet acted on, or 0 otherwise.
 
 =head1 SEE ALSO

doc/man3/SSL_read_early_data.pod

@@ -30,7 +30,7 @@ SSL_get_early_data_status
 
 =head1 DESCRIPTION
 
-These functions are used to send and recieve early data where TLSv1.3 has been
+These functions are used to send and receive early data where TLSv1.3 has been
 negotiated. Early data can be sent by the client immediately after its initial
 ClientHello without having to wait for the server to complete the handshake.
 Early data can only be sent if a session has previously been established with
@@ -152,7 +152,7 @@ connection immediately without further need to call a function such as
 L<SSL_accept(3)>. This can happen if the client is using a protocol version less
 than TLSv1.3. Applications can test for this by calling
 L<SSL_is_init_finished(3)>. Alternatively, applications may choose to call
-L<SSL_accept(3)> anway. Such a call will successfully return immediately with no
+L<SSL_accept(3)> anyway. Such a call will successfully return immediately with no
 further action taken.
 
 When a session is created between a server and a client the server will specify

doc/man3/SSL_write.pod

@@ -25,7 +25,7 @@ SSL_write_ex(), or SSL_write().
 If necessary, a write function will negotiate a TLS/SSL session, if not already
 explicitly performed by L<SSL_connect(3)> or L<SSL_accept(3)>. If the peer
 requests a re-negotiation, it will be performed transparently during
-the write functio operation. The behaviour of the write functions depends on the
+the write function operation. The behaviour of the write functions depends on the
 underlying BIO.
 
 For the transparent negotiation to succeed, the B<ssl> must have been

doc/man3/X509_get0_notBefore.pod

@@ -36,7 +36,7 @@ the call.
 X509_getm_notBefore() and X509_getm_notAfter() are similar to
 X509_get0_notBefore() and X509_get0_notAfter() except they return
 non-constant mutable references to the associated date field of
-the certficate.
+the certificate.
 
 X509_set1_notBefore() and X509_set1_notAfter() set the B<notBefore>
 and B<notAfter> fields of B<x> to B<tm>. Ownership of the passed

doc/man3/d2i_X509.pod

@@ -465,7 +465,7 @@ Represents a PKCS#1 RSA public key structure.
 
 =item B<X509_ALGOR>
 
-Represents an B<AlogrithmIdentifier> structure as used in IETF RFC 6960 and
+Represents an B<AlgorithmIdentifier> structure as used in IETF RFC 6960 and
 elsewhere.
 
 =item B<X509_Name>

doc/man5/x509v3_config.pod

@@ -350,7 +350,7 @@ Example:
  noticeNumbers=1,2,3,4
 
 The B<ia5org> option changes the type of the I<organization> field. In RFC2459
-it can only be of type DisplayText. In RFC3280 IA5Strring is also permissible.
+it can only be of type DisplayText. In RFC3280 IA5String is also permissible.
 Some software (for example some versions of MSIE) may require ia5org.
 
 ASN1 type of explicitText can be specified by prepending B<UTF8>,

doc/man7/RSA-PSS.pod

@@ -28,7 +28,7 @@ but with some restrictions described below.
 
 =head1 SIGNING AND VERIFICATION
 
-Siging and verification is similar to the B<RSA> algorithm except the
+Signing and verification is similar to the B<RSA> algorithm except the
 padding mode is always PSS. If the key in use has parameter restrictions then
 the corresponding signature parameters are set to the restrictions:
 for example, if the key can only be used with digest SHA256, MGF1 SHA256