----- "Martin Gainty" <mgai...@hotmail.com> wrote:

> it means the authentication provider does not support the
> authentication algorithm you selected

I didn't select a protocol (there is no protocol="foo" setting the Realm)

> list out the contents of your keystore

I'm not using a keystore. I just made sure that the GoDaddy certificates
are in the JVM cacerts ($JAVA_HOME/jre/lib/security/cacerts)

> http://download-llnw.oracle.com/javase/1.4.2/docs/tooldocs/windows/keytool.html

More importantly to me would be to have a tool written in Java to do an
SSL connect, so I can, without the overhead of Tomcat say that it works.

> you may be better off creating new keys and be sure you identify only
> the encryption algo the provider supports

I didn't create these keys, they were provided by GoDaddy, and work
for a multitude of services perfectly fine.

BUT:

All of that is far beside the point. As I already mentioned, wireshark
reports nothing about SSL/TLS at all:

  0.000000 188.40.115.116 -> 188.40.115.121 TCP 39360 > ldap [SYN] Seq=0 
Win=5840 Len=0 MSS=1460 TSV=1140509975 TSER=0 WS=7
  0.000000 188.40.115.121 -> 188.40.115.116 TCP ldap > 39360 [SYN, ACK] Seq=0 
Ack=1 Win=5792 Len=0 MSS=1460 TSV=49062377 TSER=1140509975 WS=7
  0.000000 188.40.115.116 -> 188.40.115.121 TCP 39360 > ldap [ACK] Seq=1 Ack=1 
Win=5888 Len=0 TSV=1140509975 TSER=49062377
  0.004000 188.40.115.116 -> 188.40.115.121 LDAP bindRequest(1) "uid=whatever" 
simple 
  0.004000 188.40.115.121 -> 188.40.115.116 TCP ldap > 39360 [ACK] Seq=1 Ack=54 
Win=5888 Len=0 TSV=49062378 TSER=1140509976
  0.004000 188.40.115.121 -> 188.40.115.116 LDAP bindResponse(1) 
confidentialityRequired (confidentiality required) 
  0.004000 188.40.115.116 -> 188.40.115.121 TCP 39360 > ldap [ACK] Seq=54 
Ack=39 Win=5888 Len=0 TSV=1140509976 TSER=49062378
  0.008000 188.40.115.116 -> 188.40.115.121 TCP 39360 > ldap [FIN, ACK] Seq=54 
Ack=39 Win=5888 Len=0 TSV=1140509977 TSER=49062378
  0.008000 188.40.115.121 -> 188.40.115.116 TCP ldap > 39360 [FIN, ACK] Seq=39 
Ack=55 Win=5888 Len=0 TSV=49062379 TSER=1140509977
  0.008000 188.40.115.116 -> 188.40.115.121 TCP 39360 > ldap [ACK] Seq=55 
Ack=40 Win=5888 Len=0 TSV=1140509977 TSER=49062379


There's no SASL negotiation taking place, so we're far away from a TLS
negotiation. (You can find the capture for the above transcript attatched)

I would still like to believe that this is a simple configuration error from
my side. That I have to tell Tomcat use StartTLS, use SASL - but none
of the documentation gives a hint about that.


So long,
i

> Martin Gainty 
> ______________________________________________ 
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de
> confidentialité
> 
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig.
> Diese Nachricht dient lediglich dem Austausch von Informationen und
> entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten
> Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den
> Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes
> pas le destinataire prévu, nous te demandons avec bonté que pour
> satisfaire informez l'expéditeur. N'importe quelle diffusion non
> autorisée ou la copie de ceci est interdite. Ce message sert à
> l'information seulement et n'aura pas n'importe quel effet légalement
> obligatoire. Étant donné que les email peuvent facilement être sujets
> à la manipulation, nous ne pouvons accepter aucune responsabilité pour
> le contenu fourni.
> 
> 
> 
>  
> 
> > Date: Sun, 15 Aug 2010 14:14:55 +0000
> > From: i.ga...@brainsware.org
> > To: users@tomcat.apache.org
> > Subject: JNDI: LDAPv3 with StartTLS
> > 
> > 
> > Hi folks,
> > 
> > I'm running Hudson in Tomcat 6.0.29 on Debian/Squeeze/amd64 with 
> > 
> > i.ga...@pheme /opt/tomcat6 % java -version
> > java version "1.6.0_18"
> > OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-1)
> > OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
> > 
> > I'm starting the server with:
> > CATALINA_OPTS-"-Djava.awt.headless=true
> -Djavax.net.debug=ssl:handshake
> -DHUDSON_HOME=${CATALINA_HOME}/webapps/hudson -Xmx512m"
> > 
> > In server.xml's Engine context there is a single JNDI Realm
> configured:
> > 
> > <Engine name="Catalina" defaultHost="localhost">
> > 
> > <Realm className="org.apache.catalina.realm.JNDIRealm"
> > connectionURL="ldap://mail.brainsware.org:389/";
> > alternateURL="ldap://mail.esotericsystems.at:389";
> > commonRole="admin" connectionName="uid=whatever"
> connectionPassword="securityisgreat."
> > userBase="ou=people,dc=brainsware,dc=org"
> userPattern="(uid={0})(postOfficeBox=internal_projects)"
> > userSearch="(uid={0})" />
> > 
> > The LDAP server I'm connecting to is Zimbra (OpenLDAP), and requires
> StartTLS. It has a valid Certificate, signed by Go Daddy.
> > I've made sure that all parts of Go Daddy's chain are in the JVM's
> cacerts.
> > 
> > When starting the server, I see this in the log:
> > 
> > INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
> > Aug 15, 2010 2:04:18 PM org.apache.catalina.realm.JNDIRealm open
> > WARNING: Exception performing authentication
> > javax.naming.AuthenticationNotSupportedException: [LDAP: error code
> 13 - confidentiality required]
> > at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3023)
> > at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2978)
> > at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2780)
> > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2694)
> > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:306)
> > at
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)
> > at
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)
> > at
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
> > at
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
> > at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> > at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
> > at javax.naming.InitialContext.init(InitialContext.java:240)
> > at javax.naming.InitialContext.<init>(InitialContext.java:214)
> > at
> javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:99)
> > at org.apache.catalina.realm.JNDIRealm.open(JNDIRealm.java:1954)
> > at org.apache.catalina.realm.JNDIRealm.start(JNDIRealm.java:2045)
> > at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1037)
> > at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
> > at
> org.apache.catalina.core.StandardService.start(StandardService.java:519)
> > at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
> > at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:616)
> > at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
> > 
> > 
> > I've traced the operation with wireshark only to find it's not even
> trying to do any kind of SASL negotiation.
> > That seems weird, since:
> >
> http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-com.sun/jndi/com/sun/jndi/ldap/LdapClient.java.htm
> > suggests it should be doing that by default.
> > 
> > I'm out ideas now. and welcome any advise you can offer.
> > 
> > So long o/~
> > -- 
> > Igor Galić
> > 
> > Tel: +43 (0) 664 886 22 883
> > Mail: i.ga...@brainsware.org
> > URL: http://brainsware.org/
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >

Attachment: tomcat.jndi.ldap.cap
Description: application/cap

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to