CHAD
On Jul 7, 2014, at 11:03 PM, "Dave Thompson" <dthomp...@prinpay.com> wrote: >> From: owner-openssl-us...@openssl.org On Behalf Of Barbe, Charles >> Sent: Monday, July 07, 2014 21:59 > >> I will try an ASN.1 decoder tomorrow. Thanks for the suggestion! >> >> One thing I did try today was to have both servers generate their > certificates >> using the same private key. Theoretically I would expect the two certs to >> then be exactly the same to the bit... I am not providing any domain or ip >> specific fields just so that I can do this comparison and made sure all > other >> variable fields would be static. The only variable left should be my > signing > > If these certs are (intended to be) for the same server(s), then the server > identity (usually name, rarely IP) can be the same, but it should not be > omitted. > SSL clients are supposed to, and at least browsers do, enforce it. Yep I understand this. The removal of the name / ip was just for testing so I could do a binary compare of the two certs. > > Every cert should have a serial# which should be unique, and for real CA > certs > normally isn't even serial, it's random. OpenSSL still normally does serial. > Did you do something to fake the serial, or did you ignore that (small) > difference? In our case we're doing random but, again for my test only, I explicitly set it to 1. > >> algorithm vs the one used my openssl's code. What I think I found was that >> the two certs were identical except for 4 bytes. There was a 0x05 and 0x00 >> following two fields in the open ssl generated cert. Each occurrence of > these >> 2 bytes was following the signature algorithm identifier (in two places I >> think). These 4 bytes were not in the non-open ssl cert. could this be my >> problem? Is there a significance to the 0x05 and 0x00? They seemed to be >> part of the enclosing structure that contained the signature alg id but > not part >> of the id itself. At least according to wireshark. Are they necessary > padding >> that I'm missing in my custom cert generation? > They aren't necessary. Yes, the AlgorithmIdentifier occurs in two places; > X.509 was designed in early days when there was great concern over > the possibility of algorithm substitution attacks on publickey crypto as > there historically had been on some symmetric crypto, so it occurs in the > signed content (near the beginning) as well as after. > > The AlgorithmIdentifier is a general structure used in numerous places > for numerous purposes. In some of these uses it includes 'parameters' > which basically specialize the algorithm. In this use, the parameters > are not needed, and ASN.1 allows two ways of handling this: the parameters > can be omitted entirely, or they can be encoded as an ASN.1 NULL, which > is the bytes 05 00. A robust parser/verifier should accept both. This makes me think that my problem may be in our implementation of the protocol and not in the certificate itself. Thanks for the help! > >> Like I said earlier, I'll try to attach the certs tomorrow. I really > appreciate >> everybody's help! > FYI ASN.1 decode can also be done by openssl commandline 'asn1parse', > not as flexibly as some but it's already right to hand. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
