We have a java application that is attempting to pull the userCertificate attribute from our 389ds ldap server. Looking at the ldap logs, I see its request, and it looks like it should be working, except for one oddity, it is asking for the attribute "usercertificate;binary". By attaching eclipse to the application, we have determined that the general flow of the code is
<get certificate from client and put it into myCert>
LDAPCertStoreParameters loCertStoreParams = new LDAPCertStoreParameters(<ldap_host>,<ldap_port>);
CertStore loCertStore = CertStore.getInstance("LDAP", loCertStoreParams, "Sun");
x509CertSelector loTargetConstraints = new X509CertSelector();
lsSubjectDN = CSFGlobalPKIUtil.getSubjectDNFromCertificate(myCert); //we have verified that everything works fine as far as this point.
loTargetConstraints.setSubject(lsSubjectDN); Collection loCol = loCertStore.getCertificates(loTargetConstraints);
Once the gall to getCertificates is made, a query is built and sent to the LDAP server using java internal classes, we believe it is ultimately the X509CertStoreLDAP class. We do not have the source to debug this part of the code, but at some point, without visible interaction in the source code we do have, it choses to ask for "usercertificate;binary" instead of just "usercertificate".
Should the 389ds be able to understand "usercertificate;binary", and is this a misconfiguration on my part in the directory server, or is that not something I should be expecting the directory to understand?
As a point of further information, when I try to replicate the behavior using ldapsearch, I also fail to retrieve a certificate when I request "usercertificate;binary" but succeed when I request only "usercertificate".
Any help would be greatly appreciated.
Thanks!!
Luke
On 03/25/2011 07:12 AM, Luke Schierer wrote:
We have a java application that is attempting to pull the userCertificate attribute from our 389ds ldap server. Looking at the ldap logs, I see its request, and it looks like it should be working, except for one oddity, it is asking for the attribute "usercertificate;binary". By attaching eclipse to the application, we have determined that the general flow of the code is
<get certificate from client and put it into myCert>
LDAPCertStoreParameters loCertStoreParams = new LDAPCertStoreParameters(<ldap_host>,<ldap_port>);
CertStore loCertStore = CertStore.getInstance("LDAP", loCertStoreParams, "Sun");
x509CertSelector loTargetConstraints = new X509CertSelector();
lsSubjectDN = CSFGlobalPKIUtil.getSubjectDNFromCertificate(myCert); //we have verified that everything works fine as far as this point.
loTargetConstraints.setSubject(lsSubjectDN); Collection loCol = loCertStore.getCertificates(loTargetConstraints);
Once the gall to getCertificates is made, a query is built and sent to the LDAP server using java internal classes, we believe it is ultimately the X509CertStoreLDAP class. We do not have the source to debug this part of the code, but at some point, without visible interaction in the source code we do have, it choses to ask for "usercertificate;binary" instead of just "usercertificate".
Should the 389ds be able to understand "usercertificate;binary", and is this a misconfiguration on my part in the directory server, or is that not 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 4.1.5.1 (Binary Option) and others)
So the real fix would be to change the client app to not use ";binary". You could also file a bug/RFE against 389 to add support for legacy apps that still use ";binary". Another fix would be to add a duplicate attribute "usercertificate;binary" which is a duplicate of the userCertificate attribute.
As a point of further information, when I try to replicate the behavior using ldapsearch, I also fail to retrieve a certificate when I request "usercertificate;binary" but succeed when I request only "usercertificate".
Any help would be greatly appreciated.
Thanks!!
Luke
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 03/25/2011 07:12 AM, Luke Schierer wrote:
<snip>
Should the 389ds be able to understand "usercertificate;binary", and is this a misconfiguration on my part in the directory server, or is that not 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 4.1.5.1 (Binary Option) and others)
So the real fix would be to change the client app to not use ";binary". You could also file a bug/RFE against 389 to add support for legacy apps 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 bug 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 into the schema object in the tree, I get an error when I attempt to create the attribute. As soon as I type in the semi-colon character in the attribute name, the text "Attribute Name" turns red and the "ok" button greys out. It appears that is an illegal attribute name.
If I were to manually edit the schema files, would it work, or would it break things?
Thanks!!
Luke
On 03/30/2011 10:58 AM, Luke Schierer wrote:
On 03/25/2011 07:12 AM, Luke Schierer wrote:
<snip> >> Should the 389ds be able to understand "usercertificate;binary", and is >> this a misconfiguration on my part in the directory server, or is that >> not >> 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 > 4.1.5.1 (Binary Option) and others) > > So the real fix would be to change the client app to not use ";binary". > You could also file a bug/RFE against 389 to add support for legacy apps > 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 bug 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 into the schema object in the tree, I get an error when I attempt to create the attribute. As soon as I type in the semi-colon character in the attribute name, the text "Attribute Name" turns red and the "ok" button greys out. 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 changetype: modify add: userCertificate;binary
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
Thanks!!
Luke
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 03/30/2011 10:58 AM, Luke Schierer wrote:
On 03/25/2011 07:12 AM, Luke Schierer wrote:
<snip> >> Should the 389ds be able to understand "usercertificate;binary", and >> is >> this a misconfiguration on my part in the directory server, or is that >> not >> 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 > 4.1.5.1 (Binary Option) and others) > > So the real fix would be to change the client app to not use ";binary". > You could also file a bug/RFE against 389 to add support for legacy > apps > 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 bug 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 into the schema object in the tree, I get an error when I attempt to create the attribute. As soon as I type in the semi-colon character in the attribute name, the text "Attribute Name" turns red and the "ok" button greys out. 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 changetype: modify add: userCertificate;binary
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.
Thanks!!
Luke
389-users@lists.fedoraproject.org