h.b.furuseth@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@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.