[Mono-bugs] [Bug 78226][Wis] Changed - Unable to bind to LDAP server via SSL using Novell.Directory.Ldap

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by directhex at apebox.org.

http://bugzilla.ximian.com/show_bug.cgi?id=78226

--- shadow/78226	2006-04-27 21:18:18.000000000 -0400
+++ shadow/78226.tmp.17851	2006-04-28 06:44:45.000000000 -0400
@@ -169,6 +169,27 @@
 78226.ldap.pem: OK
 
 I'll re-read the RFCs about the "lack" of (any type) key usage in v3
 certificates. In the mean time, I suggest you regenerate the server
 certificates (not your CA) to include an extended key usage with the
 oid 1.3.6.1.5.5.7.3.1 (Server Authentication).
+
+------- Additional Comments From directhex at apebox.org  2006-04-28 06:44 -------
+>> All certificates were generated with OpenLDAP.
+
+> Are you sure they were generated by OpenLDAP and not by OpenSSL ?
+
+Too many "Open"s for late at night.
+
+> I'll re-read the RFCs about the "lack" of (any type) key usage in v3
+> certificates. In the mean time, I suggest you regenerate the server
+> certificates (not your CA) to include an extended key usage with the
+> oid 1.3.6.1.5.5.7.3.1 (Server Authentication).
+
+That worked. For the benefit of Google, the required voodoo was adding
+"extendedKeyUsage = 1.3.6.1.5.5.7.3.1" below "[ usr_cert ]" in
+openssl.cnf.
+
+As far as I can read the RFCs, RFC3280 suggests that whilst purpose is
+optional, "Certificate using applications MAY require that a
+particular purpose be indicated in order for the certificate to be
+acceptable to that application." - That said, I may be misinterpreting.