CN constraints fix

[rlm2002]

Description

Applies DNS name constraints to Subject CN when SAN is unavailable.

Fixes zd#21611

Checklist

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

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m4-min-ecc

• FLASH: .text +64 B (+0.1%, 59,189 B / 262,144 B, total: 23% used)

gcc-arm-cortex-m4-tls12

• FLASH: .text +64 B (+0.1%, 119,482 B / 262,144 B, total: 46% used)
  No memory changes detected for:
• gcc-arm-cortex-m4- gcc-arm-cortex-m4-baremetal

[rlm2002]

retest this please Jenkins: history deleted

[rlm2002]

Retest this please Jenkins. generic-config-parser failed

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #10223

Scan targets checked: wolfcrypt-api_misuse, wolfcrypt-bugs, wolfcrypt-compliance, wolfcrypt-concurrency, wolfcrypt-consttime, wolfcrypt-defaults, wolfcrypt-mutation, wolfcrypt-portability, wolfcrypt-proptest, wolfcrypt-src, wolfcrypt-zeroize

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

[wolfSSL-Fenrir-bot]

🟠 [Medium] Surviving deletion mutation: subjectDnsName CN fallback has no test for permitted CN
Category: Surviving deletion mutations

The new test test_wolfSSL_CertManagerNameConstraint_DNS_CN only verifies that a CN violating the DNS name constraint (evil.attacker.com) is rejected. It does not test that a CN matching the permitted constraint (e.g., wolfssl.com or example.com) is accepted when no SAN is present. This means the entire subjectDnsName population block (lines 17663-17673) could be replaced with an unconditional return ASN_NAME_INVALID_E (or a hardcoded failure for missing SAN) and the test would still pass. A mutation that deletes the subjectDnsName.name = cert->subjectCN assignment and instead forces a constraint violation would survive all existing tests. A positive test case — a leaf cert with CN=wolfssl.com and no SAN that is expected to pass verification — is needed to confirm the CN-to-constraint matching logic actually works correctly rather than simply always rejecting certs without SANs.

if (cert->subjectCN != NULL && cert->altNames == NULL) {
    subjectDnsName.next = NULL;
    subjectDnsName.type = ASN_DNS_TYPE;
    subjectDnsName.len  = cert->subjectCNLen;
    subjectDnsName.name = cert->subjectCN;
}

Recommendation: Add a test case in test_wolfSSL_CertManagerNameConstraint_DNS_CN that creates a leaf cert with CN=wolfssl.com (a permitted name), no SAN extension, and verifies that wolfSSL_CertManagerVerifyBuffer returns WOLFSSL_SUCCESS (not ASN_NAME_INVALID_E). This ensures the CN fallback path correctly matches permitted names, not just rejects disallowed ones.