My question is completely wrong (0x2880 is alloc failure, not parsing failure)! Please ignore.
When using the nRF Connect SDK mbedtls implementation to conduct a TLS session with a server, if the server provides a certificate without a version field, handshaking will fail with:
mbedtls_x509_crt_parse_der() returned -10368 (-0x2880)
But the version field in the x.509 standard is marked "DEFAULT v1", and requires that "if the value of a type is its default value, it shall be absent". So version 1 certificates shouldn't, and generally don't have this field.
For example, here's how openssl parses the certificate from test.mosquitto.org:
% echo -n | openssl s_client -connect test.mosquitto.org:8883 2> /dev/null | openssl x509 -textCertificate:Data:Version: 1 (0x0)Serial Number:7d:d3:9b:4f:dc:5b:f7:2d:0f:0c:04:7e:b8:f3:23:9e:c1:9b:b7:b7Signature Algorithm: sha256WithRSAEncryptionIssuer: C=GB, ST=United Kingdom, L=Derby, O=Mosquitto, OU=CA, CN=mosquitto.org, [email protected]
Yet if you look at the raw content you can see that after the Certificate SEQUENCE (30 82 03 97) and the TBSCertificate SEQUENCE (30 82 02 7f), the version is missing and instead the serial number appears next (02 14 7d d3 9b 4f dc 5b f7 2d 0f 0c 04 7e b8 f3 23 9e c1 9b b7 b7):
% pbpaste | openssl enc -base64 -d | xxd00000000: 3082 0397 3082 027f 0214 7dd3 9b4f dc5b 0...0.....}..O.[00000010: f72d 0f0c 047e b8f3 239e c19b b7b7 300d .-...~..#.....0.
The offending mbedtls code is at sdk-mbedtls/library/x509_crt.c:1150.
It's been a painstaking process to get tls going, so to find it was never going to work anyway is quite the bummer. Surely I'm doing something wrong? Or am I really the first person to publicly find that Nordic's mbedtls implementation doesn't support v1 certificates?
