Signature failure masked by date error under WOLFSSL_SMALL_CERT_VERIFY

Under WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse() runs the certificate signature check separately from the parse to keep peak memory down, then merges the two results, but it merged the signature result back only when the parse returned 0, so any parse error hid it. ParseCertRelative() reaches its validity-date, name-constraint and critical-extension checks only after ConfirmSignature() has passed, so splitting the signature check out inverts the precedence that makes "override date errors" a sound policy, and ASN_SIG_CONFIRM_E is never surfaced anywhere. The attacker needs no key material from the real PKI and no CA compromise: a self-made certificate carrying the expected subject name, the trusted CA's subject as its issuer, arbitrary bytes where the signature goes, a validity window in the past and the attacker's own key pair is sufficient. Affected builds define WOLFSSL_SMALL_CERT_VERIFY, which is off by default, is not set implicitly by any platform or preset header, and is not reachable from any CMake option; the autotools routes are --enable-lowresource, --enable-leantls, --enable-tinytls13=cert and --enable-tinytls13=mutualauth, and examples/configs/user_settings_embedded.h reaches it through WC_CFG_SMALL_CERT_VERIFY, which ships as 0, while neither --enable-all nor --enable-distro enables it at all. The application must additionally install a verify callback through wolfSSL_CTX_set_verify() or wolfSSL_set_verify() with WOLFSSL_VERIFY_PEER that returns 1 for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E; wolfSSL ships this exact shape as myVerify() in wolfssl/test.h under VERIFY_OVERRIDE_DATE_ERR, which examples/client -D selects. An application with no callback, or whose callback returns preverify for date errors, still fails the handshake, and wolfSSL_CertManagerVerifyBuffer() and wc_CheckCertSignature() report ASN_SIG_CONFIRM_E correctly in the same binary. TLS 1.2 and TLS 1.3 are affected in both directions, and DTLS reaches the same function; where the forged certificate is a chain certificate the callback's consent causes it to be cached in the WOLFSSL_CTX certificate manager, so an exposed deployment must restart the context or the process rather than merely reconnect.

WOLFSSL_SMALL_CERT_VERIFY を定義している場合、ProcessPeerCertParse() はパース処理から証明書の署名検証を切り離し、ピークメモリを抑えつつ両者の結果を統合します。しかし、署名検証結果はパースが0（成功）を返した場合にのみ戻されるため、パースエラーが署名検証の失敗を隠してしまいます。ParseCertRelative() は ConfirmSignature() が成功した後に有効期限、名前制約、重大な拡張の検査を行うため、署名検証を分割したことで「有効期限のエラーを上書きする」という正当なポリシーの優先順位が逆転し、ASN_SIG_CONFIRM_E はどこにも表れません。攻撃者は実際のPKIからの鍵情報やCAの侵害を必要とせず、期待されるサブジェクト名を持ち、信頼されたCAのサブジェクトを発行者とした自己署名証明書に、署名部分に任意のバイトを設定し、有効期限を過去にし攻撃者自身の鍵ペアを使うだけで攻撃を成立させることができます。影響を受けるビルドは WOLFSSL_SMALL_CERT_VERIFY を定義しており、これはデフォルトで無効、プラットフォームやプリセットヘッダーで暗黙に設定されることはなく、CMake オプションからもアクセスできません。autotools では --enable-lowresource、--enable-leantls、--enable-tinytls13=cert 及び --enable-tinytls13=mutualauth のルートで設定され、examples/configs/user_settings_embedded.h は WC_CFG_SMALL_CERT_VERIFY（デフォルト0）を通じてアクセスしますが、--enable-all や --enable-distro では有効化されません。さらにアプリケーションは wolfSSL_CTX_set_verify() または wolfSSL_set_verify() で WOLFSSL_VERIFY_PEER フラグを用いた検証コールバックをインストールし、ASN_BEFORE_DATE_E または ASN_AFTER_DATE_E の場合に 1 を返す必要があります。wolfSSL の wolfssl/test.h の VERIFY_OVERRIDE_DATE_ERR で myVerify() としてこの形が提供されており、examples/client の -D オプションで選択可能です。コールバックが無い場合、または日付エラーでプリベリファイを返すコールバックの場合はハンドシェイクが失敗します。一方、同じバイナリ内で wolfSSL_CertManagerVerifyBuffer() と wc_CheckCertSignature() は ASN_SIG_CONFIRM_E を正しく報告します。TLS 1.2 と TLS 1.3 は双方向で影響を受け、DTLS も同様の関数に到達します。偽造証明書がチェーン証明書の場合、コールバックの承認により WOLFSSL_CTX 証明書マネージャにキャッシュされるため、公開環境では再接続だけでなくコンテキストまたはプロセスの再起動が必要になります。