retrieving x509 certificates using java

[Luke Schierer]

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

[Rich Megginson]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

[Luke Schierer]

>  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

[Rich Megginson]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

[Luke Schierer]

>  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