When a server uses a HRR to negotiate the key exchange group to use, the
selected group is advertised in the HRR key share extension.
Furthermore, this group is also stored in the Cookie that is sent to the
client. When the server receives the second CH, the group used in the
key share extension MUST be the one of the HRR.
For stateless DTLS servers, the handling of this check had a bug. The
key share group of the HRR is stored in the ssl->hrr_keyshare_group
variable and is checked against the received key share of the second CH.
However, in the stateless server case, another CH message may be
received inbetween the two CH message of the desired client, potentially
overwriting the ssl->hrr_keyshare_group variable. This then causes
handshake failures when the ssl->hrr_keyshare_group variable contains
another group than the second CH message of the desired client.
To fix this, the following changes are conducted:
1. Disable the ssl->hrr_keyshare_group check for stateless DTLS 1.3
servers. As long as the server is stateless, CHs from multiple
clients may be received that individually cause HRRs with different
groups. For each of these clients, the HRR group is properly stored
in the cookie.
2. When a valid cookie is received from the client, the server becomes
stateful. In this case, we now parse the cookie for a stored HRR
group in the RestartHandshakeHashWithCookie() method. If present,
we restore the ssl->hrr_keyshare_group variable to this group to
ensure the error checks succeed.
3. Move the check of ssl->hrr_keyshare_group of the the KeyShare
extension parsing logic into the general TLS1.3 ClientHello parsing
after extension handling. This ensures that the order of the cookie
and key share extensions does not matter.
A new test is added to check for this behavior.
RSA-PSS signed certificates contain a valid RSA public key that can be
used for key transport, but wc_PKCS7_AddRecipient_KTRI and the
EnvelopedData/AuthEnvelopedData encode paths rejected them because they
only checked for RSAk. Allow RSAPSSk to fall through to the RSAk key
transport path, and always use RSAk as the KeyEncryptionAlgorithmIdentifier
since the operation is RSA encryption, not RSA-PSS signing.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
### `wolfssl/internal.h`
- **`InternalTicket` struct gains a flexible array member**: A new `peerCert[]` field (with a preceding `peerCertLen[2]`) is added to `InternalTicket`. This allows the peer's DER-encoded certificate to be stored directly inside the session ticket.
- **`ExternalTicket` struct becomes variable-length**: The `enc_ticket` field is changed from a fixed-size array to a flexible array member (`byte enc_ticket[]`). The `mac` field is removed from the struct — the MAC is now placed dynamically after the encrypted data in `enc_ticket`.
### `src/internal.c`
- The `GetRecordHeader` function now only adds `MAX_COMP_EXTRA` to the maximum allowed record size when `ssl->options.usingCompression` is true, tightening the length validation. The max fragment length extension check is now much stricter.
- **Peer certificate is serialized into the ticket**: During ticket creation, the code attempts to find the peer certificate from `ssl->peerCert` or from `ssl->session->chain` (fallback). If found and within `MAX_TICKET_PEER_CERT_SZ`, it's copied into `it->peerCert`. DTLS is explicitly excluded (peer cert length set to 0) to keep ticket size small for MTU constraints. If `HAVE_MAX_FRAGMENT` is defined and max fragment is not `MAX_RECORD_SIZE` for TLS 1.3, the cert is also skipped since `SendTls13NewSessionTicket` doesn't support fragmentation yet.
- **Peer certificate restoration from ticket**: On successful ticket decryption, if the ticket contains a peer certificate (`peerCertLen > 0`), it is decoded back into `ssl->peerCert` via `ParseCertRelative`/`CopyDecodedToX509`, and also added to `ssl->session->chain` via `AddSessionCertToChain`.
- The `CLEAR_ASN_NO_PEM_HEADER_ERROR` macro was rewritten to loop and remove all consecutive PEM no-start-line errors (not just the last one), wrapped in a `do { ... } while(0)` for safety.
- The `SendTicket` function is simplified to use `SendHandshakeMsg` to support fragmenting the larger ticket.
---
### `src/x509.c`
- `loadX509orX509REQFromPemBio` now accepts `TRUSTED_CERT_TYPE` in addition to `CERT_TYPE` and `CERTREQ_TYPE`.
- **Streaming BIO support**: When `wolfSSL_BIO_get_len()` returns ≤ 0 (e.g., pipes/FIFOs), the function no longer returns an error. Instead, it sets an initial buffer of `MAX_X509_SIZE` and dynamically grows (doubling) up to `MAX_BIO_READ_BUFFER` (`MAX_X509_SIZE * 16`) as data is read byte-by-byte.
- **Alternate footer detection**: For `TRUSTED_CERT_TYPE`, the PEM reader also checks for the regular `CERT_TYPE` footer (`-----END CERTIFICATE-----`) in addition to the trusted cert footer (`-----END TRUSTED CERTIFICATE-----`), so it can parse either format.
- Removed two lines that set `cert->srcIdx` to `SIGALGO_SEQ` offset. This makes `cert->srcIdx` reflect the end of parsed certificate data. This is used by `loadX509orX509REQFromBuffer` to detect where auxiliary trust data begins in trusted certificates.
---
### `src/ssl_sk.c`
- Added a `STACK_TYPE_X509_CRL` case to `wolfssl_sk_dup_data` that calls `wolfSSL_X509_CRL_dup` for deep-copying CRL stack elements. Previously, `STACK_TYPE_X509_CRL` fell through to the unsupported default case.
---
### `wolfssl/openssl/ssl.h`
- `sk_X509_dup` now maps to `wolfSSL_shallow_sk_dup` (was `wolfSSL_sk_dup`/deep copy). This matches OpenSSL's behavior where `sk_X509_dup` does a shallow copy.
- `sk_SSL_CIPHER_dup` similarly changed to `wolfSSL_shallow_sk_dup`.
---
### `src/ssl_api_cert.c`
- When `ssl->ourCert` is `NULL` and the SSL owns its cert, the function now checks if `ssl->ctx->ourCert` points to the same certificate (by comparing DER buffers). If so, it returns the ctx's `X509` pointer directly. This maintains pointer compatibility for applications (like nginx OCSP stapling) that use the `X509*` from `SSL_CTX_use_certificate` as a lookup key.
### `src/bio.c`
- When `wolfssl_file_len` returns `WOLFSSL_BAD_FILETYPE` (now returned for pipes/FIFOs), `wolfSSL_BIO_get_len` treats it as length 0 instead of propagating the error.
---
### `tests/test-maxfrag.conf` and `tests/test-maxfrag-dtls.conf`
- Removed `DHE-RSA-AES256-GCM-SHA384` test entries because the ClientKeyExchange doesn't fit in the selected max fragment length.
Add full RSA-PSS (RSASSA-PSS) support to PKCS#7 SignedData
encoding and verification.
This change enables SignerInfo.signatureAlgorithm to use
id-RSASSA-PSS with explicit RSASSA-PSS-params (hash, MGF1,
salt length), as required by RFC 4055 and CMS profiles.
Key changes:
- Add RSA-PSS encode and verify paths for PKCS7 SignedData
- Encode full RSASSA-PSS AlgorithmIdentifier parameters
- Decode RSA-PSS parameters from SignerInfo for verification
- Treat RSA-PSS like ECDSA (sign raw digest, not DigestInfo)
- Fix certificate signatureAlgorithm parameter length handling
- Add API test coverage for RSA-PSS SignedData
This resolves failures when using RSA-PSS signer certificates
(e.g. -173 invalid signature algorithm) and maintains backward
compatibility with RSA PKCS#1 v1.5 and ECDSA.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Eric Blankenhorn
Daniel Pouzzner
JacobBarthelmeh
Tobias Frauenschläger
Juliusz Sosinowicz
Hideki Miyazaki
Paul Adelsbach
Sameeh Jubran
Sean Parkinson
Marco Oliverio