openssl x509 -noout -serial
returns only 16 characters also.

Here is a hex dump of the first bytes of that cert, ending immediately after the encoding of the serial number:

30820816308206fea00302010202 1100c9f97f52c320766d6df0d55dd229559e

I agree that the serial number is encoded using 17 octets.

However, the fact that only 16 octets are displayed by the command-line utility is intentional.

When displaying an asn1 INTEGER in printable hex, if the leading octet is zero, then it is not displayed.

This behaviour can be surprising, and we have had some internal discussions on it (I will link to the related github issue if I can find it).

converting this to der format and dumping it out in hexedit shows this:

00000000   30 82 08 16  30 82 06 FE  A0 03 02 01  02 02 11 00  C9 F9 7F 52  C3 20 76 6D  6D F0 D5 5D  0...0..............R. vmm..]

Byte 0 (0x30) is the start of the sequence in asn1parse
Byte 4 (0x30) is the start of the next sequence in asn1parse
Byte 8 (0xA0) is the cons (0) value from asn1parse
Byte 10 (0x2) is the first integer reported in asn1parse (with a value of 2)
Byte 13 (0x2) is the serial number that is output (purportedly with a length of 17)

However, if you look at byte 15 which is the first byte of the serial number, its zero (0x0). Since the value is encoded as an integer, I would imagine that the decode is truncating the leading zero, as a zero padded integer is just the integer

However

https://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf

Indicates that when encoding an integer the bits of the first octet and bit 8 of the second octect:

1. shall not all be ones
   and
2. shall not all be zero

To ensure minimal space during encoding.

But bit 8 of the second octet (0xc9) is 1 meaning both of those requirements would be met, and truncating the leading zero would result in a sign change. The truncation would have been ok if bit 8 of the second octet were zero, but since, its not that would lead to a sign change, which definately seems like a bug to me

Here is a related PR (unmerged):

#8136

Above, I said:

When displaying an asn1 INTEGER in printable hex, if the leading octet is zero, then it is not displayed.

After re-reading the discussion in that PR, I see that my comment isn't completely accurate. There is some inconsistency in how openssl treats leading zero octets when displaying an asn1 INTEGER.

It seems to me that the leading zero in this case has to be included as truncating it results in the sign of the represented integer being flipped.

The leading zero is just a DER encoding artifact. The serial number is a number, thus the leading zero would not be displayed. This is not a bug.

The serial number isn'tjust a number... it's a signed number.asn1parse doesn't have any information on the number's signedness, though, it just parses DER (not ASN.1 😆), so it's difficult to know whether C9F97F52C320766D6DF0D55DD229559E is meant to be interpreted as C9F97F52C320766D6DF0D55DD229559E or as -360680AD3CDF8992920F2AA22DD6AA62.

Point is thatasn1parse is supposed to show what it parsed rather than a somewhat frivolous interpretation. Since a (positive) C9F97F52C320766D6DF0D55DD229559E is encoded 00C9F97F52C320766D6DF0D55DD229559E, I can understand why the lack of that leading 00 can be a bit... surprising, for those who pay attention to these details.

I'd regard this as a bug, but perhaps not a terribly important one

Github seems to be having issues at the moment, but IIRC#8136 indicated that openssl x509 -text was showing a simmilar issue

Ok, I see now, DER encoded the a 16 byte integer using a minimum of 17 bytes because the DER encoding has to preserve the sign of the integer being encoded. Whatever did the encoding interpreted the serial number as positive, so the DER encoding added an extra zero pad to record the fact that the value was positive (rather than negative as would have been the interpretation if the zero pad wasn't there). asn1parse is smart enough to prepend a '-' (negative) notation in front of a number that it parses from DER when the leading bit is zero, so we can correctly interpret a printed integer value (even one in hex with the MSB set), as positive or negative based on the presence or lack of '-'.

In fact editing the provided file to make the uppper octet in DER 0xFF results in this print out:

openssl asn1parse -in ./cert.der -inform DER    0:d=0  hl=4 l=2070 cons: SEQUENCE              4:d=1  hl=4 l=1790 cons: SEQUENCE              8:d=2  hl=2 l=   3 cons: cont [ 0 ]           10:d=3  hl=2 l=   1 prim: INTEGER           :02   13:d=2  hl=2 l=  17 prim: INTEGER           :-7F360680AD3CDF8992920F2AA22DD6AA62   32:d=2  hl=2 l=  13 cons: SEQUENCE

So we can see how we handle +/- integers, and that the encoding size doesn't necessecarily match the number of octets printed because of said padding.

I agree now, this isn't a bug

Thanks to all for the discussion/explanation. Now I have to convince a vendor that their display of the 00 is wrong.

Now I have to convince a vendor that their display of the 00 is wrong.

before you commit too fiercely to one side of the discussion, please note that other tools for displaying ASN1 data in a human-readable form have made different design choices thanopenssl asn1parse.

e.g.dumpasn1 shows the leading00:

$ openssl x509 -in Sectigo-cert.cer -outform DER -out foo.der$ dumpasn1 foo.der | head   0 2070: SEQUENCE {   4 1790:   SEQUENCE {   8    3:     [0] {  10    1:       INTEGER 2         :       }  13   17:     INTEGER 00 C9 F9 7F 52 C3 20 76 6D 6D F0 D5 5D D2 29 55 9E  32   13:     SEQUENCE {  34    9:       OBJECT IDENTIFIER         :         sha256WithRSAEncryption (1 2 840 113549 1 1 11)  45    0:       NULL

The sad part is to "add insult to injury" the vendor's code renders the serial number as a set of 16 hex bytes, adding a newline before the 17th byte e.g. Serial Number: 00 B6 94 C3 AE A4 A3 58 E5 5F 7F 03 F9 F4 18 55 which means that you are unable to grep the output of the tool for "Serial Number" and get the full serial number.
This makes the extraction of the serial number (from 100+ hosts) for comparison to the list of issued certificate serial numbers somewhat more of a challenge.
Thanks to all who participated in this discussion. Too bad their isnt a 'standard'.

Unfortunately, not so many people these days have a sufficient understanding of ASN.1 BER encoding (including its variant DER).