h.b.furuseth(a)usit.uio.no wrote:
Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I
don't
know.
Are you using the same version of OpenSSL on your other test machines? Have you
tried a newer version?
Makes sense that this wouldn't be a problem in HEAD since we're now using
liblber for certificate handling. I suppose we could patch RE23 to use
ber_get_int for the serial number. But at the moment this seems to be an
OpenSSL problem, in which case we can close this ITS.
The offending operation (on Jennifer Smith) adds one certificate and
deletes the old one. However the added and the old certificate compare
equal because certificateExactNormalize() produces the same string for
both:
0$email=ca(a)example.com,cn=example ca,
o=openldap example\2C ltd.,st=california,c=us
That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize()
returns serial number "0". The inputs to that function are
(gdb) p *sn
$6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0}
and
(gdb) p *sn
$8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0}
Those *sn values are the same as on a successful run on Linux, except
the 2nd data[1...] (the xample... string) which I presume does not
matter when length=1.
The input certificates ('val' arg to certificateExactNormalize()) are
correct.
--
-- Howard Chu
Chief Architect, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/