[Bug]: Client Certificate Extensions Offered-List Inconsistency

[LiD0209]

Contact Details

lxd_dong@bupt.edu.cn

Version

V5.9.1

Description

Client Certificate Extensions Offered-List Inconsistency

Conclusion

This note concerns extensions in a client-sent TLS 1.3 Certificate message:
they must correspond to extensions previously offered by the server in
CertificateRequest.

wolfSSL parses CertificateEntry extensions, but in the current default build
there is no stable hard-check path showing that a client certificate extension
is rejected solely because it was not present in the server's earlier
CertificateRequest extension list. This should not be classified as fully
satisfied.

Standard Text

RFC 8446 Section 4.4.2, "Certificate":
https://www.rfc-editor.org/rfc/rfc8446.html#section-4.4.2

extensions:  A set of extension values for the CertificateEntry.  The
"Extension" format is defined in Section 4.2.  Valid extensions
for server certificates at present include the OCSP Status
extension [RFC6066] and the SignedCertificateTimestamp extension
[RFC6962]; future extensions may be defined for this message as
well.  Extensions in the Certificate message from the server MUST
correspond to ones from the ClientHello message.  Extensions in
the Certificate message from the client MUST correspond to
extensions in the CertificateRequest message from the server.  If
an extension applies to the entire chain, it SHOULD be included in
the first CertificateEntry.

The directly relevant sentence for this case is:

Extensions in the Certificate message from the client MUST correspond to
extensions in the CertificateRequest message from the server.

wolfSSL Source Evidence

CertificateEntry Extensions Are Parsed

In internal.c, wolfSSL extracts each
CertificateEntry extension block and passes it into TLSX_Parse():

args->exts[args->totalCerts].length = extSz;
args->exts[args->totalCerts].buffer = input + args->idx;
args->idx += extSz;
listSz -= extSz + OPAQUE16_LEN;
WOLFSSL_MSG_EX("\tParsing %d bytes of cert extensions",
    args->exts[args->totalCerts].length);
#if !defined(NO_TLS)
#if defined(HAVE_CERTIFICATE_STATUS_REQUEST)
ssl->response_idx = args->totalCerts;
#endif
ret = TLSX_Parse(ssl, args->exts[args->totalCerts].buffer,
    (word16)args->exts[args->totalCerts].length,
    certificate, NULL);
#endif /* !NO_TLS */

So the issue is not that certificate extensions are ignored entirely. The
question is whether wolfSSL enforces the offered-list correspondence required
by RFC 8446.

Generic Extension Parser

In tls.c, TLSX_Parse() treats
client_hello and certificate_request as request-like messages:

byte isRequest = (msgType == client_hello ||
                  msgType == certificate_request);

The certificate message is not included in this isRequest condition.

Message-Position Check Is Not the Same as Offered-List Check

For status_request, tls.c allows the
extension in a TLS 1.3 certificate message:

if (IsAtLeastTLSv1_3(ssl->version)) {
    if (msgType != client_hello &&
        msgType != certificate_request &&
        msgType != certificate)
        return EXT_NOT_ALLOWED;
}
ret = CSR_PARSE(ssl, input + offset, size, isRequest);

This checks whether the extension type is allowed in the message. It does not
by itself prove that the extension was offered in the previous
CertificateRequest.

The Stronger Check Is Feature-Dependent

When certificate status request support is enabled,
tls.c contains logic that can reject an
unexpected status_request:

if (!csr) /* unexpected extension */
    return TLSX_HandleUnsupportedExtension(ssl);

The rejection helper sends unsupported_extension; see
tls.c:

int TLSX_HandleUnsupportedExtension(WOLFSSL* ssl)
{
    SendAlert(ssl, alert_fatal, unsupported_extension);
    WOLFSSL_ERROR_VERBOSE(UNSUPPORTED_EXTENSION);
    return UNSUPPORTED_EXTENSION;
}

However, in the current default build this path is compiled out. The relevant
macros in tls.c reduce CSR_PARSE to a
successful no-op:

#define CSR_FREE_ALL(data, heap) WC_DO_NOTHING
#define CSR_GET_SIZE(a, b)    0
#define CSR_WRITE(a, b, c)    0
#define CSR_PARSE(a, b, c, d) 0

The default build configuration also shows that
HAVE_CERTIFICATE_STATUS_REQUEST and HAVE_OCSP are not enabled; see
options.h.

Evidence Scope

The minimal runtime probe is
test_id253_254_tlsx_parse_runtime.c.
In the current default static build, the client object initializes, while the
server object does not initialize cleanly. Therefore, this client-certificate
case is mainly based on source-path analysis, while the server-certificate case has direct runtime evidence.

Classification

The current wolfSSL behavior is closer to checking whether an extension type is
generally allowed in a certificate message, not to enforcing a hard
offered-list correspondence against the previous CertificateRequest.

Reproduction steps

No response

Relevant log output

[cpsource]

Took a crack at this. Root-cause analysis, proposed fix, a self-contained reproducer, and an automated BEFORE/AFTER verification script are all below. (Queried gh first — no existing PR addresses this. PR #10186 tightened the unknown-extension default branch but its scope deliberately excludes known-but-feature-disabled extensions, so case TLSX_STATUS_REQUEST with the no-op CSR_PARSE stub is still a free pass.)

---

The bug

In a default wolfSSL build (./configure --enable-tls13, with no
OCSP/HAVE_CERTIFICATE_STATUS_REQUEST), receiving a TLS 1.3
Certificate (or CertificateRequest) message that carries a
status_request extension does not abort the handshake. The
extension is silently consumed even though the local endpoint
never advertised it (no offered-list correspondence).

RFC 8446 §4.4.2 says: "Extensions in the Certificate message from
the client MUST correspond to extensions in the CertificateRequest
message from the server." §4.2 says the receiver MUST abort with
an unsupported_extension alert when an unsolicited extension
appears.

Direct evidence (this review's reproducer):

TLSX_Parse(certificate, status_request) ret=0
FAIL  status_request silently accepted in TLS 1.3 Certificate
      (RFC 8446 4.4.2 violated)

After the proposed fix:

TLSX_Parse(certificate, status_request) ret=-429
PASS  status_request rejected in TLS 1.3 Certificate
      (RFC 8446 4.4.2 obeyed)

Upstream status

Checked on 2026-04-27 with gh:

• Issue opened 2026-04-27 by LiD0209 (Li Xiangdong); 0 comments,
  no assignee, label bug. Reporter ran wolfSSL V5.9.1 and noted
  that their runtime probe didn't fully initialise on the server
  side, so their conclusion is grounded in source-path analysis.
• gh pr list --repo wolfSSL/wolfssl --state all --search "10319" →
  no PRs reference this issue.
• gh search issues --repo wolfSSL/wolfssl --include-prs "10319" →
  the issue plus two unrelated 2024 PRs. Two sibling issues filed
  by the same reporter the same day:
  • [Bug]: HelloRetryRequest Extension Whitelist Runtime Recheck #10320 — HelloRetryRequest Extension Whitelist (already fixed
    by PR Error out in case of unknown extensions in response message in TLS 1.3 #10186, separate review).
  • [Bug]: ServerHello Extension Whitelist Runtime Recheck #10321 — ServerHello Extension Whitelist (already fixed by
    PR Error out in case of unknown extensions in response message in TLS 1.3 #10186, separate review).
• Keyword scan of ticket_lifetime, unsupported_extension,
  CertificateEntry, status_request in PRs and issues: no
  upstream PR addresses status_request admission specifically in
  the TLS 1.3 Certificate / CertificateRequest messages. PR
  Error out in case of unknown extensions in response message in TLS 1.3 #10186 (Frauschi, merged 2026-04-13) tightened the unknown-
  extension default branch but deliberately scopes only {server_hello, hello_retry_request, encrypted_extensions, certificate} for
  unknown types — known extensions whose handlers are no-op stubs
  (CSR_PARSE) are left as-is.

Conclusion: this gap is real on master and not in flight upstream.

Root cause

TLSX_Parse() in src/tls.c dispatches by extension type.
TLSX_STATUS_REQUEST (type 5) has its own case at
src/tls.c:17534:

case TLSX_STATUS_REQUEST:
    WOLFSSL_MSG("Certificate Status Request extension received");
    ...
#ifdef WOLFSSL_TLS13
    if (IsAtLeastTLSv1_3(ssl->version)) {
        if (msgType != client_hello &&
            msgType != certificate_request &&
            msgType != certificate)
            return EXT_NOT_ALLOWED;        /* (1) message-type filter */
    }
    else
 #endif
    {
        if (msgType != client_hello &&
            msgType != server_hello)
            return EXT_NOT_ALLOWED;
    }
    ret = CSR_PARSE(ssl, input + offset, size, isRequest); /* (2) handler */
    break;

Filter (1) only rejects status_request in unrelated message
types (e.g. EncryptedExtensions). It does not enforce offered-list
correspondence — it permits the extension in certificate /
certificate_request regardless of whether the local endpoint ever
advertised it.

Handler (2), CSR_PARSE, is the live OCSP code only when CSR is
compiled in. Without HAVE_CERTIFICATE_STATUS_REQUEST it is a
literal no-op:

#define CSR_PARSE(a, b, c, d) 0   /* src/tls.c:4022 */

Returning 0 is "success" to TLSX_Parse, so the loop advances past
the extension and the handshake continues as if nothing had been
sent. PR #10186's default:-branch rejection only fires for
unknown extension types; status_request is known, so it never
reaches default:.

The same gap exists for TLSX_STATUS_REQUEST_V2 (type 17) at
src/tls.c:17557 when HAVE_CERTIFICATE_STATUS_REQUEST_V2 is
disabled — CSR2_PARSE is similarly stubbed.

Why the current design exists

The case TLSX_STATUS_REQUEST body was structured assuming that
when CSR is disabled the case is dead code — the local endpoint
neither advertises nor consumes status_request. The author did not
add a rejection arm for the case where a peer still emits the
extension. PR #10186 fixed the same shape of problem for unknown
types but did not extend the reasoning to known-but-stubbed types.

Proposed fix

Add a small #ifndef HAVE_CERTIFICATE_STATUS_REQUEST rejection arm
inside case TLSX_STATUS_REQUEST (and the analogous arm for
_V2), gated on TLS 1.3 + msgType in {certificate_request, certificate}:

#ifndef HAVE_CERTIFICATE_STATUS_REQUEST
    if (msgType == certificate_request ||
            msgType == certificate) {
        SendAlert(ssl, alert_fatal, unsupported_extension);
        WOLFSSL_ERROR_VERBOSE(UNSUPPORTED_EXTENSION);
        return UNSUPPORTED_EXTENSION;
    }
#endif

After the fix, the following invariants hold in default builds:

• status_request in TLS 1.3 Certificate from a peer is rejected
  with unsupported_extension (-429), regardless of which side is
  receiving (server reading client cert, or client reading server
  cert).
• status_request in TLS 1.3 CertificateRequest from a server
  is rejected with unsupported_extension.
• status_request in client_hello is still tolerated (a peer
  may probe; the server may simply not respond with stapled
  status, which is RFC-compliant).
• CSR-enabled builds are unaffected: the new #ifndef block is
  compiled out and the existing CSR_PARSE path takes over.

The patch is +33 lines, all additions, two parallel #ifndef
blocks (one per status-request case), no edits to existing flow.

Caveats and risks

• Scope: the patch handles only the feature-disabled form of
  the unsolicited-extension problem. The broader RFC 8446 §4.4.2
  rule — that even in CSR-enabled builds an extension in the
  client's Certificate MUST correspond to one offered in the
  server's CertificateRequest — would require additional state
  tracking (which extensions did the server include in its CR?)
  and is left as future work.
• CSR-enabled builds: zero behavioural change. The new code
  is gated on #ifndef HAVE_CERTIFICATE_STATUS_REQUEST (and the
  _V2 analogue), so OCSP-stapling builds continue to use
  CSR_PARSE/CSR2_PARSE as today.
• Practical impact: in the default build the silently-accepted
  status_request data is consumed but never dereferenced (the
  handler is a no-op), so this is an RFC-compliance gap rather
  than a memory or auth-bypass defect. The fix tightens conformance
  and surfaces malformed peer behaviour earlier.
• Build-config guards: the fix only touches the
  WOLFSSL_TLS13 && !HAVE_CERTIFICATE_STATUS_REQUEST arm, which
  is the configuration the reporter tested.
• Async / threading: case TLSX_STATUS_REQUEST runs in the
  TLSX_Parse path on the SSL state machine, which is single-
  threaded per-WOLFSSL already, and there is no async crypto on
  this branch.

Tests to add

1. Included in this review — issue-10319-test.c directly
   invokes TLSX_Parse() (statically linked against
   libwolfssl.a so the WOLFSSL_LOCAL symbol resolves) with a
   4-byte extension list {0x00 0x05 0x00 0x00} and msgType = certificate (11). Asserts ret == UNSUPPORTED_EXTENSION (-429) after the fix; would fail on master.
2. Suggested follow-up — a tests/api/test_tls13.c regression
   in the spirit of test_tls13_unknown_ext_rejected (added by PR
   Error out in case of unknown extensions in response message in TLS 1.3 #10186 for the unknown-extension case): drive a client/server
   handshake via test_memio with a hand-crafted Certificate
   carrying status_request, assert
   wolfSSL_get_error() == UNSUPPORTED_EXTENSION and that the
   alert record reaches the wire.
3. Suggested follow-up — analogous status_request_v2 case.

Files touched by the proposed patch

• src/tls.c — case TLSX_STATUS_REQUEST (line 17534) and
  case TLSX_STATUS_REQUEST_V2 (line 17557): each gets a small
  #ifndef HAVE_CERTIFICATE_STATUS_REQUEST{,_V2} rejection arm
  for msgType in {certificate_request, certificate} in TLS 1.3.

See issue-10319.patch alongside this file.

Appendix — end-to-end verification

issue-10319-test.c:

1. Calls wolfSSL_Init().
2. Allocates a WOLFSSL_CTX* with
   wolfTLSv1_3_client_method() and a WOLFSSL* from it. The new
   SSL has ssl->version set to TLS 1.3 (so
   IsAtLeastTLSv1_3(ssl->version) is true at the case site).
3. Constructs the smallest possible TLS extension list:

   ext_blob = { 0x00, 0x05, 0x00, 0x00 }
              ^^type^^^^^len^^
              status_request   length 0
   

4. Forward-declares TLSX_Parse() (the symbol is WOLFSSL_LOCAL,
   reachable through static linking against libwolfssl.a).
5. Calls TLSX_Parse(ssl, ext_blob, 4, /*certificate=*/11, NULL).
6. Inspects the return:
   • 0 (success) → BEFORE: silent accept → FAIL.
   • -429 (UNSUPPORTED_EXTENSION) → AFTER: rejected → PASS.
   • any other value → unexpected.

Observed results

Scenario	BEFORE (master)	AFTER (patched)
TLSX_Parse(ssl_v1_3, {0x00 0x05 0x00 0x00}, msgType=certificate)	FAIL — ret=0 (silently accepted)	PASS — ret=-429 UNSUPPORTED_EXTENSION

The BEFORE/AFTER distinction shows the bug is at admission time:
the unpatched library treats the extension as parsed-and-success
because CSR_PARSE is a no-op stub. The patched library
short-circuits the case to unsupported_extension whenever CSR is
not built in and the message is certificate or
certificate_request.

Running the test harness

test.sh alongside this README automates the BEFORE/AFTER
verification. From this directory:

./test.sh

What it does, in order:

1. Resets src/tls.c via git checkout and asserts the patch
   marker is absent.
2. Runs ./configure --enable-tls13 --enable-static (CSR
   intentionally disabled so we exercise the default-build code
   path, and --enable-static so libwolfssl.a is built for
   linking).
3. Builds wolfSSL and the reproducer (linked against
   libwolfssl.a directly so the WOLFSSL_LOCAL symbol resolves).
4. BEFORE: runs the reproducer; expects FAIL.
5. Applies issue-10319.patch, rebuilds, re-links.
6. AFTER: runs the reproducer; expects PASS.
7. Prints a colored summary.
8. On exit, restores the tree (trap).

Exit status: 0 only when BEFORE FAILs and AFTER PASSes.

---

issue-10319.patch — +33 lines in src/tls.c, two parallel #ifndef arms

diff --git a/src/tls.c b/src/tls.c
index c60826121..a18cb0917 100644
--- a/src/tls.c
+++ b/src/tls.c
@@ -17543,6 +17543,22 @@ int TLSX_Parse(WOLFSSL* ssl, const byte* input, word16 length, byte msgType,
                         msgType != certificate_request &&
                         msgType != certificate)
                         return EXT_NOT_ALLOWED;
+#ifndef HAVE_CERTIFICATE_STATUS_REQUEST
+                    /* Issue #10319: when CSR support is not built in,
+                     * the local endpoint never advertises status_request
+                     * in ClientHello and never includes it in
+                     * CertificateRequest, so a status_request seen in a
+                     * CertificateRequest or Certificate message is
+                     * unsolicited. RFC 8446 Section 4.2 + Section 4.4.2
+                     * require the receiver to abort the handshake with
+                     * an unsupported_extension alert in that case. */
+                    if (msgType == certificate_request ||
+                            msgType == certificate) {
+                        SendAlert(ssl, alert_fatal, unsupported_extension);
+                        WOLFSSL_ERROR_VERBOSE(UNSUPPORTED_EXTENSION);
+                        return UNSUPPORTED_EXTENSION;
+                    }
+#endif
                 }
                 else
  #endif
@@ -17574,6 +17590,20 @@ int TLSX_Parse(WOLFSSL* ssl, const byte* input, word16 length, byte msgType,
                         msgType != server_hello)
                         return EXT_NOT_ALLOWED;
                 }
+#if defined(WOLFSSL_TLS13) && !defined(HAVE_CERTIFICATE_STATUS_REQUEST_V2)
+                /* Issue #10319: same offered-list rule as
+                 * status_request — without v2 support compiled in, an
+                 * incoming status_request_v2 in a TLS 1.3
+                 * CertificateRequest or Certificate is unsolicited and
+                 * must be rejected with unsupported_extension. */
+                if (IsAtLeastTLSv1_3(ssl->version) &&
+                        (msgType == certificate_request ||
+                         msgType == certificate)) {
+                    SendAlert(ssl, alert_fatal, unsupported_extension);
+                    WOLFSSL_ERROR_VERBOSE(UNSUPPORTED_EXTENSION);
+                    return UNSUPPORTED_EXTENSION;
+                }
+#endif
                 ret = CSR2_PARSE(ssl, input + offset, size, isRequest);
                 break;
 

issue-10319-test.c — direct TLSX_Parse() call via static link

/* issue-10319-test.c
 *
 * Reproducer for wolfSSL issue #10319:
 *   "[Bug]: Client Certificate Extensions Offered-List Inconsistency"
 *
 * In a default wolfSSL build (without HAVE_CERTIFICATE_STATUS_REQUEST)
 * the macro CSR_PARSE in src/tls.c reduces to a no-op stub.
 * `case TLSX_STATUS_REQUEST` in TLSX_Parse() therefore lets a
 * status_request extension through silently when it appears in a
 * TLS 1.3 client Certificate (or CertificateRequest) — even though
 * the local endpoint never advertised the extension in ClientHello
 * and the server never offered it in CertificateRequest, so any such
 * occurrence is by definition unsolicited.
 *
 * RFC 8446 Section 4.4.2 says client Certificate extensions MUST
 * correspond to extensions in the server's CertificateRequest, and
 * Section 4.2 says an unsolicited extension MUST trigger an
 * unsupported_extension alert.
 *
 * This reproducer constructs a 4-byte extension list containing one
 * status_request (type 0x0005, length 0) and feeds it directly into
 * the internal TLSX_Parse() function with msgType = certificate (11).
 * The reproducer is statically linked against libwolfssl.a so it can
 * resolve the WOLFSSL_LOCAL symbol.
 *
 * Behaviour:
 *   - BEFORE the patch (current default build): TLSX_Parse() returns
 *     0 — silent accept. Test prints FAIL and exits 1.
 *   - AFTER  the patch: TLSX_Parse() returns UNSUPPORTED_EXTENSION
 *     (-429). Test prints PASS and exits 0.
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <wolfssl/options.h>
#include <wolfssl/ssl.h>
#include <wolfssl/error-ssl.h>

/* Forward declaration of the internal TLSX_Parse(). Implemented in
 * src/tls.c. WOLFSSL_LOCAL hides it from the shared library's
 * dynamic symbol table, but it is still present in libwolfssl.a, so
 * static linking resolves it. */
extern int TLSX_Parse(WOLFSSL* ssl, const unsigned char* input,
                      unsigned short length, unsigned char msgType,
                      void* suites);

/* From wolfssl/internal.h enum HandShakeType: certificate = 11. */
#define HS_CERTIFICATE 11

int main(int argc, char** argv)
{
    int          rc = 1;
    WOLFSSL_CTX* ctx = NULL;
    WOLFSSL*     ssl = NULL;
    int          ret;

    /* extension list:
     *   ext_type   : status_request (0x0005)
     *   ext_length : 0
     *   ext_body   : (empty)
     */
    static const unsigned char ext_blob[] = {
        0x00, 0x05, 0x00, 0x00
    };

    (void)argc; (void)argv;

    wolfSSL_Init();

    ctx = wolfSSL_CTX_new(wolfTLSv1_3_client_method());
    if (ctx == NULL) {
        fprintf(stderr, "ctx alloc failed\n");
        goto out;
    }
    ssl = wolfSSL_new(ctx);
    if (ssl == NULL) {
        fprintf(stderr, "ssl alloc failed\n");
        goto out;
    }

    ret = TLSX_Parse(ssl, ext_blob, (unsigned short)sizeof(ext_blob),
                     HS_CERTIFICATE, NULL);
    printf("TLSX_Parse(certificate, status_request) ret=%d\n", ret);

    if (ret == WC_NO_ERR_TRACE(UNSUPPORTED_EXTENSION)) {
        printf("PASS  status_request rejected in TLS 1.3 Certificate "
               "(RFC 8446 4.4.2 obeyed)\n");
        rc = 0;
    }
    else if (ret == 0) {
        printf("FAIL  status_request silently accepted in TLS 1.3 "
               "Certificate (RFC 8446 4.4.2 violated)\n");
        rc = 1;
    }
    else {
        printf("FAIL  unexpected ret=%d (expected 0 BEFORE / -429 AFTER)\n",
               ret);
        rc = 1;
    }

out:
    if (ssl != NULL) wolfSSL_free(ssl);
    if (ctx != NULL) wolfSSL_CTX_free(ctx);
    wolfSSL_Cleanup();
    return rc;
}

test.sh — BEFORE/AFTER harness

#!/bin/bash
# End-to-end BEFORE/AFTER runner for wolfSSL issue #10319
# ("Client Certificate Extensions Offered-List Inconsistency").
#
# 1. Resets src/tls.c to its committed state.
# 2. Configures + builds wolfSSL with TLS 1.3 but WITHOUT
#    OCSP/status_request support (HAVE_CERTIFICATE_STATUS_REQUEST
#    disabled), matching the default-build scenario the reporter
#    tested.
# 3. Builds the reproducer, statically linked against libwolfssl.a
#    so that the WOLFSSL_LOCAL symbol TLSX_Parse() can be called
#    directly.
# 4. BEFORE: runs the reproducer. Expected FAIL — TLSX_Parse()
#    returns 0 because case TLSX_STATUS_REQUEST falls through to
#    the no-op CSR_PARSE stub.
# 5. Applies issue-10319.patch and rebuilds.
# 6. AFTER: runs the reproducer. Expected PASS — TLSX_Parse()
#    returns UNSUPPORTED_EXTENSION (-429).
# 7. Restores the tree on exit via trap.
#
# Exit code: 0 iff BEFORE FAILs and AFTER PASSes.

set -u

ISSUE_N="10319"
SOURCE_FILE_RELATIVE="src/tls.c"
# CSR support intentionally NOT enabled — that's the build the
# reporter tested and the build my patch targets.
CFG_FLAGS="--enable-tls13 --enable-static"
PATCH_MARKER="Issue #10319"

HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO="$(cd "$HERE/../.." && pwd)"
cd "$REPO"

TEST_BIN="$HERE/issue-${ISSUE_N}-test"
TEST_SRC="$HERE/issue-${ISSUE_N}-test.c"
PATCH="$HERE/issue-${ISSUE_N}.patch"
LIB_DIR="$REPO/src/.libs"
CFG_LOG="/tmp/wolfssl-cfg-${ISSUE_N}.log"
BLD_LOG="/tmp/wolfssl-build-${ISSUE_N}.log"

red()   { printf '\033[31m%s\033[0m' "$*"; }
green() { printf '\033[32m%s\033[0m' "$*"; }
bold()  { printf '\033[1m%s\033[0m'  "$*"; }
section() { echo; echo "==================== $* ===================="; }

PATCH_PREEXISTING=0
if grep -q "$PATCH_MARKER" "$REPO/$SOURCE_FILE_RELATIVE" 2>/dev/null; then
    PATCH_PREEXISTING=1
fi

restore_tree() {
    echo
    echo "Restoring tree to pre-script state..."
    git -C "$REPO" checkout -- "$SOURCE_FILE_RELATIVE"
    if [ "$PATCH_PREEXISTING" = "1" ]; then
        git -C "$REPO" apply "$PATCH" || echo "  WARN: could not re-apply patch"
        make -C "$REPO" -j"$(nproc)" >"$BLD_LOG" 2>&1 || true
    else
        make -C "$REPO" -j"$(nproc)" >"$BLD_LOG" 2>&1 || true
    fi
}
trap restore_tree EXIT

section "Reset $SOURCE_FILE_RELATIVE to clean state"
git -C "$REPO" checkout -- "$SOURCE_FILE_RELATIVE"
if grep -q "$PATCH_MARKER" "$REPO/$SOURCE_FILE_RELATIVE"; then
    echo "ERROR: $SOURCE_FILE_RELATIVE still has patch markers after checkout."
    exit 1
fi

section "Configure wolfSSL ($CFG_FLAGS)"
./configure $CFG_FLAGS >"$CFG_LOG" 2>&1 || {
    echo "configure failed; tail of $CFG_LOG:"
    tail -30 "$CFG_LOG"
    exit 1
}

# Sanity check: confirm CSR is NOT defined in the resulting options.h
if grep -q "define HAVE_CERTIFICATE_STATUS_REQUEST\b" "$REPO/wolfssl/options.h" 2>/dev/null; then
    echo "WARNING: HAVE_CERTIFICATE_STATUS_REQUEST is defined; this is not the default build."
fi

section "Build wolfSSL (unpatched)"
make -j"$(nproc)" >"$BLD_LOG" 2>&1 || {
    echo "build failed; tail of $BLD_LOG:"
    tail -40 "$BLD_LOG"
    exit 1
}

section "Build reproducer (statically linked)"
gcc -Wall -Wextra -I"$REPO" \
    "$TEST_SRC" "$LIB_DIR/libwolfssl.a" \
    -lm -lpthread -o "$TEST_BIN" || {
    echo "reproducer compile/link failed"
    exit 1
}
echo "  built $TEST_BIN"

run_repro() {
    local label="$1"
    echo; echo "  --- $label ---"
    "$TEST_BIN" 2>&1
    local rc=$?
    echo "  reproducer exit = $rc"
    return $rc
}

section "BEFORE (unpatched / buggy) — expected: FAIL"
run_repro "TLSX_Parse(certificate, status_request)"
RC_BEF=$?

section "Apply issue-${ISSUE_N}.patch and rebuild"
git -C "$REPO" apply "$PATCH" || {
    echo "git apply failed"
    exit 1
}
echo "  patch markers in $SOURCE_FILE_RELATIVE: $(grep -c "$PATCH_MARKER" "$REPO/$SOURCE_FILE_RELATIVE")"
make -j"$(nproc)" >"$BLD_LOG" 2>&1 || {
    echo "patched build failed; tail of $BLD_LOG:"
    tail -40 "$BLD_LOG"
    exit 1
}
# Re-link the reproducer against the rebuilt libwolfssl.a.
gcc -Wall -Wextra -I"$REPO" \
    "$TEST_SRC" "$LIB_DIR/libwolfssl.a" \
    -lm -lpthread -o "$TEST_BIN" || {
    echo "reproducer re-link failed"
    exit 1
}

section "AFTER (patched) — expected: PASS"
run_repro "TLSX_Parse(certificate, status_request)"
RC_AFT=$?

section "Summary"
fmt_expected_fail() { [ "$1" != "0" ] && green "FAIL (expected — bug present)" || red "PASS (UNEXPECTED — bug not reproduced)"; }
fmt_expected_pass() { [ "$1"  = "0" ] && green "PASS (expected — fix in place)"  || red "FAIL (UNEXPECTED — fix did not hold)"; }

printf "  BEFORE  cert+status_request : "; fmt_expected_fail "$RC_BEF"; echo
printf "  AFTER   cert+status_request : "; fmt_expected_pass "$RC_AFT"; echo

OK=1
[ "$RC_BEF" = "0" ] && OK=0
[ "$RC_AFT" = "0" ] || OK=0

if [ "$OK" = "1" ]; then
    echo; bold "Overall: all outcomes as expected."; echo
    exit 0
else
    echo; bold "Overall: at least one outcome was UNEXPECTED."; echo
    exit 1
fi

Happy to turn this into a PR if useful.