[sameehj]

Description

ProcessPeerCerts() checks the Extended Key Usage of CA certificates against the TLS purpose (serverAuth when verifying a server, clientAuth when verifying a client), but only for CAs the peer sends in its Certificate message. When the peer sends only its leaf and the issuing CA is already loaded in the CertManager, that CA's Extended Key Usage is not checked. The same chain is therefore rejected with EXTKEYUSE_AUTH_E when the intermediate is sent and accepted when it is omitted.

This change makes the result independent of which CAs the peer sends:

• Signer gains an extExtKeyUsageSet bit, set by FillSigner(), so an absent extension can be told apart from one that grants none of the known purposes.
• CheckSignerExtKeyUsage() walks from the leaf's issuer up to the self-signed trust anchor and applies the TLS purpose to every CA on the way. The trust anchor stays exempt, as in CheckChainCAExtKeyUsage(). The walk reuses the name constraints ancestor lookup, now exported as wolfssl_local_FindSignerByAkidOrName(), with the same cycle guard and WOLFSSL_MAX_CHAIN_DEPTH limit.
• The check runs after the leaf's own key usage checks. A verify callback can override it as it can the other leaf errors. It is skipped when a chain verify callback is installed, when verification is disabled, and for a trusted peer certificate (WOLFSSL_TRUST_PEER_CERT), whose chain is not used.
• With IGNORE_NAME_CONSTRAINTS the Signer has no issuer lookup data, so only the leaf's direct issuer is checked.

Testing

test_wolfSSL_chain_ca_ext_key_usage gains a leafOnly option, where the peer sends only the leaf and the CAs are loaded into the verifier. New cases:

• depth 1: codeSigning and clientAuth CA rejected, and serverAuth, no extension and anyExtendedKeyUsage accepted, when verifying a server
• depth 1: codeSigning and serverAuth CA rejected, and clientAuth and no extension accepted, when verifying a client
• depth 2, with the restricted CA above an unrestricted one and neither sent, for server and client authentication
• a verify callback overriding the result for a leaf-only chain, and one that accepts only EXTKEYUSE_AUTH_E, showing that the callback is given that error
• a self-signed codeSigning trust anchor with a leaf-only chain, which stays accepted

Built and run with the default configure flags plus cert generation, and with each of OPENSSL_EXTRA, OPENSSL_EXTRA + WOLFSSL_CHAIN_VERIFY_CB, IGNORE_NAME_CONSTRAINTS, WOLFSSL_ASN_ORIGINAL, WOLFSSL_ALT_CERT_CHAINS with CRL/OCSP and status request, WOLFSSL_TRUST_PEER_CERT, and NO_SKID. A trusted peer leaf whose issuer name matches a restricted CA in the CertManager still connects with the example client (-E). The new cases fail without the library change. The full --api suite passes in the default and OPENSSL_EXTRA builds.

NO_SKID note: the existing self-issued rollover cases in this test already fail on master with NO_SKID (ASN_SIG_CONFIRM_E); this change does not affect them.

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m0plus

• FLASH: .text +20 B (+0.0%, 70,447 B / 262,144 B, total: 27% used)

gcc-arm-cortex-m3

• FLASH: .text +184 B (+0.1%, 130,901 B / 262,144 B, total: 50% used)

gcc-arm-cortex-m4

• FLASH: .text +128 B (+0.1%, 210,012 B / 262,144 B, total: 80% used)

gcc-arm-cortex-m4-crypto-only

• FLASH: .text +64 B (+0.0%, 182,463 B / 262,144 B, total: 70% used)

gcc-arm-cortex-m4-dtls13

• FLASH: .text +192 B (+0.1%, 194,392 B / 1,048,576 B, total: 19% used)

gcc-arm-cortex-m4-min-ecc

• FLASH: .text +64 B (+0.1%, 67,673 B / 262,144 B, total: 26% used)

gcc-arm-cortex-m4-openssl-compat

• FLASH: .text +192 B (+0.0%, 795,108 B / 1,048,576 B, total: 76% used)

gcc-arm-cortex-m4-pq

• FLASH: .text +128 B (+0.0%, 311,780 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m4-rsa-only

• FLASH: .text +192 B (+0.1%, 343,192 B / 1,048,576 B, total: 33% used)

gcc-arm-cortex-m4-sp-math

• FLASH: .text +64 B (+0.1%, 67,673 B / 262,144 B, total: 26% used)

gcc-arm-cortex-m4-tls12

• FLASH: .text +192 B (+0.1%, 131,665 B / 262,144 B, total: 50% used)

gcc-arm-cortex-m4-tls13

• FLASH: .text +192 B (+0.1%, 249,358 B / 262,144 B, total: 95% used)

gcc-arm-cortex-m7

• FLASH: .text +128 B (+0.1%, 210,012 B / 262,144 B, total: 80% used)

gcc-arm-cortex-m7-pq

• FLASH: .text +192 B (+0.1%, 312,740 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m7-tls13

• FLASH: .text +128 B (+0.1%, 249,358 B / 262,144 B, total: 95% used)

linuxkm-standard

• Data: __patchable_function_entries +8 B (+0.0%, 51,976 B)
  No memory changes detected for:
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-pkcs7
• linuxkm-pie
• stm32-sim-stm32h753

[Copilot]

🟡 Changes recommended

Pending signers and restored caches can bypass issuer EKU checks, and repeated checks can invalidate certificate-specific callback overrides.

3 open issues

• Pass pending signers to issuer EKU lookup · New
• Persist signer EKU state in the certificate cache · New
• Preserve per-handshake CA EKU callback waivers · New

What changed in this PR

This PR extends TLS issuer Extended Key Usage checks to CAs loaded in the CertManager, aiming to make validation independent of which intermediates the peer sends.

Changes:

• Records EKU extension presence on cached signers.
• Walks issuer ancestors to enforce the TLS purpose while exempting self-signed trust anchors.
• Adds leaf-only chain tests for server/client authentication, callback overrides and trust-anchor handling.

File	Description
wolfssl/​wolfcrypt/​asn.h	Adds signer EKU presence state and declares the shared issuer lookup.
wolfcrypt/​src/​asn.c	Populates the new state and exposes the existing ancestor lookup.
tests/​api/​test_ssl_cert.c	Extends the handshake harness and adds cached-issuer test cases.
src/​internal.c	Adds issuer-chain EKU validation during peer certificate processing.

_{Review effort: Balanced}