PKIX standards (RFC 3280) state the following about Serial Numbers:
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.
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.
Note: Non-conforming CAs may issue certificates with serial numbers
that are negative, or zero. Certificate users SHOULD be prepared to
gracefully handle such certificates.
If the product you were using to generate certificates was a commercial
product, I'm surprised that it generated certificates with duplicate
serial numbers (this is like having multiple records in a relational DB
table with the same primary key).
Thanks for the clarification.
Arshad Noor
StrongAuth, Inc.
Michael Pratt wrote:
It was an oversight. Our SAs created a script to automatically generate
certs for all users, and when it came to assigning a value to serial number
they couldn't find any documentation or guidance on how to properly assign
this value. Plus the fact that our combined experience with LDAP and SSL
was close to zero when we started.
So yeah, it was definitely an oversight on our part, but it would still be
nice if this was documented. I couldn't find in any of the docs (
http://docs.sun.com/app/docs/coll/S1_DirectoryServer_52) where it stated DS
would behave that way if the serial number wasn't unique. Of course, this
may be such common practice (or even the standard) that documenting it
seems
silly, I don't know.
Mike
On 5/2/06, Arshad Noor <[EMAIL PROTECTED]> wrote:
While the traditional definition of a digital certificate is taken to
be the "binding of a name to a public key", why would you issue certs
with duplicate serial numbers? Was this an oversight or a design
decision? If the latter, it would help the forum to understand the
business/technical requirements leading to such a decision. Thanks.
Arshad Noor
StrongAuth, Inc.
Michael Pratt wrote:
> I'm cross posting this to crypto and ldap in the hopes nobody else will
> waste months of effort on a simple issue :)
>
> Those of you that frequent these boards have probably seen several
posts
> from me dating back to January regarding problems with client
> authentication
> and Sun directory server. We've been trying to set up our apps using
> Mozilla Java and C APIs and have them authenticate with using SASL /
> External. The problem was when multiple users would run at the same
time,
> one of them would fail to authenticate on the directory server and
return
> error "-12271: SSL peer cannot verify your certificate".
>
> The problem was with the directory server (5.2 patch 4, Solaris 8) and
how
> it handles client certificates (or possibly in how we created the
> certificates). Apparently if the same DS machine receives two
certifcates
> at the same time with the same serial number value, only one will be
> succesfully processed and the other will return the error above. This
was
> pointed out to us by a Sun engineer, and it wasn't clear if this is a
> bug in
> the version or if this is how DS was intended to work. Regardless,
once
we
> changed each user's cert to have a unique serial number the problem
> dissapeared.
>
> Mike
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
