Error parsing Microsoft Root Agency Certificate about asn1crypto HOT 2 CLOSED

OpenSSL is apparently more forgiving and treats the negative integer as a positive one, essentially adding one null '00' octet on the front. The output from the command even shows it as "00:81:55:22..." even though that is NOT what's encoded in the ASN.1. OpenSSL does not try re-encoding the certificate, either: it will spit out exactly what it took in, so that representation is very misleading. However, openssl x509 -inform der -pubkey -noout < der_cert_bytes will produce a corrected key.
In short, however, this certificate is malformed, period.
asn1crypto doesn't make any such assumptions, and keeps it as a negative integer. I would have to imagine plenty of other crypto software would choke: see mirleft/ocaml-x509#56 (comment) for this exact same problem surfacing elsewhere, and I agree with the sentiment, "I am very reluctant to add warts to support other people's old bugs."

OpenSSL's own asn1parse command will show you that it's a negative value:

> openssl asn1parse -offset 146 -length 73 < der_cert_bytes
    0:d=0  hl=2 l=  71 cons: SEQUENCE
    2:d=1  hl=2 l=  64 prim: INTEGER           :-7EAADD46755B901229182699F0AA4328322A43B1BFFDDE5D4E0878CF7AA12D0DBB4623648A4904B9A0BD4962DCC9F421ABF03242E066D5EFA7EE34BF344A58BF
   68:d=1  hl=2 l=   3 prim: INTEGER           :010001

The offset is necessary since asn1parse won't try to read inside the bit-string where the public key is stored.

from asn1crypto.

@geitda I meant to respond to this earlier - thank you for the explanation. I also agree with not adding warts to support other people's old bugs, even though the project I'm working on is surfacing an awful lot of other people's old bugs!

from asn1crypto.