16 files changed, 212 insertions, 78 deletions
diff --git a/doc/man3/ADMISSIONS.pod b/doc/man3/ADMISSIONS.pod
index f86aac922aa0..b6335cb73550 100644
--- a/doc/man3/ADMISSIONS.pod
+++ b/doc/man3/ADMISSIONS.pod
@@ -98,7 +98,7 @@ PROFESSION_INFO_set0_registrationNumber
 The B<PROFESSION_INFOS>, B<ADMISSION_SYNTAX>, B<ADMISSIONS>, and
 B<PROFESSION_INFO> types are opaque structures representing the
 analogous types defined in the Common PKI Specification published
-by L<https://www.t7ev.org>.
+by L<T7 & TELETRUST|https://www.bundesnetzagentur.de/EVD/DE/SharedDocuments/Downloads/Anbieter_Infothek/Common_PKI_v2.0_02.pdf?__blob=publicationFile&v=1>.
 Knowledge of those structures and their semantics is assumed.
 
 The conventional routines to convert between DER and the local format
@@ -169,7 +169,7 @@ L<d2i_X509(3)>,
 
 =head1 COPYRIGHT
 
-Copyright 2017-2018 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2017-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/BIO_get_data.pod b/doc/man3/BIO_get_data.pod
index aeb6b1c7e9ba..b2debd2bc504 100644
--- a/doc/man3/BIO_get_data.pod
+++ b/doc/man3/BIO_get_data.pod
@@ -18,7 +18,7 @@ BIO_get_shutdown - functions for managing BIO state information
 
 =head1 DESCRIPTION
 
-These functions are mainly useful when implementing a custom BIO.
+These functions can be used when implementing a custom BIO.
 
 The BIO_set_data() function associates the custom data pointed to by B<ptr> with
 the BIO. This data can subsequently be retrieved via a call to BIO_get_data().
@@ -36,6 +36,13 @@ The BIO_set_shutdown() and BIO_get_shutdown() functions set and get the state of
 this BIO's shutdown (i.e. BIO_CLOSE) flag. If set then the underlying resource
 is also closed when the BIO is freed.
 
+=head1 WARNINGS
+
+Do not use BIO_set_data(), BIO_get_data(), BIO_set_init(), BIO_get_init(), outside
+the implementation of a custom BIO.
+Calling BIO_set_data() on an existing BIO implementation with data that it does
+not expect will lead to unexpected results.
+
 =head1 RETURN VALUES
 
 BIO_get_data() returns a pointer to the implementation specific custom data
@@ -55,7 +62,7 @@ The functions described here were added in OpenSSL 1.1.0.
 
 =head1 COPYRIGHT
 
-Copyright 2016 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2016-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/BIO_push.pod b/doc/man3/BIO_push.pod
index 84ce3f042d1e..739c2f1b855d 100644
--- a/doc/man3/BIO_push.pod
+++ b/doc/man3/BIO_push.pod
@@ -20,7 +20,7 @@ Otherwise it prepends I<b>, which may be a single BIO or a chain of BIOs,
 to I<next> (unless I<next> is NULL).
 It then makes a control call on I<b> and returns I<b>.
 
-BIO_pop() removes the BIO I<b> from any chain is is part of.
+BIO_pop() removes the BIO I<b> from any chain it is part of.
 If I<b> is NULL the function does nothing and returns NULL.
 Otherwise it makes a control call on I<b> and
 returns the next BIO in the chain, or NULL if there is no next BIO.
@@ -88,7 +88,7 @@ The BIO_set_next() function was added in OpenSSL 1.1.0.
 
 =head1 COPYRIGHT
 
-Copyright 2000-2021 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2000-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/BIO_read.pod b/doc/man3/BIO_read.pod
index f337aab353bb..e2feb443f598 100644
--- a/doc/man3/BIO_read.pod
+++ b/doc/man3/BIO_read.pod
@@ -52,7 +52,9 @@ For implementing this, unfortunately the data needs to be read byte-by-byte.
 
 BIO_write() attempts to write I<len> bytes from I<buf> to BIO I<b>.
 
-BIO_puts() attempts to write a NUL-terminated string I<buf> to BIO I<b>.
+BIO_puts() attempts to write a NUL-terminated string I<buf> to BIO I<b>,
+without the terminating NUL byte and without appending '\n'
+(so, similar to fputs(3), and not puts(3)).
 
 =head1 RETURN VALUES
 
@@ -119,7 +121,7 @@ I<written> parameter of the function can be NULL since OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2000-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/EVP_EncryptInit.pod b/doc/man3/EVP_EncryptInit.pod
index f6b29d9daa9b..2af4ebec91f9 100644
--- a/doc/man3/EVP_EncryptInit.pod
+++ b/doc/man3/EVP_EncryptInit.pod
@@ -1453,6 +1453,9 @@ for failure.
 EVP_CIPHER_names_do_all() returns 1 if the callback was called for all names.
 A return value of 0 means that the callback was not called for any names.
 
+EVP_CIPHER_get_params(), EVP_CIPHER_CTX_get_params() and
+EVP_CIPHER_CTX_set_params() return 1 for success and 0 for failure.
+
 =head1 CIPHER LISTING
 
 All algorithms have a fixed key length unless otherwise stated.
@@ -1477,7 +1480,12 @@ depending on the mode specified.
 To specify additional authenticated data (AAD), a call to EVP_CipherUpdate(),
 EVP_EncryptUpdate() or EVP_DecryptUpdate() should be made with the output
 parameter I<out> set to NULL. In this case, on success, the parameter
-I<outl> is set to the number of bytes authenticated.
+I<outl> is set to the number of AAD bytes processed in that call
+(that is, the value of I<inl>), and does not include any plaintext
+or ciphertext bytes processed by other calls.
+
+If no AAD is used, this call can be omitted. See the mode-specific notes
+below for any exceptions.
 
 When decrypting, the return value of EVP_DecryptFinal() or EVP_CipherFinal()
 indicates whether the operation was successful. If it does not indicate success,
diff --git a/doc/man3/OPENSSL_malloc.pod b/doc/man3/OPENSSL_malloc.pod
index bdbf596ec3a5..38f8509f9b17 100644
--- a/doc/man3/OPENSSL_malloc.pod
+++ b/doc/man3/OPENSSL_malloc.pod
@@ -117,8 +117,8 @@ the returned pointer.
 OPENSSL_clear_realloc() and OPENSSL_clear_free() should be used
 when the buffer at B<addr> holds sensitive information.
 The old buffer is filled with zero's by calling OPENSSL_cleanse()
-before ultimately calling OPENSSL_free(). If the argument to OPENSSL_free() is
-NULL, nothing is done.
+before ultimately calling OPENSSL_free(). If the argument to
+OPENSSL_clear_free() is NULL, nothing is done.
 
 OPENSSL_cleanse() fills B<ptr> of size B<len> with a string of 0's.
 It is useful in cases when it is needed to ensure that memory (that contains
@@ -258,7 +258,7 @@ added in OpenSSL 3.4.
 
 =head1 COPYRIGHT
 
-Copyright 2016-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2016-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/OSSL_CMP_CTX_new.pod b/doc/man3/OSSL_CMP_CTX_new.pod
index a966d9b17c9c..86239ee57205 100644
--- a/doc/man3/OSSL_CMP_CTX_new.pod
+++ b/doc/man3/OSSL_CMP_CTX_new.pod
@@ -356,6 +356,12 @@ Taking it over as a trust anchor implements trust-on-first-use (TOFU).
 Do not cache certificates received in the extraCerts CMP message field.
 Otherwise they are stored to potentially help validate further messages.
 
+In any case, after successfully validating an incoming message, its protection
+certificate (if any) is cached for reuse with validation of subsequent messages.
+This is done not only for efficiency but also
+to eliminate the need for the sender to include its certificate and related chain
+in the extraCerts field of subsequent messages of the same transaction.
+
 =back
 
 OSSL_CMP_CTX_get_option() reads the current value of the given option
@@ -877,14 +883,15 @@ OSSL_CMP_CTX_set1_serialNumber(),
 OSSL_CMP_CTX_get0_libctx(), OSSL_CMP_CTX_get0_propq(), and
 OSSL_CMP_CTX_get0_validatedSrvCert() were added in OpenSSL 3.2.
 
-OSSL_CMP_CTX_get0_geninfo_ITAVs() was added in OpenSSL 3.3.
+OSSL_CMP_CTX_get0_geninfo_ITAVs() and
+the B<OSSL_CMP_OPT_NO_CACHE_EXTRACERTS> option were added in OpenSSL 3.3.
 
 Support for central key generation, requested via B<OSSL_CRMF_POPO_NONE>,
 was added in OpenSSL 3.5.
 
 =head1 COPYRIGHT
 
-Copyright 2007-2025 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2007-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/OSSL_HPKE_CTX_new.pod b/doc/man3/OSSL_HPKE_CTX_new.pod
index 89a6fcafe133..a7fd32122f32 100644
--- a/doc/man3/OSSL_HPKE_CTX_new.pod
+++ b/doc/man3/OSSL_HPKE_CTX_new.pod
@@ -451,12 +451,12 @@ OSSL_HPKE_get_ciphertext_size() and OSSL_HPKE_get_public_encap_size().
 
 OSSL_HPKE_str2suite() maps input I<str> strings to an B<OSSL_HPKE_SUITE> object.
 The input I<str> should be a comma-separated string with a KEM,
-KDF and AEAD name in that order, for example "x25519,hkdf-sha256,aes128gcm".
+KDF and AEAD name in that order, for example "x25519,hkdf-sha256,aes-128-gcm".
 This can be used by command line tools that accept string form names for HPKE
 codepoints. Valid (case-insensitive) names are:
 "p-256", "p-384", "p-521", "x25519" and "x448" for KEM,
 "hkdf-sha256", "hkdf-sha384" and "hkdf-sha512" for KDF, and
-"aes-gcm-128", "aes-gcm-256", "chacha20-poly1305" and "exporter" for AEAD.
+"aes-128-gcm", "aes-256-gcm", "chacha20-poly1305" and "exporter" for AEAD.
 String variants of the numbers listed in L</OSSL_HPKE_SUITE Identifiers>
 can also be used.
 
@@ -566,7 +566,7 @@ This functionality described here was added in OpenSSL 3.2.
 
 =head1 COPYRIGHT
 
-Copyright 2022-2025 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2022-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/PKCS5_PBE_keyivgen.pod b/doc/man3/PKCS5_PBE_keyivgen.pod
index f697628db13b..2b925a09e17a 100644
--- a/doc/man3/PKCS5_PBE_keyivgen.pod
+++ b/doc/man3/PKCS5_PBE_keyivgen.pod
@@ -110,6 +110,13 @@ I<iter> less than 1 is treated as a single iteration.
 
 I<digest> is the message digest function used in the derivation.
 
+I<aiv> is the initialization vector (IV) to use for the encryption algorithm.
+If I<aiv> is NULL, then a random IV will be generated.
+
+I<prf_nid> is the numeric identifier (NID) for the pseudo-random function to
+use with PBKDF2. If I<prf_nid> is not specified (for example, I<prf_nid> is set to 0),
+a default PRF is used, which is currently set to SHA-256 (NID_hmacWithSHA256).
+
 Functions ending in _ex() take optional parameters I<libctx> and I<propq> which
 are used to select appropriate algorithm implementations.
 
@@ -118,7 +125,9 @@ are used to select appropriate algorithm implementations.
 PKCS5_pbe_set(), PKCS5_pbe_set_ex(), PKCS5_pbe2_set(), PKCS5_pbe2_set_iv(),
 PKCS5_pbe2_set_iv_ex() and PKCS5_pbe2_set_scrypt() generate an B<X509_ALGOR>
 object which represents an AlgorithmIdentifier containing the algorithm OID and
-associated parameters for the PBE algorithm.
+associated parameters for the PBE algorithm. These functions encode the
+key derivation parameters (such as salt and iteration count) and the
+encryption parameters (such as the IV) into the ASN.1 structure.
 
 PKCS5_pbkdf2_set() and PKCS5_pbkdf2_set_ex() generate an B<X509_ALGOR>
 object which represents an AlgorithmIdentifier containing the algorithm OID and
@@ -177,7 +186,7 @@ This is required for PBKDF2 FIPS compliance.
 
 =head1 COPYRIGHT
 
-Copyright 2021-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2021-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/RSA_set_method.pod b/doc/man3/RSA_set_method.pod
index 21cfeed27b46..490932dc854b 100644
--- a/doc/man3/RSA_set_method.pod
+++ b/doc/man3/RSA_set_method.pod
@@ -148,13 +148,7 @@ and RSA_get_method() return pointers to the respective RSA_METHODs.
 
 RSA_set_default_method() returns no value.
 
-RSA_set_method() returns a pointer to the old RSA_METHOD implementation
-that was replaced. However, this return value should probably be ignored
-because if it was supplied by an ENGINE, the pointer could be invalidated
-at any time if the ENGINE is unloaded (in fact it could be unloaded as a
-result of the RSA_set_method() function releasing its handle to the
-ENGINE). For this reason, the return type may be replaced with a B<void>
-declaration in a future release.
+RSA_set_method() returns 1 for success. It always succeeds.
 
 RSA_new_method() returns NULL and sets an error code that can be obtained
 by L<ERR_get_error(3)> if the allocation fails. Otherwise
@@ -185,7 +179,7 @@ was replaced to always return NULL in OpenSSL 1.1.1.
 
 =head1 COPYRIGHT
 
-Copyright 2000-2020 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2000-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_CONF_cmd.pod b/doc/man3/SSL_CONF_cmd.pod
index 3e2de6e66be7..e78a2231dae3 100644
--- a/doc/man3/SSL_CONF_cmd.pod
+++ b/doc/man3/SSL_CONF_cmd.pod
@@ -176,16 +176,14 @@ respectively:
     $ openssl list -tls1_2 -tls-groups
     $ openssl list -tls1_3 -tls-groups
 
-The recommended groups (in order of decreasing performance) for TLS 1.3 are presently:
+The recommended groups for TLS 1.3 are presently documented in the default
+TLS group list in the OpenSSL code base. Starting with OpenSSL 3.5, the
+hybrid algorithm B<X25519MLKEM768> is first in this default list.
+It mitigates against threats from future quantum computers while
+still providing state-of-the-art classical key exchange protection.
 
-B<x25519>,
-B<secp256r1>,
-B<x448>,
-and
-B<secp384r1>.
-
-The stronger security margins of the last two, come at a significant
-performance penalty.
+Further details regarding post-quantum algorithm considerations are documented
+in the HISTORY section below.
 
 An enriched alternative syntax, that enables clients to send multiple keyshares
 and allows servers to prioritise some groups over others, is described in
@@ -884,7 +882,7 @@ As of OpenSSL 3.5 key exchange group names are case-insensitive.
 
 =head1 COPYRIGHT
 
-Copyright 2012-2025 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2012-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_CTX_set1_curves.pod b/doc/man3/SSL_CTX_set1_curves.pod
index 017eefd3176a..6fedad01b4d0 100755
--- a/doc/man3/SSL_CTX_set1_curves.pod
+++ b/doc/man3/SSL_CTX_set1_curves.pod
@@ -40,13 +40,13 @@ SSL_get1_curves, SSL_get_shared_curve, SSL_CTX_get0_implemented_groups
 
 For all of the functions below that set the supported groups there must be at
 least one group in the list. A number of these functions identify groups via a
-unique integer NID value. However, support for some groups may be added by
-external providers. In this case there will be no NID assigned for the group.
+unique integer B<NID> value. However, support for some groups may be added by
+external providers. In this case there will be no B<NID> assigned for the group.
 When setting such groups applications should use the "list" form of these
 functions (i.e. SSL_CTX_set1_groups_list() and SSL_set1_groups_list()).
 
 SSL_CTX_set1_groups() sets the supported groups for B<ctx> to B<glistlen>
-groups in the array B<glist>. The array consist of all NIDs of supported groups.
+groups in the array B<glist>. The array consist of all B<NIDs> of supported groups.
 The supported groups for B<TLSv1.3> include:
 B<NID_X9_62_prime256v1>,
 B<NID_secp384r1>,
@@ -73,20 +73,27 @@ B<SSL_OP_CIPHER_SERVER_PREFERENCE> is set, the order of the elements in the
 array determines the selected group. Otherwise, the order is ignored and the
 client's order determines the selection.
 
-For a TLS 1.3 server, the groups determine the selected group, but
-selection is more complex. A TLS 1.3 client sends both a group list as well as a
-predicted subset of groups. Choosing a group outside the predicted subset incurs
-an extra roundtrip. However, in some situations, the most preferred group may
-not be predicted. OpenSSL considers all supported groups in I<clist> to be comparable
-in security and prioritizes avoiding roundtrips above either client or server
-preference order. If an application uses an external provider to extend OpenSSL
-with, e.g., a post-quantum algorithm, this behavior may allow a network attacker
-to downgrade connections to a weaker algorithm. It is therefore recommended
-to use SSL_CTX_set1_groups_list() with the ability to specify group tuples.
+For a TLS 1.3 server, the groups determine the selected group, but selection is
+more complex.
+A TLS 1.3 client sends both a group list and predicted keyshares for a subset
+of groups.
+A server choosing a group outside the client's predicted subset incurs an extra
+roundtrip.
+However, in some situations, the most preferred group may not be predicted.
+
+When groups are specified via SSL_CTX_set1_groups() as a list of B<NID>
+values, OpenSSL considers all supported groups in I<clist> to be comparable in
+security and prioritises avoiding roundtrips above either client or server
+preference order.
+If an application uses an external provider to extend OpenSSL with, e.g., a
+post-quantum algorithm, this behavior may allow a network attacker to downgrade
+connections to a weaker algorithm.
+It is therefore recommended to use SSL_CTX_set1_groups_list() instead, making
+it possible to specify group tuples as described below.
 
 SSL_CTX_set1_groups_list() sets the supported groups for B<ctx> to
 string I<list>. In contrast to SSL_CTX_set1_groups(), the names of the
-groups, rather than their NIDs, are used.
+groups, rather than their B<NIDs>, are used.
 
 The commands below list the available groups for TLS 1.2 and TLS 1.3,
 respectively:
@@ -102,30 +109,72 @@ The preferred group names are those defined by
 L<IANA|https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8>.
 
 The I<list> can be used to define several group tuples of comparable security
-levels, and can specify which key shares should be sent by a client.
-The specified list elements can optionally be ignored, if not implemented
+levels, and can specify which predicted key shares should be sent by a client.
+Group tuples are used by OpenSSL TLS servers to decide whether to request a
+stronger keyshare than those predicted by sending a Hello Retry Request
+(B<HRR>) even if some of the predicted groups are supported.
+OpenSSL clients ignore tuple boundaries, and pay attenion only to the overall
+order of I<list> elements and which groups are selected as predicted keyshares
+as described below.
+
+The specified list elements can optionally be ignored if not implemented
 (listing unknown groups otherwise results in error).
-It is also possible to specify the built-in default set of groups, and to explicitly
-remove a group from that list.
+It is also possible to specify the built-in default set of groups, and to
+explicitly remove a group from that list.
+
+In its simplest legacy form, the string I<list> is just a colon separated list
+of group names, for example "P-521:P-384:P-256:X25519:ffdhe2048".
+The first group listed will in this case be used as the sole predicted
+B<key_share> sent by a client in a TLSv1.3 B<ClientHello>.
+The list should be in order of preference with the most preferred group first.
+
+A more expressive syntax supports definition of group tuples of comparable
+security by separating them from each other with C</> characters.
+
+The predicted keyshares to be sent by clients can be explicitly specified by
+adding a C<*> prefix to the associated group name.
+These C<*> prefixes are ignored by servers.
+
+If a group name is prefixed with the C<?> character, it will be ignored if an
+implementation is missing.
+Otherwise, listing an unknown group name will cause a failure to parse the
+I<list>.
+Note that whether a group is known or not may depend on the OpenSSL version,
+how OpenSSL was compiled and/or which providers are loaded.
+Make sure you have the correct spelling of the group name and when in doubt
+prefix it with a C<?> to handle configurations in which it might nevertheless
+be unknown.
+
+If a group name is prefixed with the C<-> character, it will be removed from
+the list of groups specified up to that point.
+It can be added again if specified later.
+Removal of groups that have not been included earlier in the list is silently
+ignored.
 
-In its simplest form, the string I<list> is just a colon separated list
-of group names, for example "P-521:P-384:P-256:X25519:ffdhe2048". The first
-group listed will also be used for the B<key_share> sent by a client in a
-TLSv1.3 B<ClientHello>. For servers note the discussion above. The list should
-be in order of preference with the most preferred group first.
+The pseudo group name C<DEFAULT> can be used to select the OpenSSL built-in
+default list of groups.
+Prepending one or more groups to C<DEFAULT> using only C<:> separators prepends those
+groups to the built-in default list's first tuple.
+Additional tuples can be prepended by use of the C</> separator.
+Appending a set of groups to C<DEFAULT> using only C<:> separators appends those
+groups to the built-in default list's last tuple.
+Additional tuples can be appended by use of the C</> separator.
 
-Group tuples of comparable security are defined by separating them from each
-other by a tuple separator C</>. Keyshares to be sent by a client are specified
-by prepending a C<*> to the group name, while any C<*> will be ignored by a
-server. The following string I<list> for example defines three tuples when
-used on the server-side, and triggers the generation of three key shares
-when used on the client-side: P-521:*P-256/*P-384/*X25519:P-384:ffdhe2048.
+The B<DEFAULT> list selects B<X25519MLKEM768> as one of the predicted keyshares.
+In rare cases this can lead to failures or timeouts because the resulting
+larger TLS Client Hello message may no longer fit in a single TCP segment and
+firewall software may erroneously disrupt the TLS handshake.
+If this is an issue or concern, prepending C<?X25519MLKEM768:> without a C<*>
+prefix leads to its occurrence in the default list to be ignored as a duplicate,
+and along with that also the keyshare prediction.
+The group will then only be selected by servers that specifically expect it,
+after a Hello Retry Request (HRR).
+Servers that specifically prefer B<X25519MLKEM768>, are much less likely to be
+found behind problematic firewalls.
 
-If a group name is preceded with the C<?> character, it will be ignored if an
-implementation is missing. If a group name is preceded with the C<-> character, it
-will be removed from the list of groups if present (including not sending a
-key share for this group), ignored otherwise. The pseudo group name
-C<DEFAULT> can be used to select the OpenSSL built-in default list of groups.
+The following string I<list> for example defines three tuples when used on the
+server-side, and triggers the generation of three key shares when used on the
+client-side: P-521:*P-256/*P-384/*X25519:P-384:ffdhe2048.
 
 For a TLS 1.3 client, all the groups in the string I<list> are added to the
 supported groups extension of a C<ClientHello>, in the order in which they are listed,
@@ -351,7 +400,7 @@ supported groups as comparable in security.
 
 =head1 COPYRIGHT
 
-Copyright 2013-2025 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2013-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_CTX_set_psk_client_callback.pod b/doc/man3/SSL_CTX_set_psk_client_callback.pod
index dd302983fdde..146e3d03a51a 100644
--- a/doc/man3/SSL_CTX_set_psk_client_callback.pod
+++ b/doc/man3/SSL_CTX_set_psk_client_callback.pod
@@ -93,6 +93,14 @@ be used as the basis for a PSK.
 Ownership of the SSL_SESSION object is passed to the OpenSSL library and so it
 should not be freed by the application.
 
+Note that as described above, the callback may be called a second time during a
+handshake. Since ownership of the SSL_SESSION is transferred to OpenSSL on each
+call, if the callback wishes to return the same SSL_SESSION pointer on a
+subsequent invocation, it must first call L<SSL_SESSION_up_ref(3)> to increment
+the reference count. Failure to do so will result in a use-after-free error.
+Alternatively, the callback may return a different SSL_SESSION object on each
+call (e.g., by calling L<SSL_SESSION_dup(3)>).
+
 It is also possible for the callback to succeed but not supply a PSK. In this
 case no PSK will be sent to the server but the handshake will continue. To do
 this the callback should return successfully and ensure that B<*sess> is
@@ -169,7 +177,7 @@ were added in OpenSSL 1.1.1.
 
 =head1 COPYRIGHT
 
-Copyright 2006-2020 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2006-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_get_ciphers.pod b/doc/man3/SSL_get_ciphers.pod
index add0fc4cd045..8f32cc008e4b 100644
--- a/doc/man3/SSL_get_ciphers.pod
+++ b/doc/man3/SSL_get_ciphers.pod
@@ -75,6 +75,8 @@ description of SSL_get1_supported_ciphers() above). This function will return
 available shared ciphersuites whether or not they are enabled. This is a server
 side function only and must only be called after the completion of the initial
 handshake.
+The function sets an empty string when B<ssl> fails the handshake due to the
+absence of shared ciphers.
 
 =head1 NOTES
 
@@ -107,7 +109,7 @@ L<SSL_CIPHER_get_name(3)>
 
 =head1 COPYRIGHT
 
-Copyright 2000-2018 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2000-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/X509V3_EXT_print.pod b/doc/man3/X509V3_EXT_print.pod
new file mode 100644
index 000000000000..0727d35f88e5
--- /dev/null
+++ b/doc/man3/X509V3_EXT_print.pod
@@ -0,0 +1,51 @@
+=pod
+
+=head1 NAME
+
+X509V3_EXT_print, X509V3_EXT_print_fp - pretty print X509 certificate extensions
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509v3.h>
+
+ int X509V3_EXT_print(BIO *out, X509_EXTENSION *ext, unsigned long flag, int indent);
+ int X509V3_EXT_print_fp(FILE *out, X509_EXTENSION *ext, int flag, int indent);
+
+=head1 DESCRIPTION
+
+X509V3_EXT_print() and X509V3_EXT_print_fp() parse and print the extension
+info from I<ext> to I<bio> or I<out> with indentation set via I<indent>.
+I<flag> determines the behaviour if an extension could not be parsed and can be
+one of:
+B<X509V3_EXT_DEFAULT> (equivalent to 0): an unknown or unparsable extension
+stops the parsing and the function returns a failure.
+B<X509V3_EXT_PARSE_UNKNOWN>: an unknown or unparsable extension is handled by
+printing it through the B<ASN1_parse_dump()> function, and the function returns
+success.
+B<X509V3_EXT_DUMP_UNKNOWN>: an unknown or unparsable extension is handled by
+printing it through the B<BIO_dump_indent()> function, and the function returns
+success,
+B<X509V3_EXT_ERROR_UNKNOWN>: an unknown or unparsable extension is handled by
+printing either "<Not Supported>" or  "<Parse Error>", and the function returns
+success.
+
+=head1 RETURN VALUES
+
+X509V3_EXT_print() and X509V3_EXT_print_fp() return 1 for success and 0 for
+failure.
+
+=head1 SEE ALSO
+
+L<BIO_dump_indent(3)>,
+L<ASN1_parse_dump(3)>,
+
+=head1 COPYRIGHT
+
+Copyright 2026 The OpenSSL Project Authors. All Rights Reserved.
+
+Licensed under the Apache License 2.0 (the "License").  You may not use
+this file except in compliance with the License.  You can obtain a copy
+in the file LICENSE in the source distribution or at
+L<https://www.openssl.org/source/license.html>.
+
+=cut
diff --git a/doc/man3/X509_NAME_print_ex.pod b/doc/man3/X509_NAME_print_ex.pod
index e43bb191f523..f86849d26e2e 100644
--- a/doc/man3/X509_NAME_print_ex.pod
+++ b/doc/man3/X509_NAME_print_ex.pod
@@ -32,9 +32,8 @@ I<size> is ignored.
 Otherwise, at most I<size> bytes will be written, including the ending '\0',
 and I<buf> is returned.
 
-X509_NAME_print() prints out I<name> to I<bp> indenting each line by I<obase>
-characters. Multiple lines are used if the output (including indent) exceeds
-80 characters.
+X509_NAME_print() prints out I<name> to I<bp> on a single line.
+The I<obase> parameter is ignored and retained only for API compatibility.
 
 =head1 NOTES
 
@@ -122,7 +121,7 @@ L<ASN1_STRING_print_ex(3)>
 
 =head1 COPYRIGHT
 
-Copyright 2002-2020 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2002-2026 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy