=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>
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);
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
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
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
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
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
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
testapp = test_sect
[test_sect]
- # list of confuration modules
+ # list of configuration modules
+
ssl_conf = ssl_sect
[ssl_sect]
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
=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.
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
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
=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
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
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
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
=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>
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>,
=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
projects / oweals / openssl.git / commitdiff