Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
12 files changed:
The B<engine> command is used to query the status and capabilities
of the specified B<engine>'s.
The B<engine> command is used to query the status and capabilities
of the specified B<engine>'s.
-Engines may be speicifed before and after all other command-line flags.
+Engines may be specified before and after all other command-line flags.
Only those specified are queried.
=head1 OPTIONS
Only those specified are queried.
=head1 OPTIONS
descriptors but will still populate B<*numfds>. Therefore application code is
typically expected to call this function twice: once to get the number of fds,
and then again when sufficient memory has been allocated. If only one
descriptors but will still populate B<*numfds>. Therefore application code is
typically expected to call this function twice: once to get the number of fds,
and then again when sufficient memory has been allocated. If only one
-asynchronous engine is being used then noramlly this call will only ever return
+asynchronous engine is being used then normally this call will only ever return
one fd. If multiple asynchronous engines are being used then more could be
returned.
one fd. If multiple asynchronous engines are being used then more could be
returned.
with them. Applications can wait for the file descriptor to be ready for "read"
using a system function call such as select or poll (being ready for "read"
indicates that the job should be resumed). If no file descriptor is made
with them. Applications can wait for the file descriptor to be ready for "read"
using a system function call such as select or poll (being ready for "read"
indicates that the job should be resumed). If no file descriptor is made
-available then an application will have to priodically "poll" the job by
+available then an application will have to periodically "poll" the job by
attempting to restart it to see if it is ready to continue.
An example of typical usage might be an async capable engine. User code would
attempting to restart it to see if it is ready to continue.
An example of typical usage might be an async capable engine. User code would
=head1 RETURN VALUES
BIO_lookup() returns 1 on success and 0 when an error occurred, and
=head1 RETURN VALUES
BIO_lookup() returns 1 on success and 0 when an error occurred, and
-will leave an error indicaton on the OpenSSL error stack in that case.
+will leave an error indication on the OpenSSL error stack in that case.
All other functions described here return 0 or B<NULL> when the
information they should return isn't available.
All other functions described here return 0 or B<NULL> when the
information they should return isn't available.
ENGINE_free(e);
return 0;
}
ENGINE_free(e);
return 0;
}
}
if(!ENGINE_init(e)) {
fprintf(stderr, "Failed initialisation\n");
}
if(!ENGINE_init(e)) {
fprintf(stderr, "Failed initialisation\n");
ENGINE_finish(e);
return 0;
}
ENGINE_finish(e);
return 0;
}
}
ENGINE_set_default(e, ENGINE_METHOD_ALL & ~ENGINE_METHOD_RAND);
/* Success */
}
ENGINE_set_default(e, ENGINE_METHOD_ALL & ~ENGINE_METHOD_RAND);
/* Success */
In versions of OpenSSL prior to 1.1.0 SSL_COMP_free_compression_methods() freed
the internal table of compression methods that were built internally, and
possibly augmented by adding SSL_COMP_add_compression_method(). However this is
In versions of OpenSSL prior to 1.1.0 SSL_COMP_free_compression_methods() freed
the internal table of compression methods that were built internally, and
possibly augmented by adding SSL_COMP_add_compression_method(). However this is
-now unncessary from version 1.1.0. No explicit initialisation or
+now unnecessary from version 1.1.0. No explicit initialisation or
de-initialisation is necessary. See L<OPENSSL_init_crypto(3)> and
L<OPENSSL_init_ssl(3)>. From OpenSSL 1.1.0 calling this function does nothing.
de-initialisation is necessary. See L<OPENSSL_init_crypto(3)> and
L<OPENSSL_init_ssl(3)>. From OpenSSL 1.1.0 calling this function does nothing.
SSL_CONF_cmd(ctx, "SignatureAlgorithms", "ECDSA+SHA256:RSA+SHA256:DSA+SHA256");
SSL_CONF_cmd(ctx, "SignatureAlgorithms", "ECDSA+SHA256:RSA+SHA256:DSA+SHA256");
-There are various ways to select the supported procotols.
+There are various ways to select the supported protocols.
This set the minimum protocol version to TLSv1, and so disables SSLv3.
This is the recommended way to disable protocols.
This set the minimum protocol version to TLSv1, and so disables SSLv3.
This is the recommended way to disable protocols.
-The functions set the minimum and maximum supported portocol versions
+The functions set the minimum and maximum supported protocol versions
for the B<ctx> or B<ssl>.
This works in combination with the options set via
L<SSL_CTX_set_options(3)> that also make it possible to disable
for the B<ctx> or B<ssl>.
This works in combination with the options set via
L<SSL_CTX_set_options(3)> that also make it possible to disable
a ciphersuite is negotiated that uses a pipeline capable cipher provided by an
engine.
a ciphersuite is negotiated that uses a pipeline capable cipher provided by an
engine.
-Pipelining operates slighly differently for reading encrypted data compared to
+Pipelining operates slightly differently for reading encrypted data compared to
writing encrypted data. SSL_CTX_set_split_send_fragment() and
SSL_set_split_send_fragment() define how data is split up into pipelines when
writing encrypted data. The number of pipelines used will be determined by the
writing encrypted data. SSL_CTX_set_split_send_fragment() and
SSL_set_split_send_fragment() define how data is split up into pipelines when
writing encrypted data. The number of pipelines used will be determined by the
be sorted starting with the subject's certificate (actual client or server
certificate), followed by intermediate CA certificates if applicable, and
ending at the highest level (root) CA. SSL_use_certificate_chain_file() is
be sorted starting with the subject's certificate (actual client or server
certificate), followed by intermediate CA certificates if applicable, and
ending at the highest level (root) CA. SSL_use_certificate_chain_file() is
-similar except it loads the cerificate chain into B<ssl>.
+similar except it loads the certificate chain into B<ssl>.
SSL_CTX_use_PrivateKey() adds B<pkey> as private key to B<ctx>.
SSL_CTX_use_RSAPrivateKey() adds the private key B<rsa> of type RSA
SSL_CTX_use_PrivateKey() adds B<pkey> as private key to B<ctx>.
SSL_CTX_use_RSAPrivateKey() adds the private key B<rsa> of type RSA
Despite the names of SSL_get_client_random() and SSL_get_server_random(), they
ARE NOT random number generators. Instead, they return the mostly-random values that
Despite the names of SSL_get_client_random() and SSL_get_server_random(), they
ARE NOT random number generators. Instead, they return the mostly-random values that
-were already generated and used in the TLS protoccol. Using them
+were already generated and used in the TLS protocol. Using them
in place of RAND_bytes() would be grossly foolish.
The security of your TLS session depends on keeping the master key secret:
in place of RAND_bytes() would be grossly foolish.
The security of your TLS session depends on keeping the master key secret:
rsa(1) then B<*rhash> would be 4, B<*rsign> 1, B<*phash> NID_sha256, B<*psig>
NID_rsaEncryption and B<*psighash> NID_sha256WithRSAEncryption.
rsa(1) then B<*rhash> would be 4, B<*rsign> 1, B<*phash> NID_sha256, B<*psig>
NID_rsaEncryption and B<*psighash> NID_sha256WithRSAEncryption.
-If a signature algorithm is not recognised the corresponsing NIDs
+If a signature algorithm is not recognised the corresponding NIDs
will be set to B<NID_undef>. This may be because the value is not supported
or is not an appropriate combination (for example MD5 and DSA).
will be set to B<NID_undef>. This may be because the value is not supported
or is not an appropriate combination (for example MD5 and DSA).
projects / openssl.git / commitdiff