MbedTLS accepts a certificate whose serial number is zero

[Jennifer-first]

Summary

MbedTLS accepts a certificate whose serial number is zero.However, RFC 5280 states: “The serial number must be a positive integer assigned by the CA to each certificate.”And,the errata #3200 "The serial number MUST be a positive non-zero integer assigned by the CA to each certificate".

System information

MbedTLS version (number or commit id): 3.6.6
Operating system and version: Ubuntu 20.04.5 LTS
Configuration (if not default, please attach mbedtls_config.h):Mbed TLS 3.6.6 (Default configuration, no changes made to mbedtls_config.h)
Compiler and options (if you used a pre-built binary, please indicate how you obtained it): Compiled from the official source archive (mbedtls-3.6.6.tar.bz2) using GNU Make and GCC. Installed globally via sudo make install.
Additional environment information: Ubuntu Linux (running inside a VirtualBox virtual machine), x86_64 architecture.

Expected behavior

MbedTLS should be rejected.

Actual behavior

. Loading the CA root certificate ... ok (0 skipped)
. Loading the certificate(s) ... ok

Steps to reproduce

~/mbedtls-3.6.6/programs/x509/cert_app mode=file filename=seed.pem ca_file=ca.pem

test.zip

[mpg]

Hi! Thanks for your interest in Mbed TLS and for your report.

I agree such certificates are invalid, and so we could indeed reject them.

I'll note our policy is we rely on trusted CAs to only sign correctly-formed, compliant certificates. By definition, trusted CAs are already trusted with much more delicate tasks, namely verifying the identify of the entity whose certificate they're signing, so we can also trust them to verify the syntactic correctness and compliance of certificates they're issuing.

So, I don't think we need to reject such certificates. That would perhaps be a nice thing to do: it's a pretty cheap check, and would probably align better with other implementations out there.

This seems a rather low priority improvement, considering there is no security or function impact in practice, so we're unlikely to work on it ourselves in the foreseeable future. However if you or someone else wants to raise a PR adding that check, and a corresponding test case in test_suite_x509parse, we'll try to review the PR.