Long certificate serial number with OpenSSL backend is null about curl

[bagder]

Thanks! I wrote up a slightly modified fix but based on your report and hints here. Landed in aff153f.

[dkjjr89]

Thank you!

[jay]

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.

[bagder]

@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.

[jay]

Ok. If you have no objections I'll replace that block with i2c_ASN1_INTEGER.

[bagder]

No objections at all!

[jay]

They're not using i2c_ASN1_INTEGER, for the output. I assumed they were based on what I was reading. Mistake! I should've tested the output of a large negative serial number to be sure. I created a cert with a serial of -999,999,999,999,999,999,999:

openssl req -config openssl.cnf -x509 -newkey rsa:2048 -keyout serial_number_negative_nines.key -out serial_number_negative_nines.crt -days 3650 -nodes -batch -set_serial -999999999999999999999 -subj /CN=localhost/
openssl x509 -noout -text -in serial_number_negative_nines.crt

Here's the relevant part of their x509 output, which comes from X509_print_ex:

        Serial Number:
             (Negative)36:35:c9:ad:c5:de:9f:ff:ff

And if I specify -serial it also shows serial=-3635C9ADC5DE9FFFFF. So I guess there is some basis. A smaller number that fits in a long like -2000 shows Serial Number: -2000 (-0x7d0) and serial=-07D0.

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!