fix: enforce pathlen constraint in X509 API verify path

[afldl]

Summary

wolfSSL_X509_verify_cert() passes CERT_TYPE to ParseCertRelative(), but the pathlen enforcement guard in asn.c skips the check when type == CERT_TYPE:

if (type != CERT_TYPE && cert->isCA && cert->ca && ...)

This means the standalone X.509 verification API (wolfSSL_X509_verify_cert()) never enforces BasicConstraints.pathlen, allowing unlimited intermediate CAs.

The TLS handshake path is NOT affected — it already uses CHAIN_CERT_TYPE.

Fix

Change ssl_certman.c to use CHAIN_CERT_TYPE, consistent with the TLS path. One-line change:

-        ret = ParseCertRelative(cert, CERT_TYPE, VERIFY, cm, NULL);
+        ret = ParseCertRelative(cert, CHAIN_CERT_TYPE, VERIFY, cm, NULL);

Reproduction

Create a 3-tier chain: Root → Intermediate (pathlen:0) → Sub-CA → Leaf. The Sub-CA violates the intermediate's pathlen:0 constraint.

wolfSSL X509 API:  ACCEPT  ← BUG
OpenSSL 3.6.2:    REJECT
OpenSSL 1.1.1w:   REJECT
mbedTLS 3.6.6:    REJECT
LibreSSL 4.3.1:   REJECT
BearSSL 0.6:      REJECT

PoC available in the linked issue with full C source + pre-built DER certificates.

Testing

• The TLS handshake path already uses CHAIN_CERT_TYPE and works correctly — no regression expected
• Only the wolfSSL_X509_verify_cert() / wolfSSL_CertManagerVerifyBuffer() standalone API path changes behavior
• Existing certman tests should pass; pathlen violation chains will now be correctly rejected

Credit

Discovered through differential fuzzing of 6 X.509 implementations (PathDiff project).

[wolfSSL-Bot]

Can one of the admins verify this patch?