Fix typos and repeated words

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12370)

15 files changed, 78 insertions, 78 deletions

diff --git a/doc/man1/CA.pl.pod b/doc/man1/CA.pl.pod
index 0176f20178..7b72e32338 100644
--- a/doc/man1/CA.pl.pod
+++ b/doc/man1/CA.pl.pod
@@ -164,7 +164,7 @@ Create the CA directories and files:
 
  CA.pl -newca
 
-enter cacert.pem when prompted for the CA file name.
+enter cacert.pem when prompted for the CA filename.
 
 Create a DSA certificate request and private key (a different set of parameters
 can optionally be created first):
diff --git a/doc/man1/ca.pod b/doc/man1/ca.pod
index 27bb31493a..1502946906 100644
--- a/doc/man1/ca.pod
+++ b/doc/man1/ca.pod
@@ -219,7 +219,7 @@ DNs match the order of the request. This is not needed for Xenroll.
 =item B<-noemailDN>
 
 The DN of a certificate can contain the EMAIL field if present in the
-request DN, however it is good policy just having the e-mail set into
+request DN, however, it is good policy just having the e-mail set into
 the altName extension of the certificate. When this option is set the
 EMAIL field is removed from the certificate' subject and set only in
 the, eventually present, extensions. The B<email_in_dn> keyword can be
diff --git a/doc/man1/enc.pod b/doc/man1/enc.pod
index 6f20ac1fc7..9f5a4f487f 100644
--- a/doc/man1/enc.pod
+++ b/doc/man1/enc.pod
@@ -240,7 +240,7 @@ a strong block cipher, such as AES, in CBC mode.
 
 All the block ciphers normally use PKCS#5 padding, also known as standard
 block padding. This allows a rudimentary integrity or password check to
-be performed. However since the chance of random data passing the test
+be performed. However, since the chance of random data passing the test
 is better than 1 in 256 it isn't a very good test.
 
 If padding is disabled then the input data must be a multiple of the cipher
diff --git a/doc/man1/ocsp.pod b/doc/man1/ocsp.pod
index 736055b1b6..d4d18f8ffd 100644
--- a/doc/man1/ocsp.pod
+++ b/doc/man1/ocsp.pod
@@ -176,7 +176,7 @@ Specify the responder URL. Both HTTP and HTTPS (SSL/TLS) URLs can be specified.
 =item B<-host hostname:port>, B<-path pathname>
 
 If the B<host> option is present then the OCSP request is sent to the host
-B<hostname> on port B<port>. B<path> specifies the HTTP path name to use
+B<hostname> on port B<port>. B<path> specifies the HTTP pathname to use
 or "/" by default.  This is equivalent to specifying B<-url> with scheme
 http:// and the given hostname, port, and pathname.
 
diff --git a/doc/man1/pkcs12.pod b/doc/man1/pkcs12.pod
index da887a4699..d07e8bd613 100644
--- a/doc/man1/pkcs12.pod
+++ b/doc/man1/pkcs12.pod
@@ -245,7 +245,7 @@ This option is only interpreted by MSIE and similar MS software. Normally
 encryption purposes but arbitrary length keys for signing. The B<-keysig>
 option marks the key for signing only. Signing only keys can be used for
 S/MIME signing, authenticode (ActiveX control signing)  and SSL client
-authentication, however due to a bug only MSIE 5.0 and later support
+authentication, however, due to a bug only MSIE 5.0 and later support
 the use of signing only keys for SSL client authentication.
 
 =item B<-macalg digest>
diff --git a/doc/man1/pkcs8.pod b/doc/man1/pkcs8.pod
index b079885d2f..53367dc650 100644
--- a/doc/man1/pkcs8.pod
+++ b/doc/man1/pkcs8.pod
@@ -285,7 +285,7 @@ one million iterations of the password:
 Test vectors from this PKCS#5 v2.0 implementation were posted to the
 pkcs-tng mailing list using triple DES, DES and RC2 with high iteration
 counts, several people confirmed that they could decrypt the private
-keys produced and Therefore it can be assumed that the PKCS#5 v2.0
+keys produced and therefore, it can be assumed that the PKCS#5 v2.0
 implementation is reasonably accurate at least as far as these
 algorithms are concerned.
 
diff --git a/doc/man1/pkeyutl.pod b/doc/man1/pkeyutl.pod
index dffc449a4e..e24021508e 100644
--- a/doc/man1/pkeyutl.pod
+++ b/doc/man1/pkeyutl.pod
@@ -38,7 +38,7 @@ B<openssl> B<pkeyutl>
 
 =head1 DESCRIPTION
 
-The B<pkeyutl> command can be used to perform low level public key operations
+The B<pkeyutl> command can be used to perform low-level public key operations
 using any supported algorithm.
 
 =head1 OPTIONS
diff --git a/doc/man1/s_client.pod b/doc/man1/s_client.pod
index 86cc295691..132778b4d9 100644
--- a/doc/man1/s_client.pod
+++ b/doc/man1/s_client.pod
@@ -427,11 +427,11 @@ File to send output of B<-msg> or B<-trace> to, default standard output.
 
 =item B<-nbio_test>
 
-Tests non-blocking I/O
+Tests nonblocking I/O
 
 =item B<-nbio>
 
-Turns on non-blocking I/O
+Turns on nonblocking I/O
 
 =item B<-crlf>
 
@@ -781,14 +781,14 @@ is that a web client complains it has no certificates or gives an empty
 list to choose from. This is normally because the server is not sending
 the clients certificate authority in its "acceptable CA list" when it
 requests a certificate. By using B<s_client> the CA list can be viewed
-and checked. However some servers only request client authentication
+and checked. However, some servers only request client authentication
 after a specific URL is requested. To obtain the list in this case it
 is necessary to use the B<-prexit> option and send an HTTP request
 for an appropriate page.
 
 If a certificate is specified on the command line using the B<-cert>
 option it will not be used unless the server specifically requests
-a client certificate. Therefore merely including a client certificate
+a client certificate. Therefore, merely including a client certificate
 on the command line is no guarantee that the certificate works.
 
 If there are problems verifying a server certificate then the
diff --git a/doc/man1/s_server.pod b/doc/man1/s_server.pod
index 7fa382a8ae..5e9d09cebf 100644
--- a/doc/man1/s_server.pod
+++ b/doc/man1/s_server.pod
@@ -432,9 +432,9 @@ used in conjunction with B<-early_data>.
 =item B<-id_prefix val>
 
 Generate SSL/TLS session IDs prefixed by B<val>. This is mostly useful
-for testing any SSL/TLS code (eg. proxies) that wish to deal with multiple
+for testing any SSL/TLS code (e.g. proxies) that wish to deal with multiple
 servers, when each of which might be generating a unique range of session
-IDs (eg. with a certain prefix).
+IDs (e.g. with a certain prefix).
 
 =item B<-rand file...>
 
diff --git a/doc/man1/s_time.pod b/doc/man1/s_time.pod
index 04cae196a5..1085bfbbb4 100644
--- a/doc/man1/s_time.pod
+++ b/doc/man1/s_time.pod
@@ -177,14 +177,14 @@ is that a web client complains it has no certificates or gives an empty
 list to choose from. This is normally because the server is not sending
 the clients certificate authority in its "acceptable CA list" when it
 requests a certificate. By using L<s_client(1)> the CA list can be
-viewed and checked. However some servers only request client authentication
+viewed and checked. However, some servers only request client authentication
 after a specific URL is requested. To obtain the list in this case it
 is necessary to use the B<-prexit> option of L<s_client(1)> and
 send an HTTP request for an appropriate page.
 
 If a certificate is specified on the command line using the B<-cert>
 option it will not be used unless the server specifically requests
-a client certificate. Therefore merely including a client certificate
+a client certificate. Therefore, merely including a client certificate
 on the command line is no guarantee that the certificate works.
 
 =head1 BUGS
diff --git a/doc/man1/sess_id.pod b/doc/man1/sess_id.pod
index 6c54ed988b..543b5b7de7 100644
--- a/doc/man1/sess_id.pod
+++ b/doc/man1/sess_id.pod
@@ -142,7 +142,7 @@ The PEM encoded session format uses the header and footer lines:
 
 Since the SSL session output contains the master key it is
 possible to read the contents of an encrypted session using this
-information. Therefore appropriate security precautions should be taken if
+information. Therefore, appropriate security precautions should be taken if
 the information is being output by a "real" application. This is however
 strongly discouraged and should only be used for debugging purposes.
 
diff --git a/doc/man1/ts.pod b/doc/man1/ts.pod
index ec57ec7ebb..a21e2a5f05 100644
--- a/doc/man1/ts.pod
+++ b/doc/man1/ts.pod
@@ -101,23 +101,23 @@ the hash to the TSA.
 =item 2.
 
 The TSA attaches the current date and time to the received hash value,
-signs them and sends the time stamp token back to the client. By
+signs them and sends the timestamp token back to the client. By
 creating this token the TSA certifies the existence of the original
 data file at the time of response generation.
 
 =item 3.
 
-The TSA client receives the time stamp token and verifies the
+The TSA client receives the timestamp token and verifies the
 signature on it. It also checks if the token contains the same hash
 value that it had sent to the TSA.
 
 =back
 
-There is one DER encoded protocol data unit defined for transporting a time
-stamp request to the TSA and one for sending the time stamp response
+There is one DER encoded protocol data unit defined for transporting 
+a timestamp request to the TSA and one for sending the timestamp response
 back to the client. The B<ts> command has three main functions:
-creating a time stamp request based on a data file,
-creating a time stamp response based on a request, verifying if a
+creating a timestamp request based on a data file,
+creating a timestamp response based on a request, verifying if a
 response corresponds to a particular request or a data file.
 
 There is no support for sending the requests/responses automatically
@@ -128,7 +128,7 @@ requests either by ftp or e-mail.
 
 =head2 Time Stamp Request generation
 
-The B<-query> switch can be used for creating and printing a time stamp
+The B<-query> switch can be used for creating and printing a timestamp
 request with the following options:
 
 =over 4
@@ -154,7 +154,7 @@ see L<openssl(1)/COMMAND SUMMARY>.
 
 =item B<-data> file_to_hash
 
-The data file for which the time stamp request needs to be
+The data file for which the timestamp request needs to be
 created. stdin is the default if neither the B<-data> nor the B<-digest>
 parameter is specified. (Optional)
 
@@ -175,7 +175,7 @@ The default is SHA-1. (Optional)
 =item B<-tspolicy> object_id
 
 The policy that the client expects the TSA to use for creating the
-time stamp token. Either the dotted OID notation or OID names defined
+timestamp token. Either the dotted OID notation or OID names defined
 in the config file can be used. If no policy is requested the TSA will
 use its own default policy. (Optional)
 
@@ -193,7 +193,7 @@ response. (Optional)
 
 =item B<-in> request.tsq
 
-This option specifies a previously created time stamp request in DER
+This option specifies a previously created timestamp request in DER
 format that will be printed into the output file. Useful when you need
 to examine the content of a request in human-readable
 format. (Optional)
@@ -212,13 +212,13 @@ instead of DER. (Optional)
 
 =head2 Time Stamp Response generation
 
-A time stamp response (TimeStampResp) consists of a response status
-and the time stamp token itself (ContentInfo), if the token generation was
-successful. The B<-reply> command is for creating a time stamp
-response or time stamp token based on a request and printing the
+A timestamp response (TimeStampResp) consists of a response status
+and the timestamp token itself (ContentInfo), if the token generation was
+successful. The B<-reply> command is for creating a timestamp
+response or timestamp token based on a request and printing the
 response/token in human-readable format. If B<-token_out> is not
-specified the output is always a time stamp response (TimeStampResp),
-otherwise it is a time stamp token (ContentInfo).
+specified the output is always a timestamp response (TimeStampResp),
+otherwise it is a timestamp token (ContentInfo).
 
 =over 4
 
@@ -237,7 +237,7 @@ used, see B<CONFIGURATION FILE OPTIONS> for details. (Optional)
 
 =item B<-queryfile> request.tsq
 
-The name of the file containing a DER encoded time stamp request. (Optional)
+The name of the file containing a DER encoded timestamp request. (Optional)
 
 =item B<-passin> password_src
 
@@ -282,19 +282,19 @@ B<default_policy> config file option. (Optional)
 
 =item B<-in> response.tsr
 
-Specifies a previously created time stamp response or time stamp token
+Specifies a previously created timestamp response or timestamp token
 (if B<-token_in> is also specified) in DER format that will be written
 to the output file. This option does not require a request, it is
 useful e.g. when you need to examine the content of a response or
-token or you want to extract the time stamp token from a response. If
-the input is a token and the output is a time stamp response a default
+token or you want to extract the timestamp token from a response. If
+the input is a token and the output is a timestamp response a default
 'granted' status info is added to the token. (Optional)
 
 =item B<-token_in>
 
 This flag can be used together with the B<-in> option and indicates
-that the input is a DER encoded time stamp token (ContentInfo) instead
-of a time stamp response (TimeStampResp). (Optional)
+that the input is a DER encoded timestamp token (ContentInfo) instead
+of a timestamp response (TimeStampResp). (Optional)
 
 =item B<-out> response.tsr
 
@@ -304,7 +304,7 @@ stdout. (Optional)
 
 =item B<-token_out>
 
-The output is a time stamp token (ContentInfo) instead of time stamp
+The output is a timestamp token (ContentInfo) instead of timestamp
 response (TimeStampResp). (Optional)
 
 =item B<-text>
@@ -323,8 +323,8 @@ for all available algorithms. Default is builtin. (Optional)
 
 =head2 Time Stamp Response verification
 
-The B<-verify> command is for verifying if a time stamp response or time
-stamp token is valid and matches a particular time stamp request or
+The B<-verify> command is for verifying if a timestamp response or 
+timestamp token is valid and matches a particular timestamp request or
 data file. The B<-verify> command does not use the configuration file.
 
 =over 4
@@ -345,18 +345,18 @@ specified with this one. (Optional)
 
 =item B<-queryfile> request.tsq
 
-The original time stamp request in DER format. The B<-data> and B<-digest>
+The original timestamp request in DER format. The B<-data> and B<-digest>
 options must not be specified with this one. (Optional)
 
 =item B<-in> response.tsr
 
-The time stamp response that needs to be verified in DER format. (Mandatory)
+The timestamp response that needs to be verified in DER format. (Mandatory)
 
 =item B<-token_in>
 
 This flag can be used together with the B<-in> option and indicates
-that the input is a DER encoded time stamp token (ContentInfo) instead
-of a time stamp response (TimeStampResp). (Optional)
+that the input is a DER encoded timestamp token (ContentInfo) instead
+of a timestamp response (TimeStampResp). (Optional)
 
 =item B<-CApath> trusted_cert_path
 
@@ -430,7 +430,7 @@ See L<ca(1)> for description. (Optional)
 =item B<serial>
 
 The name of the file containing the hexadecimal serial number of the
-last time stamp response created. This number is incremented by 1 for
+last timestamp response created. This number is incremented by 1 for
 each response. If the file does not exist at the time of response
 generation a new file is created with serial number 1. (Mandatory)
 
@@ -487,7 +487,7 @@ the components is missing zero is assumed for that field. (Optional)
 =item B<clock_precision_digits>
 
 Specifies the maximum number of digits, which represent the fraction of
-seconds, that  need to be included in the time field. The trailing zeroes
+seconds, that  need to be included in the time field. The trailing zeros
 must be removed from the time, so there might actually be fewer digits,
 or no fraction of seconds at all. Supported only on UNIX platforms.
 The maximum value is 6, default is 0.
@@ -530,13 +530,13 @@ openssl/apps/openssl.cnf will do.
 
 =head2 Time Stamp Request
 
-To create a time stamp request for design1.txt with SHA-1
+To create a timestamp request for design1.txt with SHA-1
 without nonce and policy and no certificate is required in the response:
 
   openssl ts -query -data design1.txt -no_nonce \
         -out design1.tsq
 
-To create a similar time stamp request with specifying the message imprint
+To create a similar timestamp request with specifying the message imprint
 explicitly:
 
   openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
@@ -546,7 +546,7 @@ To print the content of the previous request in human readable format:
 
   openssl ts -query -in design1.tsq -text
 
-To create a time stamp request which includes the MD-5 digest
+To create a timestamp request which includes the MD-5 digest
 of design2.txt, requests the signer certificate and nonce,
 specifies a policy id (assuming the tsa_policy1 name is defined in the
 OID section of the config file):
@@ -568,7 +568,7 @@ below assume that cacert.pem contains the certificate of the CA,
 tsacert.pem is the signing certificate issued by cacert.pem and
 tsakey.pem is the private key of the TSA.
 
-To create a time stamp response for a request:
+To create a timestamp response for a request:
 
   openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem \
         -signer tsacert.pem -out design1.tsr
@@ -577,44 +577,44 @@ If you want to use the settings in the config file you could just write:
 
   openssl ts -reply -queryfile design1.tsq -out design1.tsr
 
-To print a time stamp reply to stdout in human readable format:
+To print a timestamp reply to stdout in human readable format:
 
   openssl ts -reply -in design1.tsr -text
 
-To create a time stamp token instead of time stamp response:
+To create a timestamp token instead of timestamp response:
 
   openssl ts -reply -queryfile design1.tsq -out design1_token.der -token_out
 
-To print a time stamp token to stdout in human readable format:
+To print a timestamp token to stdout in human readable format:
 
   openssl ts -reply -in design1_token.der -token_in -text -token_out
 
-To extract the time stamp token from a response:
+To extract the timestamp token from a response:
 
   openssl ts -reply -in design1.tsr -out design1_token.der -token_out
 
-To add 'granted' status info to a time stamp token thereby creating a
+To add 'granted' status info to a timestamp token thereby creating a
 valid response:
 
   openssl ts -reply -in design1_token.der -token_in -out design1.tsr
 
 =head2 Time Stamp Verification
 
-To verify a time stamp reply against a request:
+To verify a timestamp reply against a request:
 
   openssl ts -verify -queryfile design1.tsq -in design1.tsr \
         -CAfile cacert.pem -untrusted tsacert.pem
 
-To verify a time stamp reply that includes the certificate chain:
+To verify a timestamp reply that includes the certificate chain:
 
   openssl ts -verify -queryfile design2.tsq -in design2.tsr \
         -CAfile cacert.pem
 
-To verify a time stamp token against the original data file:
+To verify a timestamp token against the original data file:
   openssl ts -verify -data design2.txt -in design2.tsr \
         -CAfile cacert.pem
 
-To verify a time stamp token against a message imprint:
+To verify a timestamp token against a message imprint:
   openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
          -in design2.tsr -CAfile cacert.pem
 
@@ -628,7 +628,7 @@ You could also look at the 'test' directory for more examples.
 
 =item *
 
-No support for time stamps over SMTP, though it is quite easy
+No support for timestamps over SMTP, though it is quite easy
 to implement an automatic e-mail based TSA with L<procmail(1)>
 and L<perl(1)>. HTTP server support is provided in the form of
 a separate apache module. HTTP client support is provided by
@@ -638,7 +638,7 @@ L<tsget(1)>. Pure TCP/IP protocol is not supported.
 
 The file containing the last serial number of the TSA is not
 locked when being read or written. This is a problem if more than one
-instance of L<openssl(1)> is trying to create a time stamp
+instance of L<openssl(1)> is trying to create a timestamp
 response at the same time. This is not an issue when using the apache
 server module, it does proper locking.
 
diff --git a/doc/man1/tsget.pod b/doc/man1/tsget.pod
index 43bf2c7e35..9f58201fd5 100644
--- a/doc/man1/tsget.pod
+++ b/doc/man1/tsget.pod
@@ -24,15 +24,15 @@ B<-h> server_url
 
 =head1 DESCRIPTION
 
-The B<tsget> command can be used for sending a time stamp request, as
-specified in B<RFC 3161>, to a time stamp server over HTTP or HTTPS and storing
-the time stamp response in a file. This tool cannot be used for creating the
+The B<tsget> command can be used for sending a timestamp request, as
+specified in B<RFC 3161>, to a timestamp server over HTTP or HTTPS and storing
+the timestamp response in a file. This tool cannot be used for creating the
 requests and verifying responses, you can use the OpenSSL B<ts(1)> command to
 do that. B<tsget> can send several requests to the server without closing
 the TCP connection if more than one requests are specified on the command
 line.
 
-The tool sends the following HTTP request for each time stamp request:
+The tool sends the following HTTP request for each timestamp request:
 
         POST url HTTP/1.1
         User-Agent: OpenTSA tsget.pl/<version>
@@ -53,7 +53,7 @@ written to a file without any interpretation.
 
 =item B<-h> server_url
 
-The URL of the HTTP/HTTPS server listening for time stamp requests.
+The URL of the HTTP/HTTPS server listening for timestamp requests.
 
 =item B<-e> extension
 
@@ -64,8 +64,8 @@ the input files. Default extension is '.tsr'. (Optional)
 =item B<-o> output
 
 This option can be specified only when just one request is sent to the
-server. The time stamp response will be written to the given output file. '-'
-means standard output. In case of multiple time stamp requests or the absence
+server. The timestamp response will be written to the given output file. '-'
+means standard output. In case of multiple timestamp requests or the absence
 of this argument the names of the output files will be derived from the names
 of the input files and the default or specified extension argument. (Optional)
 
@@ -124,7 +124,7 @@ The name of an EGD socket to get random data from. (Optional)
 
 =item [request]...
 
-List of files containing B<RFC 3161> DER-encoded time stamp requests. If no
+List of files containing B<RFC 3161> DER-encoded timestamp requests. If no
 requests are specified only one request will be sent to the server and it will be
 read from the standard input. (Optional)
 
@@ -139,35 +139,35 @@ arguments.
 =head1 EXAMPLES
 
 The examples below presume that B<file1.tsq> and B<file2.tsq> contain valid
-time stamp requests, tsa.opentsa.org listens at port 8080 for HTTP requests
+timestamp requests, tsa.opentsa.org listens at port 8080 for HTTP requests
 and at port 8443 for HTTPS requests, the TSA service is available at the /tsa
 absolute path.
 
-Get a time stamp response for file1.tsq over HTTP, output is written to
+Get a timestamp response for file1.tsq over HTTP, output is written to
 file1.tsr:
 
   tsget -h http://tsa.opentsa.org:8080/tsa file1.tsq
 
-Get a time stamp response for file1.tsq and file2.tsq over HTTP showing
+Get a timestamp response for file1.tsq and file2.tsq over HTTP showing
 progress, output is written to file1.reply and file2.reply respectively:
 
   tsget -h http://tsa.opentsa.org:8080/tsa -v -e .reply \
         file1.tsq file2.tsq
 
-Create a time stamp request, write it to file3.tsq, send it to the server and
+Create a timestamp request, write it to file3.tsq, send it to the server and
 write the response to file3.tsr:
 
   openssl ts -query -data file3.txt -cert | tee file3.tsq \
         | tsget -h http://tsa.opentsa.org:8080/tsa \
         -o file3.tsr
 
-Get a time stamp response for file1.tsq over HTTPS without client
+Get a timestamp response for file1.tsq over HTTPS without client
 authentication:
 
   tsget -h https://tsa.opentsa.org:8443/tsa \
         -C cacerts.pem file1.tsq
 
-Get a time stamp response for file1.tsq over HTTPS with certificate-based
+Get a timestamp response for file1.tsq over HTTPS with certificate-based
 client authentication (it will ask for the passphrase if client_key.pem is
 protected):
 
diff --git a/doc/man1/verify.pod b/doc/man1/verify.pod
index 18e803c8d6..0a49d790c0 100644
--- a/doc/man1/verify.pod
+++ b/doc/man1/verify.pod
@@ -336,7 +336,7 @@ in PEM format.
 =head1 VERIFY OPERATION
 
 The B<verify> program uses the same functions as the internal SSL and S/MIME
-verification, therefore this description applies to these verify operations
+verification, therefore, this description applies to these verify operations
 too.
 
 There is one crucial difference between the verify operations performed
diff --git a/doc/man1/x509.pod b/doc/man1/x509.pod
index 65cec9dbda..98d285e414 100644
--- a/doc/man1/x509.pod
+++ b/doc/man1/x509.pod
@@ -255,7 +255,7 @@ Prints out the start and expiry dates of a certificate.
 =item B<-checkend arg>
 
 Checks if the certificate expires within the next B<arg> seconds and exits
-non-zero if yes it will expire or zero if not.
+nonzero if yes it will expire or zero if not.
 
 =item B<-fingerprint>