On 03/30/2011 10:58 AM, Luke Schierer wrote:
>> On 03/25/2011 07:12 AM, Luke Schierer wrote:
>>> Should the 389ds be able to understand "usercertificate;binary",
>>> this a misconfiguration on my part in the directory server, or is that
>>> something I should be expecting the directory to understand?
>> the ;binary option was defined in http://www.ietf.org/rfc/rfc2251.txt
>> but dropped in http://www.ietf.org/rfc/rfc4511.txt
(see C.1.7. Section
>> 18.104.22.168 (Binary Option) and others)
>> So the real fix would be to change the client app to not use
>> You could also file a bug/RFE against 389 to add support for legacy
>> that still use ";binary". Another fix would be to add a duplicate
>> attribute "usercertificate;binary" which is a duplicate of the
>> userCertificate attribute.
> Thanks for this information. Based on your reply, I have submitted a
> to my upstream vendor for the client app.
> I would like to try creating an attribute, "usercertificate;binary" as a
> temporary work around while I wait for the client app to be fixed.
> However, when I go into the console to the configuration tab and then
> the schema object in the tree, I get an error when I attempt to create
> attribute. As soon as I type in the semi-colon character in the
> name, the text "Attribute Name" turns red and the "ok" button
> It appears that is an illegal attribute name.
Hmm - looks like you won't be able to use the console to do this. You
can use ldapsearch and ldapmodifiy though:
ldapsearch -x -LLL ..... '(uid=theusersid)' userCertificate > user.ldif
then edit user.ldif - under the dn: line, add
then change "userCertificate" to "userCertificate;binary"
then ldapmodify -x ..... -f user.ldif
> If I were to manually edit the schema files, would it work, or would it
> break things?
I don't think you need to edit the schema files
With this approach, I was able to successfully add usercertificate;binary
attributes, and successfully pull them from the client application.