typos in documentation; better wording, suggested by jmc@

ok jmc@

27 files changed, 63 insertions, 57 deletions

diff --git a/lib/libcrypto/man/ASN1_generate_nconf.3 b/lib/libcrypto/man/ASN1_generate_nconf.3
index af5b1c8a5df..abea69c0563 100644
--- a/lib/libcrypto/man/ASN1_generate_nconf.3
+++ b/lib/libcrypto/man/ASN1_generate_nconf.3
@@ -1,4 +1,4 @@
-.Dd $Mdocdate: September 9 2015 $
+.Dd $Mdocdate: September 22 2015 $
 .Dt ASN1_GENERATE_NCONF 3
 .Os
 .Sh NAME
@@ -251,7 +251,7 @@ A BITSTRING with bits 1 and 5 set and all others zero:
 .Dl FORMAT:BITLIST,BITSTRING:1,5
 .Pp
 A more complex example using a config file to produce a
-SEQUENCE consiting of a BOOL an OID and a UTF8String:
+SEQUENCE consisting of a BOOL an OID and a UTF8String:
 .Bd -literal -offset indent
 asn1 = SEQUENCE:seq_section
 
diff --git a/lib/libcrypto/man/BUF_MEM_new.3 b/lib/libcrypto/man/BUF_MEM_new.3
index a423d4e0bc9..f87e4f82577 100644
--- a/lib/libcrypto/man/BUF_MEM_new.3
+++ b/lib/libcrypto/man/BUF_MEM_new.3
@@ -1,4 +1,4 @@
-.Dd $Mdocdate: May 24 2015 $
+.Dd $Mdocdate: September 22 2015 $
 .Dt BUF_MEM_NEW 3
 .Os
 .Sh NAME
@@ -76,7 +76,7 @@ will accept a
 argument and will return
 .Dv NULL
 in that case.
-Its use in new programes is discouraged.
+Its use in new programs is discouraged.
 .Pp
 The memory allocated from
 .Fn BUF_strdup
diff --git a/lib/libssl/src/doc/crypto/CONF_modules_load_file.pod b/lib/libssl/src/doc/crypto/CONF_modules_load_file.pod
index c7994560c04..e663ac5bc94 100644
--- a/lib/libssl/src/doc/crypto/CONF_modules_load_file.pod
+++ b/lib/libssl/src/doc/crypto/CONF_modules_load_file.pod
@@ -19,9 +19,9 @@ The function CONF_modules_load_file() configures OpenSSL using file
 B<filename> and application name B<appname>. If B<filename> is NULL
 the standard OpenSSL configuration file is used. If B<appname> is
 NULL the standard OpenSSL application name B<openssl_conf> is used.
-The behaviour can be cutomized using B<flags>.
+The behaviour can be customized using B<flags>.
 
-CONF_modules_load() is idential to CONF_modules_load_file() except it
+CONF_modules_load() is identical to CONF_modules_load_file() except it
 read configuration information from B<cnf>.
 
 =head1 NOTES
diff --git a/lib/libssl/src/doc/crypto/EC_GROUP_copy.pod b/lib/libssl/src/doc/crypto/EC_GROUP_copy.pod
index 49dc01ced14..d4896af1d54 100644
--- a/lib/libssl/src/doc/crypto/EC_GROUP_copy.pod
+++ b/lib/libssl/src/doc/crypto/EC_GROUP_copy.pod
@@ -74,7 +74,7 @@ If the asn1_flag is 1 then this is a named curve with an associated ASN1 OID. If
 EC_GROUP_get_asn1_flag and EC_GROUP_set_asn1_flag get and set the status of the asn1_flag for the curve. If set then
 the curve_name must also be set.
 
-The point_coversion_form for a curve controls how EC_POINT data is encoded as ASN1 as defined in X9.62 (ECDSA).
+The point_conversion_form for a curve controls how EC_POINT data is encoded as ASN1 as defined in X9.62 (ECDSA).
 point_conversion_form_t is an enum defined as follows: 
 
  typedef enum {
@@ -135,7 +135,7 @@ or a pentanomial of the form:
 f(x) = x^m + x^k3 + x^k2 + x^k1 + 1 with m > k3 > k2 > k1 >= 1
 
 The function EC_GROUP_get_basis_type returns a NID identifying whether a trinomial or pentanomial is in use for the field. The
-function EC_GROUP_get_trinomial_basis must only be called where f(x) is of the trinomial form, and returns the value of B<k>. Similary
+function EC_GROUP_get_trinomial_basis must only be called where f(x) is of the trinomial form, and returns the value of B<k>. Similarly
 the function EC_GROUP_get_pentanomial_basis must only be called where f(x) is of the pentanomial form, and returns the values of B<k1>,
 B<k2> and B<k3> respectively.
 
diff --git a/lib/libssl/src/doc/crypto/EC_GROUP_new.pod b/lib/libssl/src/doc/crypto/EC_GROUP_new.pod
index ff55bf33a3c..9ab3566e657 100644
--- a/lib/libssl/src/doc/crypto/EC_GROUP_new.pod
+++ b/lib/libssl/src/doc/crypto/EC_GROUP_new.pod
@@ -48,8 +48,8 @@ EC_GROUP_set_curve_GFp sets the curve parameters B<p>, B<a> and B<b> for a curve
 EC_group_get_curve_GFp obtains the previously set curve parameters.
 
 EC_GROUP_set_curve_GF2m sets the equivalent curve parameters for a curve over F2^m. In this case B<p> represents
-the irreducible polybnomial - each bit represents a term in the polynomial. Therefore there will either be three
-or five bits set dependant on whether the polynomial is a trinomial or a pentanomial.
+the irreducible polynomial - each bit represents a term in the polynomial. Therefore there will either be three
+or five bits set dependent on whether the polynomial is a trinomial or a pentanomial.
 EC_group_get_curve_GF2m obtains the previously set curve parameters.
 
 The functions EC_GROUP_new_curve_GFp and EC_GROUP_new_curve_GF2m are shortcuts for calling EC_GROUP_new and the
diff --git a/lib/libssl/src/doc/crypto/EC_KEY_new.pod b/lib/libssl/src/doc/crypto/EC_KEY_new.pod
index 7f8f991ac75..02d7bac82ce 100644
--- a/lib/libssl/src/doc/crypto/EC_KEY_new.pod
+++ b/lib/libssl/src/doc/crypto/EC_KEY_new.pod
@@ -40,7 +40,7 @@ EC_KEY_new, EC_KEY_get_flags, EC_KEY_set_flags, EC_KEY_clear_flags, EC_KEY_new_b
 
 =head1 DESCRIPTION
 
-An EC_KEY represents a public key and (optionaly) an associated private key. A new EC_KEY (with no associated curve) can be constructed by calling EC_KEY_new.
+An EC_KEY represents a public key and (optionally) an associated private key. A new EC_KEY (with no associated curve) can be constructed by calling EC_KEY_new.
 The reference count for the newly created EC_KEY is initially set to 1. A curve can be associated with the EC_KEY by calling
 EC_KEY_set_group.
 
@@ -77,7 +77,7 @@ along with the private key. If EC_PKEY_NO_PUBKEY is set then the public key is n
 The functions EC_KEY_get_conv_form and EC_KEY_set_conv_form get and set the point_conversion_form for the B<key>. For a description
 of point_conversion_forms please refer to L<EC_POINT_new(3)|EC_POINT_new(3)>.
 
-EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitary additional data specific to the
+EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitrary additional data specific to the
 elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B<data> parameter, which must have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted.
 
 EC_KEY_set_flags sets the flags in the B<flags> parameter on the EC_KEY object. Any flags that are already set are left set. The currently defined standard flags are EC_FLAG_NON_FIPS_ALLOW and EC_FLAG_FIPS_CHECKED. In addition there is the flag EC_FLAG_COFACTOR_ECDH which is specific to ECDH and is defined in ecdh.h. EC_KEY_get_flags returns the current flags that are set for this EC_KEY. EC_KEY_clear_flags clears the flags indicated by the B<flags> parameter. All other flags are left in their existing state.
diff --git a/lib/libssl/src/doc/crypto/EVP_BytesToKey.pod b/lib/libssl/src/doc/crypto/EVP_BytesToKey.pod
index a27146f5c97..2dffaa1efa2 100644
--- a/lib/libssl/src/doc/crypto/EVP_BytesToKey.pod
+++ b/lib/libssl/src/doc/crypto/EVP_BytesToKey.pod
@@ -46,7 +46,7 @@ enough data is available for the key and IV. D_i is defined as:
 
 	D_i = HASH^count(D_(i-1) || data || salt)
 
-where || denotes concatentaion, D_0 is empty, HASH is the digest
+where || denotes concatenation, D_0 is empty, HASH is the digest
 algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data)
 is HASH(HASH(data)) and so on.
 
diff --git a/lib/libssl/src/doc/crypto/EVP_DigestSignInit.pod b/lib/libssl/src/doc/crypto/EVP_DigestSignInit.pod
index 7fd4c22e795..00205d2ae98 100644
--- a/lib/libssl/src/doc/crypto/EVP_DigestSignInit.pod
+++ b/lib/libssl/src/doc/crypto/EVP_DigestSignInit.pod
@@ -27,7 +27,7 @@ be used to set alternative signing options.
 EVP_DigestSignUpdate() hashes B<cnt> bytes of data at B<d> into the
 signature context B<ctx>. This function can be called several times on the
 same B<ctx> to include additional data. This function is currently implemented
-usig a macro.
+using a macro.
 
 EVP_DigestSignFinal() signs the data in B<ctx> places the signature in B<sig>.
 If B<sig> is B<NULL> then the maximum size of the output buffer is written to
diff --git a/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod b/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
index a0a782e7728..e9254de3d26 100644
--- a/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
+++ b/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
@@ -105,7 +105,7 @@ EVP_aes_192_ccm, EVP_aes_256_ccm - EVP cipher routines
 The EVP cipher routines are a high level interface to certain
 symmetric ciphers.
 
-EVP_CIPHER_CTX_init() initializes cipher contex B<ctx>.
+EVP_CIPHER_CTX_init() initializes cipher context B<ctx>.
 
 EVP_EncryptInit_ex() sets up cipher context B<ctx> for encryption
 with cipher B<type> from ENGINE B<impl>. B<ctx> must be initialized
diff --git a/lib/libssl/src/doc/crypto/EVP_PKEY_CTX_ctrl.pod b/lib/libssl/src/doc/crypto/EVP_PKEY_CTX_ctrl.pod
index 91125da62ef..e8776e1e678 100644
--- a/lib/libssl/src/doc/crypto/EVP_PKEY_CTX_ctrl.pod
+++ b/lib/libssl/src/doc/crypto/EVP_PKEY_CTX_ctrl.pod
@@ -90,7 +90,7 @@ B<PSS> block structure. If this macro is not called a salt length value of -2
 is used by default.
 
 The EVP_PKEY_CTX_set_rsa_rsa_keygen_bits() macro sets the RSA key length for
-RSA key genration to B<bits>. If not specified 1024 bits is used.
+RSA key generation to B<bits>. If not specified 1024 bits is used.
 
 The EVP_PKEY_CTX_set_rsa_keygen_pubexp() macro sets the public exponent value
 for RSA key generation to B<pubexp> currently it should be an odd integer. The
diff --git a/lib/libssl/src/doc/crypto/EVP_PKEY_CTX_new.pod b/lib/libssl/src/doc/crypto/EVP_PKEY_CTX_new.pod
index 9822d6806ff..60ad61e8534 100644
--- a/lib/libssl/src/doc/crypto/EVP_PKEY_CTX_new.pod
+++ b/lib/libssl/src/doc/crypto/EVP_PKEY_CTX_new.pod
@@ -22,7 +22,7 @@ the algorithm specified in B<pkey> and ENGINE B<e>.
 The EVP_PKEY_CTX_new_id() function allocates public key algorithm context
 using the algorithm specified by B<id> and ENGINE B<e>. It is normally used
 when no B<EVP_PKEY> structure is associated with the operations, for example
-during parameter generation of key genration for some algorithms.
+during parameter generation of key generation for some algorithms.
 
 EVP_PKEY_CTX_dup() duplicates the context B<ctx>.
 
diff --git a/lib/libssl/src/doc/crypto/EVP_PKEY_cmp.pod b/lib/libssl/src/doc/crypto/EVP_PKEY_cmp.pod
index c3892160866..7a690247bfc 100644
--- a/lib/libssl/src/doc/crypto/EVP_PKEY_cmp.pod
+++ b/lib/libssl/src/doc/crypto/EVP_PKEY_cmp.pod
@@ -24,10 +24,10 @@ doesn't use parameters.
 The function EVP_PKEY_copy_parameters() copies the parameters from key
 B<from> to key B<to>.
 
-The funcion EVP_PKEY_cmp_parameters() compares the parameters of keys
+The function EVP_PKEY_cmp_parameters() compares the parameters of keys
 B<a> and B<b>.
 
-The funcion EVP_PKEY_cmp() compares the public key components and paramters
+The function EVP_PKEY_cmp() compares the public key components and parameters
 (if present) of keys B<a> and B<b>.
 
 =head1 NOTES
diff --git a/lib/libssl/src/doc/crypto/EVP_PKEY_keygen.pod b/lib/libssl/src/doc/crypto/EVP_PKEY_keygen.pod
index 05ea04be11f..463c44170e4 100644
--- a/lib/libssl/src/doc/crypto/EVP_PKEY_keygen.pod
+++ b/lib/libssl/src/doc/crypto/EVP_PKEY_keygen.pod
@@ -29,7 +29,7 @@ EVP_PKEY_CTX_get_app_data - key and parameter generation functions
 =head1 DESCRIPTION
 
 The EVP_PKEY_keygen_init() function initializes a public key algorithm
-context using key B<pkey> for a key genration operation.
+context using key B<pkey> for a key generation operation.
 
 The EVP_PKEY_keygen() function performs a key generation operation, the
 generated key is written to B<ppkey>.
@@ -47,7 +47,7 @@ parameters available is returned. Any non negative value returns the value of
 that parameter. EVP_PKEY_CTX_gen_keygen_info() with a non-negative value for
 B<idx> should only be called within the generation callback.
 
-If the callback returns 0 then the key genration operation is aborted and an
+If the callback returns 0 then the key generation operation is aborted and an
 error occurs. This might occur during a time consuming operation where
 a user clicks on a "cancel" button.
 
@@ -67,7 +67,7 @@ once on the same context if several operations are performed using the same
 parameters.
 
 The meaning of the parameters passed to the callback will depend on the
-algorithm and the specifiic implementation of the algorithm. Some might not
+algorithm and the specific implementation of the algorithm. Some might not
 give any useful information at all during key or parameter generation. Others
 might not even call the callback.
 
diff --git a/lib/libssl/src/doc/crypto/OBJ_nid2obj.pod b/lib/libssl/src/doc/crypto/OBJ_nid2obj.pod
index 3656390eadd..95949ac0918 100644
--- a/lib/libssl/src/doc/crypto/OBJ_nid2obj.pod
+++ b/lib/libssl/src/doc/crypto/OBJ_nid2obj.pod
@@ -43,7 +43,7 @@ for the object B<o>, the long name <ln> or the short name <sn> respectively
 or NID_undef if an error occurred.
 
 OBJ_txt2nid() returns NID corresponding to text string <s>. B<s> can be
-a long name, a short name or the numerical respresentation of an object.
+a long name, a short name or the numerical representation of an object.
 
 OBJ_txt2obj() converts the text string B<s> into an ASN1_OBJECT structure.
 If B<no_name> is 0 then long names and short names will be interpreted
diff --git a/lib/libssl/src/doc/crypto/PKCS12_create.pod b/lib/libssl/src/doc/crypto/PKCS12_create.pod
index 12fbd20b8ab..3b27c11a104 100644
--- a/lib/libssl/src/doc/crypto/PKCS12_create.pod
+++ b/lib/libssl/src/doc/crypto/PKCS12_create.pod
@@ -17,11 +17,11 @@ PKCS12_create - create a PKCS#12 structure
 PKCS12_create() creates a PKCS#12 structure.
 
 B<pass> is the passphrase to use. B<name> is the B<friendlyName> to use for
-the supplied certifictate and key. B<pkey> is the private key to include in
+the supplied certificate and key. B<pkey> is the private key to include in
 the structure and B<cert> its corresponding certificates. B<ca> is an optional
 set of certificates to also include in the structure.
 Either B<pkey>, B<cert> or both can be B<NULL> to indicate that no key or
-certficate is required.
+certificate is required.
 
 B<nid_key> and B<nid_cert> are the encryption algorithms that should be used
 for the key and certificate respectively. If either B<nid_key> or B<nid_cert>
diff --git a/lib/libssl/src/doc/crypto/PKCS7_sign.pod b/lib/libssl/src/doc/crypto/PKCS7_sign.pod
index 9a4f5b173ee..64a3036c0a6 100644
--- a/lib/libssl/src/doc/crypto/PKCS7_sign.pod
+++ b/lib/libssl/src/doc/crypto/PKCS7_sign.pod
@@ -13,7 +13,7 @@ PKCS7_sign - create a PKCS#7 signedData structure
 =head1 DESCRIPTION
 
 PKCS7_sign() creates and returns a PKCS#7 signedData structure. B<signcert> is
-the certificate to sign with, B<pkey> is the corresponsding private key.
+the certificate to sign with, B<pkey> is the corresponding private key.
 B<certs> is an optional additional set of certificates to include in the PKCS#7
 structure (for example any intermediate CAs in the chain).
 
@@ -46,7 +46,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
diff --git a/lib/libssl/src/doc/crypto/PKCS7_sign_add_signer.pod b/lib/libssl/src/doc/crypto/PKCS7_sign_add_signer.pod
index afe8ad97cd4..280455d476c 100644
--- a/lib/libssl/src/doc/crypto/PKCS7_sign_add_signer.pod
+++ b/lib/libssl/src/doc/crypto/PKCS7_sign_add_signer.pod
@@ -40,7 +40,7 @@ Any of the following flags (ored together) can be passed in the B<flags>
 parameter.
 
 If B<PKCS7_REUSE_DIGEST> is set then an attempt is made to copy the content
-digest value from the PKCS7 struture: to add a signer to an existing structure.
+digest value from the PKCS7 structure: to add a signer to an existing structure.
 An error occurs if a matching digest value cannot be found to copy. The
 returned PKCS7 structure will be valid and finalized when this flag is set.
 
@@ -55,7 +55,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
diff --git a/lib/libssl/src/doc/crypto/PKCS7_verify.pod b/lib/libssl/src/doc/crypto/PKCS7_verify.pod
index 781c6108a93..059fbff8e9c 100644
--- a/lib/libssl/src/doc/crypto/PKCS7_verify.pod
+++ b/lib/libssl/src/doc/crypto/PKCS7_verify.pod
@@ -16,7 +16,7 @@ PKCS7_verify, PKCS7_get0_signers - verify a PKCS#7 signedData structure
 
 PKCS7_verify() verifies a PKCS#7 signedData structure. B<p7> is the PKCS7
 structure to verify. B<certs> is a set of certificates in which to search for
-the signer's certificate. B<store> is a trusted certficate store (used for
+the signer's certificate. B<store> is a trusted certificate store (used for
 chain verification). B<indata> is the signed data if the content is not
 present in B<p7> (that is it is detached). The content is written to B<out>
 if it is not NULL.
diff --git a/lib/libssl/src/doc/crypto/SMIME_write_PKCS7.pod b/lib/libssl/src/doc/crypto/SMIME_write_PKCS7.pod
index 2cfad2e0497..4a7cd08c424 100644
--- a/lib/libssl/src/doc/crypto/SMIME_write_PKCS7.pod
+++ b/lib/libssl/src/doc/crypto/SMIME_write_PKCS7.pod
@@ -6,17 +6,18 @@ SMIME_write_PKCS7 - convert PKCS#7 structure to S/MIME format.
 
 =head1 SYNOPSIS
 
-int SMIME_write_PKCS7(BIO *out, PKCS7 *p7, BIO *data, int flags);
+ #include <openssl/pkcs7.h>
+
+ int SMIME_write_PKCS7(BIO *out, PKCS7 *p7, BIO *data, int flags);
 
 =head1 DESCRIPTION
 
 SMIME_write_PKCS7() adds the appropriate MIME headers to a PKCS#7
 structure to produce an S/MIME message.
 
-B<out> is the BIO to write the data to. B<p7> is the appropriate
-B<PKCS7> structure. If cleartext signing (B<multipart/signed>) is
-being used then the signed data must be supplied in the B<data> 
-argument. B<flags> is an optional set of flags.
+B<out> is the BIO to write the data to. B<p7> is the appropriate B<PKCS7>
+structure. If streaming is enabled then the content must be supplied in the
+B<data> argument. B<flags> is an optional set of flags.
 
 =head1 NOTES
 
@@ -30,18 +31,23 @@ If the B<PKCS7_TEXT> flag is set MIME headers for type B<text/plain>
 are added to the content, this only makes sense if B<PKCS7_DETACHED>
 is also set.
 
-If cleartext signing is being used then the data must be read twice:
-once to compute the signature in PKCS7_sign() and once to output the
-S/MIME message.
+If the B<PKCS7_STREAM> flag is set streaming is performed. This flag should
+only be set if B<PKCS7_STREAM> was also set in the previous call to
+PKCS7_sign() or B<PKCS7_encrypt()>.
+
+If cleartext signing is being used and B<PKCS7_STREAM> not set then
+the data must be read twice: once to compute the signature in PKCS7_sign()
+and once to output the S/MIME message.
+
+If streaming is performed the content is output in BER format using indefinite
+length constructed encoding except in the case of signed data with detached
+content where the content is absent and DER format is used.
 
 =head1 BUGS
 
 SMIME_write_PKCS7() always base64 encodes PKCS#7 structures, there
 should be an option to disable this.
 
-There should really be a way to produce cleartext signing using only
-a single pass of the data.
-
 =head1 RETURN VALUES
 
 SMIME_write_PKCS7() returns 1 for success or 0 for failure.
diff --git a/lib/libssl/src/doc/crypto/X509_NAME_add_entry_by_txt.pod b/lib/libssl/src/doc/crypto/X509_NAME_add_entry_by_txt.pod
index c6442b947fe..f97e05e683f 100644
--- a/lib/libssl/src/doc/crypto/X509_NAME_add_entry_by_txt.pod
+++ b/lib/libssl/src/doc/crypto/X509_NAME_add_entry_by_txt.pod
@@ -45,7 +45,7 @@ B<loc>. The deleted entry is returned and must be freed up.
 =head1 NOTES
 
 The use of string types such as B<MBSTRING_ASC> or B<MBSTRING_UTF8>
-is strongly recommened for the B<type> parameter. This allows the
+is strongly recommended for the B<type> parameter. This allows the
 internal code to correctly determine the type of the field and to
 apply length checks according to the relevant standards. This is
 done using ASN1_STRING_set_by_NID().
diff --git a/lib/libssl/src/doc/crypto/X509_NAME_get_index_by_NID.pod b/lib/libssl/src/doc/crypto/X509_NAME_get_index_by_NID.pod
index 988fd7bdafd..48510890e89 100644
--- a/lib/libssl/src/doc/crypto/X509_NAME_get_index_by_NID.pod
+++ b/lib/libssl/src/doc/crypto/X509_NAME_get_index_by_NID.pod
@@ -51,7 +51,7 @@ X509_NAME_get_text_by_NID() and X509_NAME_get_text_by_OBJ() are
 legacy functions which have various limitations which make them
 of minimal use in practice. They can only find the first matching
 entry and will copy the contents of the field verbatim: this can
-be highly confusing if the target is a muticharacter string type
+be highly confusing if the target is a multicharacter string type
 like a BMPString or a UTF8String.
 
 For a more general solution X509_NAME_get_index_by_NID() or
diff --git a/lib/libssl/src/doc/crypto/X509_STORE_CTX_get_error.pod b/lib/libssl/src/doc/crypto/X509_STORE_CTX_get_error.pod
index e4339dc28f2..270b265ce5c 100644
--- a/lib/libssl/src/doc/crypto/X509_STORE_CTX_get_error.pod
+++ b/lib/libssl/src/doc/crypto/X509_STORE_CTX_get_error.pod
@@ -35,7 +35,7 @@ checks.
 
 X509_STORE_CTX_get_error_depth() returns the B<depth> of the error. This is a
 non-negative integer representing where in the certificate chain the error
-occurred. If it is zero it occured in the end entity certificate, one if
+occurred. If it is zero it occurred in the end entity certificate, one if
 it is the certificate which signed the end entity certificate and so on.
 
 X509_STORE_CTX_get_current_cert() returns the certificate in B<ctx> which
@@ -58,7 +58,7 @@ X509_STORE_CTX_get_error() returns B<X509_V_OK> or an error code.
 
 X509_STORE_CTX_get_error_depth() returns a non-negative error depth.
 
-X509_STORE_CTX_get_current_cert() returns the cerificate which caused the
+X509_STORE_CTX_get_current_cert() returns the certificate which caused the
 error or B<NULL> if no certificate is relevant to the error.
 
 X509_verify_cert_error_string() returns a human readable error string for
@@ -265,11 +265,11 @@ Some feature of a certificate extension is not supported. Unused.
 
 =item B<X509_V_ERR_PERMITTED_VIOLATION: permitted subtree violation>
 
-A name constraint violation occured in the permitted subtrees.
+A name constraint violation occurred in the permitted subtrees.
 
 =item B<X509_V_ERR_EXCLUDED_VIOLATION: excluded subtree violation>
 
-A name constraint violation occured in the excluded subtrees.
+A name constraint violation occurred in the excluded subtrees.
 
 =item B<X509_V_ERR_SUBTREE_MINMAX: name constraints minimum and maximum not
 supported>
@@ -292,7 +292,7 @@ a garbage extension or some new feature not currently supported.
 
 =item B<X509_V_ERR_CRL_PATH_VALIDATION_ERROR: CRL path validation error>
 
-An error occured when attempting to verify the CRL path. This error can only
+An error occurred when attempting to verify the CRL path. This error can only
 happen if extended CRL checking is enabled.
 
 =item B<X509_V_ERR_APPLICATION_VERIFICATION: application verification failure>
diff --git a/lib/libssl/src/doc/crypto/X509_STORE_CTX_new.pod b/lib/libssl/src/doc/crypto/X509_STORE_CTX_new.pod
index 8f602274eea..66c0da04d25 100644
--- a/lib/libssl/src/doc/crypto/X509_STORE_CTX_new.pod
+++ b/lib/libssl/src/doc/crypto/X509_STORE_CTX_new.pod
@@ -52,7 +52,7 @@ X509_STORE_CTX_trusted_stack() sets the set of trusted certificates of B<ctx>
 to B<sk>. This is an alternative way of specifying trusted certificates
 instead of using an B<X509_STORE>.
 
-X509_STORE_CTX_set_cert() sets the certificate to be vertified in B<ctx> to
+X509_STORE_CTX_set_cert() sets the certificate to be verified in B<ctx> to
 B<x>.
 
 X509_STORE_CTX_set_chain() sets the additional certificate chain used by B<ctx>
@@ -64,10 +64,10 @@ enabled in the associated B<X509_VERIFY_PARAM> structure. This might be
 used where additional "useful" CRLs are supplied as part of a protocol,
 for example in a PKCS#7 structure.
 
-X509_VERIFY_PARAM *X509_STORE_CTX_get0_param() retrieves an intenal pointer
+X509_VERIFY_PARAM *X509_STORE_CTX_get0_param() retrieves an internal pointer
 to the verification parameters associated with B<ctx>.
 
-X509_STORE_CTX_set0_param() sets the intenal verification parameter pointer
+X509_STORE_CTX_set0_param() sets the internal verification parameter pointer
 to B<param>. After this call B<param> should not be used.
 
 X509_STORE_CTX_set_default() looks up and sets the default verification
diff --git a/lib/libssl/src/doc/crypto/X509_VERIFY_PARAM_set_flags.pod b/lib/libssl/src/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
index 6acdd71e72d..6c88aec49eb 100644
--- a/lib/libssl/src/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
+++ b/lib/libssl/src/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
@@ -126,7 +126,7 @@ If B<X509_V_FLAG_USE_DELTAS> ise set delta CRLs (if present) are used to
 determine certificate status. If not set deltas are ignored.
 
 B<X509_V_FLAG_CHECK_SS_SIGNATURE> enables checking of the root CA self signed
-cerificate signature. By default this check is disabled because it doesn't
+certificate signature. By default this check is disabled because it doesn't
 add any additional security but in some cases applications might want to
 check the signature anyway. A side effect of not checking the root CA
 signature is that disabled or unsupported message digests on the root CA
diff --git a/lib/libssl/src/doc/crypto/X509_verify_cert.pod b/lib/libssl/src/doc/crypto/X509_verify_cert.pod
index 5253bdcd707..f05edd83338 100644
--- a/lib/libssl/src/doc/crypto/X509_verify_cert.pod
+++ b/lib/libssl/src/doc/crypto/X509_verify_cert.pod
@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-X509_verify_cert - discover and verify X509 certificte chain
+X509_verify_cert - discover and verify X509 certificate chain
 
 =head1 SYNOPSIS
 
@@ -40,7 +40,7 @@ for <= 0 return value on error.
 =head1 BUGS
 
 This function uses the header B<x509.h> as opposed to most chain verification
-functiosn which use B<x509_vfy.h>.
+functions which use B<x509_vfy.h>.
 
 =head1 SEE ALSO
 
diff --git a/lib/libssl/src/doc/crypto/d2i_DSAPublicKey.pod b/lib/libssl/src/doc/crypto/d2i_DSAPublicKey.pod
index eeb96c485f9..10c49e3ad28 100644
--- a/lib/libssl/src/doc/crypto/d2i_DSAPublicKey.pod
+++ b/lib/libssl/src/doc/crypto/d2i_DSAPublicKey.pod
@@ -68,7 +68,7 @@ If B<write_params> is zero then only the B<pub_key> field is encoded as an
 B<INTEGER>. If B<write_params> is 1 then a B<SEQUENCE> consisting of the
 B<p>, B<q>, B<g> and B<pub_key> respectively fields are encoded.
 
-The B<DSAPrivateKey> functions also use a non standard structure consiting
+The B<DSAPrivateKey> functions also use a non standard structure consisting
 consisting of a SEQUENCE containing the B<p>, B<q>, B<g> and B<pub_key> and
 B<priv_key> fields respectively.
 
diff --git a/lib/libssl/src/doc/crypto/engine.pod b/lib/libssl/src/doc/crypto/engine.pod
index 80201128352..e305a732712 100644
--- a/lib/libssl/src/doc/crypto/engine.pod
+++ b/lib/libssl/src/doc/crypto/engine.pod
@@ -181,7 +181,7 @@ to use the pointer value at all, as this kind of reference is a guarantee
 that the structure can not be deallocated until the reference is released.
 
 However, a structural reference provides no guarantee that the ENGINE is
-initiliased and able to use any of its cryptographic
+initialised and able to use any of its cryptographic
 implementations. Indeed it's quite possible that most ENGINEs will not
 initialise at all in typical environments, as ENGINEs are typically used to
 support specialised hardware. To use an ENGINE's functionality, you need a
@@ -573,7 +573,7 @@ for any higher-level ENGINE functions such as ENGINE_ctrl_cmd_string().
 by applications, administrations, users, etc. These can support arbitrary
 operations via ENGINE_ctrl(), including passing to and/or from the control
 commands data of any arbitrary type. These commands are supported in the
-discovery mechanisms simply to allow applications determinie if an ENGINE
+discovery mechanisms simply allow applications to determine if an ENGINE
 supports certain specific commands it might want to use (eg. application "foo"
 might query various ENGINEs to see if they implement "FOO_GET_VENDOR_LOGO_GIF" -
 and ENGINE could therefore decide whether or not to support this "foo"-specific