OpenSSL › OpenSSL - User

AW: openssl can don' t handle 20 Octes long Serial Numbers RFC 32 80

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

thomas.beckmann

AW: openssl can don' t handle 20 Octes long Serial Numbers RFC 32 80

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

Kyle Hamilton

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]

Bohn, Michael

AW: openssl can don' t handle 20 Octes long Serial Numbers RFC 32 80

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:

______________________________________________________________________
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]

Peter Sylvester-3

Re: openssl can don' t handle 20 Octes long Serial Numbers RFC 32 80

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.

smime.p7s (6K) Download Attachment

JoelKatz

RE: openssl can don' t handle 20 Octes long Serial Numbers RFC 32 80

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]