> Matt Thomlinson wrote:
> I now believe you've decoded the below incorrectly because the leading bit
> is set, making this a signed number which may have made some of your tools
> croak. Decoding by hand, I get the following mod/exp:
>
> 3047 0240 (asn, len, int tag, length of 40)
>
> modulus:
> DFAA A0F4 0CA3 853E 6942 C98D AC3F 1257 4ADB 50CB 263F 99E0 A922 1166 CD1E
> 959C 34EF BC66 84DF E3F7 3C62 F6B0 7D20 FE89 3B52 846F DD21 E099 C187 A1E3
> FE1B 14C3
>
>
> 0203 (int tag, length of 3)
> exponent:
> 0100 01
It is definitely a bug in the ASN.1 encoding of the certificate.
ASN.1 has definite rules about how to encode/decode INTEGERs.
# Print the contents of the certificates public key
ssleay asn1parse -offset 186 -length 73 <cert.pem
0:d=0 hl=2 l= 71 cons: SEQUENCE
2:d=1 hl=2 l= 64 prim: INTEGER :-2156600CF45D7BC297BE377354
C1EEA9B625B035DAC1672057DEEF9A33E26B64CC11449A7C211D09C49E0A5083E00277C5AE7
C9123DF20673F795F1D02E5EC3D
68:d=1 hl=2 l= 3 prim: INTEGER :010001
The problem is that the ASN_INTEGER is encoded as
02 BER_INTEGER
40 length 0x40
DF first byte (if top bit is set, the number is negative)
AA second byte
This means that the modulus has been encoded as a negative ASN1_INTEGER,
(the 0x80 bit is set in the first byte). There should be a leading 0x00.
ASN.1 negative numbers are stored in twos complement form. The
SSLeay/OpenSSL X509 printing tool is not displaying the 'negative' sign,
but the conversion from -ve twos complement to the internal libraries
bignum representation is occurring (negatives converted to '+ve' and
a flag is used to store the sign).
The other place where this shows up quite often is in the form of -ve serial
numbers on the certificates.
Another one for Peter Gutmann's collection of miss implemented ASN.1.
eric
