Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Long certificate serial number with OpenSSL backend is null #235
In lib/vtls/openssl/c in version 7.41.0 at line 2466 we have:
Since bufp gets pushed to return a certificate serial number setting the first character to null will always cause null to be returned, therefore, line 2477 should be removed. The snprintf call attempts to create a colon separated string but just the hexadecimal value is being inserted. Also, I could not locate documentation that says the serial number should be colon separated. To get long serial numbers returned from the library I changed the above block to:
Hope this helps!
added a commit
Apr 26, 2015
For other octets retrieved via CURLINFO_CERTINFO like rsa and signature a colon is used as the separator for each octet. I'm not sure why not for serial number. OpenSSL in their output uses the colon as a separator but only for long serial numbers (see openssl x509 -noout -text -in cert). I don't see why not do it that way for all. Though changing it to be consistent with the others at this point may break a user's parsing of it.
Another thing that looks strange in that area is output of negative serial numbers. The current way is to prefix the octets with - to designate negative direction (a la integer). but the way OpenSSL does it looks more correct.. although again any change at this point may break a user's parsing.
@jay changing it could still be safe as it was completely broken before and thus was never parsed successfully anyway! I can see how matching openssl's output could be valuable.
I also glanced over the negative thing before I ignored it but you're right, we should make sure to output the same serial number that openssl does, even when negative.
They're not using
Here's the relevant part of their x509 output, which comes from X509_print_ex:
And if I specify -serial it also shows
What libcurl is doing right now is the same as the OpenSSL 'serial' format, not the OpenSSL 'Serial Number' format. That's probably fine given that nobody's used it yet, but if you want I can change it to their 'Serial Number' format as seen in X509_print_ex. libcurl had something similar to that for small numbers prior to your change but it would have to be modified to take into account negative numbers.
So it doesn't look like much of an issue anymore. Shame, the i2c method still looks more correct to me and easier to parse!