Michael,
Michael Pratt wrote:
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
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
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
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 requi
On 5/2/06, Michael Pratt <[EMAIL PROTECTED]> wrote:
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 sa
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'v
6 matches
Mail list logo
