You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Tony Blanchard <bl...@wanadoo.fr> on 2005/07/02 20:54:46 UTC
Case sensitive question ...
I all,
I created a new entry like this ou=CA,ou=system and this is a pkiCA
object which I use with LDAPCertStore in JDK 1.5.
I have some openssl certificates which issuer DNs are "OU=CA, OU=system"
The problem is that code like this does not work :
Context is already created with provider_url =
ldap://localhost:10389/ou=system
....
Attributes lAtts = MyOpenedLdapCtx.getAttributes ("OU=CA");
instead, this works:
Attributes lAtts = MyOpenedLdapCtx.getAttributes ("ou=CA");
Is there something I am missing or it is a bug I have to write in Jira
repository ?
I can not change the OU part of generated openssl certificate...
Thanks for help,
Tony Blanchard
Re: Case sensitive question ...
Posted by Emmanuel Lecharny <el...@apache.org>.
On Sun, 2005-07-03 at 09:05 +0200, Tony Blanchard wrote:
> Ok, I did not look to the DIRLDAP in jira but only to DIREVE. I have to
> say it is not really easy to submit/check issues because sometimes it
> is difficult to investigate wich function is implied... Nevertheless, it
> would not be easy to assign issues to the right person if there was only
> one entry point to issues...
No problem at all. The important point is to fill a JIRA, and if you
don't know which part is involved, put it in DIREVE. Each one of us is
supposed to read those issues and to take charge of the bug they can
understand and fix.
Re: Case sensitive question ...
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Ok, I did not look to the DIRLDAP in jira but only to DIREVE. I have to
say it is not really easy to submit/check issues because sometimes it
is difficult to investigate wich function is implied... Nevertheless, it
would not be easy to assign issues to the right person if there was only
one entry point to issues...
I think it is the same problem than the exception I have. It talks about
a search failure.
I will send you the trace later. I have not my working computer today.
For the version I use, it is true I have not updated since10 days ago.
Cheers,
Tony
Emmanuel Lecharny a écrit :
>Sorry Tony, I think that there is already a JIRA entry for this :
>http://issues.apache.org/jira/browse/DIRLDAP-35
>
>Could you check if this is the same pb?
>
>Sorry for the inconvenience, this bug is to be fixed in the next 0.9.1
>version.
>
>Emmanuel Lécharny
>
>On Sat, 2005-07-02 at 20:54 +0200, Tony Blanchard wrote:
>
>
>>I all,
>>
>>I created a new entry like this ou=CA,ou=system and this is a pkiCA
>>object which I use with LDAPCertStore in JDK 1.5.
>>I have some openssl certificates which issuer DNs are "OU=CA, OU=system"
>>
>>The problem is that code like this does not work :
>>
>>Context is already created with provider_url =
>>ldap://localhost:10389/ou=system
>>....
>>Attributes lAtts = MyOpenedLdapCtx.getAttributes ("OU=CA");
>>
>>instead, this works:
>>Attributes lAtts = MyOpenedLdapCtx.getAttributes ("ou=CA");
>>
>>Is there something I am missing or it is a bug I have to write in Jira
>>repository ?
>>I can not change the OU part of generated openssl certificate...
>>
>>Thanks for help,
>>Tony Blanchard
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------------------------
>>Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
>>Aucun virus connu a ce jour par nos services n'a ete detecte.
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
Re: Case sensitive question ...
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Hi Alex,
Remember I search for OU=CA,OU=system beginning from the system context
so I ask OU=CA
Connection :
// Set up the environment for creating the initial context
env.put( Context.PROVIDER_URL, "ldap://localhost:10389/ou=system" );
env.put( Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.put( "java.naming.security.authentication", "none");
pkiCtx = new InitialDirContext(env);
Seacrh code :
LdapName lPKI = new LdapName(pCert.getIssuerDN().toString());
LdapName lPKISuffix = (LdapName)lPKI.getSuffix(1);
Attributes lUserAttributes = pkiCtx.getAttributes(lPKISuffix); ("OU=CA")
Resulting Stack :
javax.naming.NameNotFoundException: [LDAP: error code 32 - failed on
search operation:
org.apache.ldap.common.message.SearchRequestImpl@842d9a
org.apache.ldap.common.exception.LdapNameNotFoundException: Attempt to
search under non-existant entry: OU=ca,ou=system
at
org.apache.ldap.server.exception.ExceptionService.assertHasEntry(ExceptionService.java:341)
at
org.apache.ldap.server.exception.ExceptionService.search(ExceptionService.java:319)
at
org.apache.ldap.server.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:899)
at
org.apache.ldap.server.authz.AuthorizationService.search(AuthorizationService.java:377)
at
org.apache.ldap.server.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:899)
at
org.apache.ldap.server.authn.AuthenticationService.search(AuthenticationService.java:289)
at
org.apache.ldap.server.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:899)
at
org.apache.ldap.server.normalization.NormalizationService.search(NormalizationService.java:160)
at
org.apache.ldap.server.interceptor.InterceptorChain.search(InterceptorChain.java:545)
at
org.apache.ldap.server.jndi.ContextPartitionNexusProxy.search(ContextPartitionNexusProxy.java:230)
at
org.apache.ldap.server.jndi.ServerDirContext.search(ServerDirContext.java:608)
at
org.apache.ldap.server.jndi.ServerDirContext.search(ServerDirContext.java:560)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at
org.apache.ldap.server.protocol.SearchHandler.messageReceived(SearchHandler.java:126)
at
org.apache.mina.protocol.handler.DemuxingProtocolHandler.messageReceived(DemuxingProtocolHandler.java:70)
at
org.apache.mina.protocol.AbstractProtocolFilterChain$2.messageReceived(AbstractProtocolFilterChain.java:149)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.access$1000(AbstractProtocolFilterChain.java:50)
at
org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageReceived(AbstractProtocolFilterChain.java:524)
at
org.apache.mina.protocol.AbstractProtocolFilterChain$1.messageReceived(AbstractProtocolFilterChain.java:99)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.messageReceived(AbstractProtocolFilterChain.java:356)
at
org.apache.mina.protocol.ProtocolSessionManagerFilterChain$1.messageReceived(ProtocolSessionManagerFilterChain.java:77)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.callNextMessageReceived(AbstractProtocolFilterChain.java:365)
at
org.apache.mina.protocol.AbstractProtocolFilterChain.access$1000(AbstractProtocolFilterChain.java:50)
at
org.apache.mina.protocol.AbstractProtocolFilterChain$Entry$1.messageReceived(AbstractProtocolFilterChain.java:524)
at
org.apache.mina.protocol.filter.ProtocolThreadPoolFilter.processEvent(ProtocolThreadPoolFilter.java:96)
at
org.apache.mina.util.BaseThreadPool$Worker.processEvents(BaseThreadPool.java:340)
at
org.apache.mina.util.BaseThreadPool$Worker.run(BaseThreadPool.java:279)
]; remaining name 'OU=CA'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3010)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737)
at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1291)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:213)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:121)
at
javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:133)
at
javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:128)
at context.KeystoreContext.verifyCertificate(KeystoreContext.java:217)
... 35 more
I think this is also what makes CertSore not working correctly. But this
is not assumed now...
Best regards,
Tony
Alex Karasulu a écrit :
>
> On Jul 2, 2005, at 5:57 PM, Emmanuel Lecharny wrote:
>
>> Sorry Tony, I think that there is already a JIRA entry for this :
>> http://issues.apache.org/jira/browse/DIRLDAP-35
>>
> Ditto I apologize for this as well Tony. I thought I had fixed this
> a while back. Can you perhaps tack on the stack trace you get back
> from the server so I can isolate the problem better?
>
>> Could you check if this is the same pb?
>>
> It probably is however there was another jira patch that jacob had
> submitted to fix this issue. It was due to the schema registries not
> looking up attributes in a case insensitive fashion. Perhaps this is
> only one part of the problem. The stack trace Tony gets back will
> help narrow it down even further and this should be pretty easy to fix.
>
> BTW Tony are you working with the latest code from the Trunk or with
> an older version of apacheds? If so this may be fixed in the trunk.
> Sorry I don't remember off the top of my head if I applied Jacob's
> patch.
>
> Thanks for responding quickly Emmanuel.
>
> Alex
>
>>
>> On Sat, 2005-07-02 at 20:54 +0200, Tony Blanchard wrote:
>>
>>> I all,
>>>
>>> I created a new entry like this ou=CA,ou=system and this is a pkiCA
>>> object which I use with LDAPCertStore in JDK 1.5.
>>> I have some openssl certificates which issuer DNs are "OU=CA,
>>> OU=system"
>>>
>>> The problem is that code like this does not work :
>>>
>>> Context is already created with provider_url =
>>> ldap://localhost:10389/ou=system
>>> ....
>>> Attributes lAtts = MyOpenedLdapCtx.getAttributes ("OU=CA");
>>>
>>> instead, this works:
>>> Attributes lAtts = MyOpenedLdapCtx.getAttributes ("ou=CA");
>>>
>>> Is there something I am missing or it is a bug I have to write in Jira
>>> repository ?
>>> I can not change the OU part of generated openssl certificate...
>>>
>>> Thanks for help,
>>> Tony Blanchard
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ------------------
>>> Wanadoo vous informe que cet e-mail a ete controle par l'anti-
>>> virus mail.
>>> Aucun virus connu a ce jour par nos services n'a ete detecte.
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
Re: Case sensitive question ...
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Hi,
I just fixed my problem but it seems not to be a common ldap problem but
a schema bootstrap one.
Even if my code is not made to be nice at this time, here is what work
for my test case (ie my client program had problem to search "OU=CA" and
now works fine)
$ diff BootstrapAttributeTypeRegistry.java
/cygdrive/d/tmp/BootstrapAttributeTypeRegistry.java
108,109c108,109
< id = oidRegistry.getOid( id );
<
---
> id = oidRegistry.getOid( id.toLowerCase() );//TBL
> //id = oidRegistry.getOid( id );
136a137,149
> //TBL start
> else if ( oidRegistry.hasOid( id.toLowerCase() ) )
> {
> try
> {
> return byOid.containsKey( oidRegistry.getOid(
id.toLowerCase() ) );
> }
> catch ( NamingException e )
> {
> return false;
> }
> }
> //TBL end
148a162,167
> //TBL start
> else if ( oidToSchema.containsKey( id.toLowerCase() ) )
> {
> return ( String ) oidToSchema.get( id.toLowerCase() );
> }
> //TBL end
The maps are not case insensitive...
Should I create a new issue or comment the DIRLDAP-35 ?
Cheers,
Tony
Alex Karasulu a écrit :
>
> On Jul 2, 2005, at 5:57 PM, Emmanuel Lecharny wrote:
>
>> Sorry Tony, I think that there is already a JIRA entry for this :
>> http://issues.apache.org/jira/browse/DIRLDAP-35
>>
> Ditto I apologize for this as well Tony. I thought I had fixed this
> a while back. Can you perhaps tack on the stack trace you get back
> from the server so I can isolate the problem better?
>
>> Could you check if this is the same pb?
>>
> It probably is however there was another jira patch that jacob had
> submitted to fix this issue. It was due to the schema registries not
> looking up attributes in a case insensitive fashion. Perhaps this is
> only one part of the problem. The stack trace Tony gets back will
> help narrow it down even further and this should be pretty easy to fix.
>
> BTW Tony are you working with the latest code from the Trunk or with
> an older version of apacheds? If so this may be fixed in the trunk.
> Sorry I don't remember off the top of my head if I applied Jacob's
> patch.
>
> Thanks for responding quickly Emmanuel.
>
> Alex
>
>>
>> On Sat, 2005-07-02 at 20:54 +0200, Tony Blanchard wrote:
>>
>>> I all,
>>>
>>> I created a new entry like this ou=CA,ou=system and this is a pkiCA
>>> object which I use with LDAPCertStore in JDK 1.5.
>>> I have some openssl certificates which issuer DNs are "OU=CA,
>>> OU=system"
>>>
>>> The problem is that code like this does not work :
>>>
>>> Context is already created with provider_url =
>>> ldap://localhost:10389/ou=system
>>> ....
>>> Attributes lAtts = MyOpenedLdapCtx.getAttributes ("OU=CA");
>>>
>>> instead, this works:
>>> Attributes lAtts = MyOpenedLdapCtx.getAttributes ("ou=CA");
>>>
>>> Is there something I am missing or it is a bug I have to write in Jira
>>> repository ?
>>> I can not change the OU part of generated openssl certificate...
>>>
>>> Thanks for help,
>>> Tony Blanchard
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ------------------
>>> Wanadoo vous informe que cet e-mail a ete controle par l'anti-
>>> virus mail.
>>> Aucun virus connu a ce jour par nos services n'a ete detecte.
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
Re: Case sensitive question ...
Posted by Alex Karasulu <ao...@bellsouth.net>.
On Jul 2, 2005, at 5:57 PM, Emmanuel Lecharny wrote:
> Sorry Tony, I think that there is already a JIRA entry for this :
> http://issues.apache.org/jira/browse/DIRLDAP-35
>
Ditto I apologize for this as well Tony. I thought I had fixed this
a while back. Can you perhaps tack on the stack trace you get back
from the server so I can isolate the problem better?
> Could you check if this is the same pb?
>
It probably is however there was another jira patch that jacob had
submitted to fix this issue. It was due to the schema registries not
looking up attributes in a case insensitive fashion. Perhaps this is
only one part of the problem. The stack trace Tony gets back will
help narrow it down even further and this should be pretty easy to fix.
BTW Tony are you working with the latest code from the Trunk or with
an older version of apacheds? If so this may be fixed in the trunk.
Sorry I don't remember off the top of my head if I applied Jacob's
patch.
Thanks for responding quickly Emmanuel.
Alex
>
> On Sat, 2005-07-02 at 20:54 +0200, Tony Blanchard wrote:
>
>> I all,
>>
>> I created a new entry like this ou=CA,ou=system and this is a pkiCA
>> object which I use with LDAPCertStore in JDK 1.5.
>> I have some openssl certificates which issuer DNs are "OU=CA,
>> OU=system"
>>
>> The problem is that code like this does not work :
>>
>> Context is already created with provider_url =
>> ldap://localhost:10389/ou=system
>> ....
>> Attributes lAtts = MyOpenedLdapCtx.getAttributes ("OU=CA");
>>
>> instead, this works:
>> Attributes lAtts = MyOpenedLdapCtx.getAttributes ("ou=CA");
>>
>> Is there something I am missing or it is a bug I have to write in
>> Jira
>> repository ?
>> I can not change the OU part of generated openssl certificate...
>>
>> Thanks for help,
>> Tony Blanchard
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> ------------------
>> Wanadoo vous informe que cet e-mail a ete controle par l'anti-
>> virus mail.
>> Aucun virus connu a ce jour par nos services n'a ete detecte.
>>
>>
>>
>>
>
>
>
Re: Case sensitive question ...
Posted by Emmanuel Lecharny <el...@apache.org>.
Sorry Tony, I think that there is already a JIRA entry for this :
http://issues.apache.org/jira/browse/DIRLDAP-35
Could you check if this is the same pb?
Sorry for the inconvenience, this bug is to be fixed in the next 0.9.1
version.
Emmanuel Lécharny
On Sat, 2005-07-02 at 20:54 +0200, Tony Blanchard wrote:
> I all,
>
> I created a new entry like this ou=CA,ou=system and this is a pkiCA
> object which I use with LDAPCertStore in JDK 1.5.
> I have some openssl certificates which issuer DNs are "OU=CA, OU=system"
>
> The problem is that code like this does not work :
>
> Context is already created with provider_url =
> ldap://localhost:10389/ou=system
> ....
> Attributes lAtts = MyOpenedLdapCtx.getAttributes ("OU=CA");
>
> instead, this works:
> Attributes lAtts = MyOpenedLdapCtx.getAttributes ("ou=CA");
>
> Is there something I am missing or it is a bug I have to write in Jira
> repository ?
> I can not change the OU part of generated openssl certificate...
>
> Thanks for help,
> Tony Blanchard
>
>
>
>
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>