DNS name constraint fix

[rlm2002]

Description

A certificate with no dNSName SAN but another SAN type present (e.g. registeredID or iPAddress) bypassed the Subject CN dNSName name-constraint check. The CN-as-DNS fallback was gated on cert->subjectCN != NULL && cert->altNames == NULL && !cert->isCA instead of "no dNSName SAN", so an out-of-scope CN was accepted. The fallback now fires whenever no dNSName SAN is present, (RFC 6125 6.4.4 ). A non-dNSName SAN no longer suppresses the check.

Fixes zd#22078

Testing

Adds additional cases to test_wolfSSL_CertManagerNameConstraint_DNS_CN()

./configure --enable-all && make check

Checklist

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

[github-actions]

retest this please

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m0plus

• FLASH: .text +8 B (+0.0%, 64,099 B / 262,144 B, total: 24% used)

gcc-arm-cortex-m3

• FLASH: .text +12 B (+0.0%, 122,121 B / 262,144 B, total: 47% used)

gcc-arm-cortex-m4

• FLASH: .text +64 B (+0.0%, 199,820 B / 262,144 B, total: 76% used)

gcc-arm-cortex-m4-baremetal

• FLASH: .text +64 B (+0.1%, 66,763 B / 262,144 B, total: 25% used)

gcc-arm-cortex-m7-tls13

• FLASH: .text +64 B (+0.0%, 235,454 B / 262,144 B, total: 90% used)
  No memory changes detected for:
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• linuxkm-pie
• linuxkm-standard
• stm32-sim-stm32h753

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #10837

Scan targets checked: wolfcrypt-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src

No new issues found in the changed files. ✅

[Pig-Tail]

Thanks for putting this together, @rlm2002 — I verified the branch against my reproducer and the out-of-scope CN is now correctly rejected when only a non-dNSName SAN (registeredID/iPAddress) is present. The dnsSan == NULL gate is exactly right. 🙌

Since this restores the protection from CVE-2026-6731 for the RID/iPAddress SAN path, would it be worth tracking it with its own CVE/advisory once the fix lands in a release? It'd help downstream integrators that rely on DNS name constraints for sub-CA containment pick it up. No urgency — happy to review advisory text or provide anything else that's useful.

Thanks again for the quick fix.