[Bug]: WolfSSL accepts a certificate whose serial number is zero

[Jennifer-first]

Contact Details

[email protected]

Version

WolfSSL 5.6.4

Description

./configure make sudo make install ./testsuite/testsuite.test wolfSSL is configured and built by default

Reproduction steps

// gcc -g verify.c -o verify -lwolfssl
// gcc -g verify.c -o verify -lwolfssl
#include <stdlib.h>
#include <wolfssl/ssl.h>
#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/error-crypt.h>

int wolfSSL_Verify_PEM(char * cac, char * ec){
int ret = 0;

// to create a new wolfSSL cert manager
WOLFSSL_CERT_MANAGER* cm;
cm = wolfSSL_CertManagerNew();
if (cm == NULL){
	printf("Creating a new wolfSSL_CertManager failed!\n");
	exit(1);
}

// to load cac to the created wolfSSL_CertManager
ret = wolfSSL_CertManagerLoadCA(cm, cac, NULL);
if (ret != SSL_SUCCESS){
	printf("Loading cac to the created wolfSSL_CertManager failed!\n");
	exit(2);
}

// to verify the ec in the created wolfSSL_CertManager
ret = wolfSSL_CertManagerVerify(cm, ec, SSL_FILETYPE_PEM);
if (ret != SSL_SUCCESS){
	printf("wolfSSL_CertManagerVerify filed and with return code %d and error message %s\n",
		 ret,
		 wolfSSL_ERR_reason_error_string(ret));
}
else{
	printf("The target cert has passed through verification.\n");
}

// to free cm
wolfSSL_CertManagerFree(cm);

return ret;
}

int main(int argc, char ** argv){
char * cac = argv[1];
char * ec = argv[2];
wolfSSL_Verify_PEM(cac, ec);
return 0;
}

Actual result: The target cert has passed through verification. WolfSSL accepts a certificate whose serial number is zero which is forbidden by RFC 5280 and its errata. The certificate should be rejected according to Sec. 4.1.2.2 in RFC 5280 "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". OpenSSL: openssl verify -CAfile ca.pem 14.pem 14.pem：OK GnuTLS: certtool --verify --load-ca-certificate=ca.pem < 14.pem Chain verification output: Verified. The certificate is trusted. I provided this test certificate:

test.zip

Relevant log output

[kareem-wolfssl]

Hi @Jennifer-first ,

Thanks for the report. This was a known issue previously and has been resolved since 5.6.4. Please upgrade to 5.7.6 and retry your test. We have changed the behavior to fail on certificates with a serial number of zero by default, as long as WOLFSSL_ASN_ALLOW_0_SERIAL or WOLFSSL_NO_ASN_STRICT are not defined.

Thanks, Kareem

[jrosiek]

@kareem-wolfssl Since this ticket is still open, I hope this won't be considered necroposting.

I'm on 5.8.2, which - I assume - already contains this change. It seems through it is too strict and also applies to root certs. IMO this check should only apply to leaf and intermediate certificates in the chain. Here is why:

• https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.2 - only mentions certificates issued by CA, so IMO this does not apply to root
• There is a lot of existing root CAs that use serial number 0 (see for example here: https://support.apple.com/en-mo/103612). In effect the current implementation will reject stuff that currently is considered a normal practice.

Note that this is especially painfull in connection with wolfSSL strict full chain validation. For example, this chain:

Certificate chain         
 0 s:CN = *.binance.vision    
   i:C = US, O = Amazon, CN = Amazon RSA 2048 M02
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct 18 00:00:00 2024 GMT; NotAfter: Nov 16 23:59:59 2025 GMT
 1 s:C = US, O = Amazon, CN = Amazon RSA 2048 M02                                                                                                                        
   i:C = US, O = Amazon, CN = Amazon Root CA 1                                                                                                                                                                                                                                                                                                     
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256                                                                                                                 
   v:NotBefore: Aug 23 22:25:30 2022 GMT; NotAfter: Aug 23 22:25:30 2030 GMT
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1                                                                                                                           
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2                                                                                                                                                                                                             
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256                                                                                                                 
   v:NotBefore: May 25 12:00:00 2015 GMT; NotAfter: Dec 31 01:00:00 2037 GMT

will fail even though Amazon CA is in system's root CA list (as well as Starfield) and has non-zero sequence number. The reason is the Starfield cert does have zero sequence number :/

Thanks

[kareem-wolfssl]

Hi @jrosiek,

My apologies for my delayed response on this. You bring up a very good point, I've brought this up to the team for consideration. I'll let you know if we end up modifying this.