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