Michael,
OpenSSL ist working correct because "9a 38 74 00 00 00 00
25 be" is a negative integer. If you preceedyour serial number with "00"
everything will work fine... even the presentation of your number
with OpenSSL.
Best regards
Thomas
|
My belief is that the presentation should be as an octet string, as
opposed to a string representation of an integer. Furthermore, serial numbers are unsigned, not signed, and generally increment. The problem is that the CA did not embed "00" before the serial number of the certificate it signed -- and, by RFC, it is not required to. The serial number should be presented to the user as an opaque string of hex bytes, not (as current) a translation into an integer. -Kyle H On 1/11/06, [hidden email] <[hidden email]> wrote: > > Michael, > > OpenSSL ist working correct because "9a 38 74 00 00 00 00 25 be" is a > negative integer. If you preceedyour serial number with "00" everything will > work fine... even the presentation of your number with OpenSSL. > > Best regards > > Thomas > > > ________________________________ > Von: [hidden email] > [mailto:[hidden email]] Im Auftrag von Bohn, Michael > Gesendet: Mittwoch, 11. Januar 2006 07:20 > An: [hidden email] > Betreff: openssl can don' t handle 20 Octes long Serial Numbers RFC 3280 > > > > > Hi all, > sorry that I send the same e-mail again but I did't find any answer to my > last one. > > We have the case that openssl can not handle long serial numbers. > In ower case we have this Serail Nr. 9a 38 74 00 00 00 00 25 be > but OpenSSL 0.9.7e 25 Oct 2004 print this: > > openssl x509 -in file -noout -text > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > (Negative)65:c7:8b:ff:ff:ff:ff:da:42 > > > windows cisco and mozilla can handle this SN without any problems. > > > ################ RFC 3280 ############################ > > RFC 3280 Internet X.509 Public Key Infrastructure April 2002 > > > Given the uniqueness requirements above, serial numbers can be > expected to contain long integers. Certificate users MUST be able to > handle serialNumber values up to 20 octets. Conformant CAs MUST NOT > use serialNumber values longer than 20 octets. > > ############################################################### > > > best regards > > > Michael OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by thomas.beckmann
Okay I see if it's not requird to embed the "00" before the SN why does openssl prints that the number is negative ?
Michael Bohn -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Kyle Hamilton Gesendet: Mittwoch, 11. Januar 2006 15:22 An: [hidden email] Betreff: Re: openssl can don' t handle 20 Octes long Serial Numbers RFC 32 80 My belief is that the presentation should be as an octet string, as opposed to a string representation of an integer. Furthermore, serial numbers are unsigned, not signed, and generally increment. The problem is that the CA did not embed "00" before the serial number of the certificate it signed -- and, by RFC, it is not required to. The serial number should be presented to the user as an opaque string of hex bytes, not (as current) a translation into an integer. -Kyle H On 1/11/06, [hidden email] <[hidden email]> wrote: > > Michael, > > OpenSSL ist working correct because "9a 38 74 00 00 00 00 25 be" is a > negative integer. If you preceedyour serial number with "00" everything will > work fine... even the presentation of your number with OpenSSL. > > Best regards > > Thomas > > > ________________________________ > Von: [hidden email] > [mailto:[hidden email]] Im Auftrag von Bohn, Michael > Gesendet: Mittwoch, 11. Januar 2006 07:20 > An: [hidden email] > Betreff: openssl can don' t handle 20 Octes long Serial Numbers RFC 3280 > > > > > Hi all, > sorry that I send the same e-mail again but I did't find any answer to my > last one. > > We have the case that openssl can not handle long serial numbers. > In ower case we have this Serail Nr. 9a 38 74 00 00 00 00 25 be > but OpenSSL 0.9.7e 25 Oct 2004 print this: > > openssl x509 -in file -noout -text > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > (Negative)65:c7:8b:ff:ff:ff:ff:da:42 > > > windows cisco and mozilla can handle this SN without any problems. > > > ################ RFC 3280 ############################ > > RFC 3280 Internet X.509 Public Key Infrastructure April 2002 > > > Given the uniqueness requirements above, serial numbers can be > expected to contain long integers. Certificate users MUST be able to > handle serialNumber values up to 20 octets. Conformant CAs MUST NOT > use serialNumber values longer than 20 octets. > > ############################################################### > > > best regards > > > Michael OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Kyle Hamilton
Kyle Hamilton wrote:
> > The problem is that the CA did not embed "00" before the serial number > of the certificate it signed -- and, by RFC, it is not required to. > RFC 3280 says: 4.1.2.2 Serial number The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. |
In reply to this post by Kyle Hamilton
> My belief is that the presentation should be as an octet string, as > opposed to a string representation of an integer. Why? > Furthermore, serial > numbers are unsigned, not signed, and generally increment. Serial numbers *must* be positive. This one is negative. Therefore, it's broken. > The problem is that the CA did not embed "00" before the serial number > of the certificate it signed -- and, by RFC, it is not required to. It's required to present a positive integer as a serial number. It failed to do that. > The serial number should be presented to the user as an opaque string > of hex bytes, not (as current) a translation into an integer. Why? It *is* an integer, why should it not be presented as such? DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Free forum by Nabble | Edit this page |