[jira] Commented: (GERONIMO-3812) Geronimo 2.0.2 misses ApacheDS (LDAP) function
[ https://issues.apache.org/jira/browse/GERONIMO-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566134#action_12566134 ] Sakari Maaranen commented on GERONIMO-3812: --- I solved the problem that was caused by missing configuration of trusted certificate authorities with the LDAP security realm. First, using Geronimo keystore tools, I created a new keystore and a private key in it. I signed it using Geronimo CA. Lastly I added my Geronimo CA certificate as a trusted certificate in the same keystore. I copied that keystore to ApacheDS and configured LDAPS with that. The "original" copy of the same keystore still remains in the Geronimo var/security/keystores/ directory. Before starting Geronimo I did the following: JAVA_OPTS="-Djavax.net.ssl.trustStore=/var/security/keystores/ -Djavax.net.ssl.trustStorePassword=" export JAVA_OPTS cd bin/geronimo.sh start Now I have fully configured ApacheDS 1.0.2 standalone LDAPS with Geronimo 2.0.2. Not sure if using JAVA_OPTS is the best place for this configuration though. Geronimo should have way of setting the trusted certificate authorities keystore from the web console. > Geronimo 2.0.2 misses ApacheDS (LDAP) function > -- > > Key: GERONIMO-3812 > URL: https://issues.apache.org/jira/browse/GERONIMO-3812 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: documentation, Plugins >Affects Versions: 2.0.2 > Environment: Debian Linux, java version "1.5.0_14", > geronimo-tomcat6-jee5-2.0.2 >Reporter: Sakari Maaranen > > Geronimo documentation at > http://cwiki.apache.org/GMOxDOC20/ldap-sample-application.html talks about > org.apache.geronimo.configs/directory in system modules, but that does not > exist in Geronimo 2.0.2. > There is also a reference to Geronimo plugins. However, when I go to Plugins > in the Geronimo console and search the geronimo-2.0.2 reposityory there is > nothing related to ApacheDS or Directory. Like if the ApacheDS function was > completely missing. > The ApacheDS plugin should be added to the 2.0.2 plugin repository. The > documentation should be updated to give the steps how to install ApacheDS > with or without the plugin. The LDAP demo is useless if ApacheDS is > unavailable. > I found this much earlier discussion on the topic: > http://www.mail-archive.com/[email protected]/msg52749.html > http://www.mail-archive.com/[email protected]/msg55148.html > Frankly, I don't think that the forward compatibility is so much an issue, > but 2.0.2 completely lacking LDAP server. Would be better have it, even > without forward compatibility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3812) Geronimo 2.0.2 misses ApacheDS (LDAP) function
[ https://issues.apache.org/jira/browse/GERONIMO-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566123#action_12566123 ] Sakari Maaranen commented on GERONIMO-3812: --- I also created a LDAP security realm with LDAPS URL and SSL protocol. This gives the following errors in geronimo.log: 2008-02-06 07:51:36,080 WARN SecurityRealmPortlet: Test login failed javax.security.auth.login.LoginException: LDAP Error at org.apache.geronimo.security.realm.providers.LDAPLoginModule.login(LDAPLoginModule.java:161) at org.apache.geronimo.console.util.KernelManagementHelper.testLoginModule(KernelManagementHelper.java:423) at org.apache.geronimo.console.util.PortletManager.testLoginModule(PortletManager.java:168) at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.actionAttemptLogin(SecurityRealmPortlet.java:340) at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.processAction(SecurityRealmPortlet.java:221) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) ... at java.lang.Thread.run(Thread.java:595) Caused by: javax.naming.CommunicationException: simple bind failed: localhost:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:197) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2637) at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:283) ... Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1584) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174) ... Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221) at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:145) at sun.security.validator.Validator.validate(Validator.java:203) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172) ... Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:236) at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194) at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216) ... I think it means that some way of setting up trusted certificates for LDAP security realms is needed. Otherwise Geronimo cannot connect to LDAPS, because it cannot trust the LDAPS certificate. > Geronimo 2.0.2 misses ApacheDS (LDAP) function > -- > > Key: GERONIMO-3812 > URL: https://issues.apache.org/jira/browse/GERONIMO-3812 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: documentation, Plugins >Affects Versions: 2.0.2 > Environment: Debian Linux, java version "1.5.0_14", > geronimo-tomcat6-jee5-2.0.2 >Reporter: Sakari Maaranen > > Geronimo documentation at > http://cwiki.apache.org/GMOxDOC20/ldap-sample-application.html talks about > org.apache.geronimo.configs/directory in system modules, but that does not > exist in Geronimo 2.0.2. > There is also a reference to Geronimo plugins. However, when I go to Plugins > in the Geronimo console and search the geronimo-2.0.2 reposityory there is > nothing related to ApacheDS or Directory. Like if the ApacheDS function was > completely missing. > The ApacheDS plugin should be added to the 2.0.2 plugin repository. The > documentation should be updated to give the steps how to install ApacheDS > with or without the plugin. The LDAP demo is useless if ApacheDS is > unavailable. > I found this much earlier discussion on the topic: > http://www.mail-archive.com/[email protected]/msg52749.html > http://www.mail-archive.com/[email protected]
[jira] Commented: (GERONIMO-3812) Geronimo 2.0.2 misses ApacheDS (LDAP) function
[ https://issues.apache.org/jira/browse/GERONIMO-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566035#action_12566035 ] Sakari Maaranen commented on GERONIMO-3812: --- I worked around this issue by installing the ApacheDS 1.0.2 standalone. This configuration I am using now probably takes up a little more RAM and requires extra management work. Also, I couldn't get LDAPS working with the Geronimo LDAP Viewer. The Viewer does work with regular LDAP. There must be some problem with selecting the keystore for the Geronimo LDAP application, because I keep getting the following exception in the ApacheDS standalone log: /usr/local/apacheds-1.0.2/var/log/apacheds-stdout.log 2008-02-05 17:46:36,132 WARN org.apache.directory.server.ldap.LdapProtocolProvider$LdapProtocolHandler: [/127.0.0.1:57424] Unexpected exception forcing session to close: sending disconnect notice to client. javax.net.ssl.SSLHandshakeException: Initial SSL handshake failed. at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:425) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362) at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54) at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800) at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:243) at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:305) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:166) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1356) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1324) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1486) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:961) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:787) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:663) at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:566) at org.apache.mina.filter.support.SSLHandler.unwrapHandshake(SSLHandler.java:677) at org.apache.mina.filter.support.SSLHandler.handshake(SSLHandler.java:494) at org.apache.mina.filter.support.SSLHandler.messageReceived(SSLHandler.java:293) at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:393) ... 8 more I am not sure, but to me it seems that when trying to connect, the Geronimo LDAP Viewer does not recognize the ApacheDS LDAPS certificate. The above message is in the ApacheDS log, but I guess this certificate_unknown alert originates from Geronimo? Any advice on how to set the keystore and trusted certificates for the Geronimo LDAP Viewer to connect to a LDAPS enabled standalone server is welcome! My ApacheDS 1.0.2 LDAPS server is working correctly and I verified that by connecting to it with the Eclipse Apache Directory Studio tools. Only the above problem still persists with the Geronimo LDAP Viewer. Especially if this bug is not going to be fixed, it would be great to at least have a good workaround documented here. > Geronimo 2.0.2 misses ApacheDS (LDAP) function > -- > > Key: GERONIMO-3812 > URL: https://issues.apache.org/jira/browse/GERONIMO-3812 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: documentation, Plugins >Affects Versions: 2.0.2 > Environment: Debian Linux, java version "1.5.0_14", > geronimo-tomcat6-jee5-2.0.2 >Reporter: Sakari Maaranen > > Geronimo documentation at > http://cwiki.apache.org/GMOxDOC20/ldap-sample-application.html talks about > org.apache.geronimo.configs/directory in system modules, but that does not > exist in Geronimo 2.0.2. > There is also a reference to Geronimo plugins. However, when I go to Plugins > in the Geronimo console and search the geronimo-2.0.2 reposityory there is > nothing related to ApacheDS or Directory. Like if the ApacheDS function was > completely missing. > The ApacheDS plugin should be added to the 2.0.2 plugin repository. The > documentation should be updated to give the steps how to install ApacheDS
[jira] Commented: (GERONIMO-3812) Geronimo 2.0.2 misses ApacheDS (LDAP) function
[ https://issues.apache.org/jira/browse/GERONIMO-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565827#action_12565827 ] David Jencks commented on GERONIMO-3812: There's a plugin that once worked with a prerelease geronimo 2.0.x and apacheds 1.5.x at https://svn.apache.org/repos/asf/geronimo/plugins/directory/branches/2.0 I'm afraid I've concentrated on improving the geronimo plugin system and improving the structure of apacheds and lost sight of the goal of releasing something working for 2.0.2. Realistically I won't have time for working towards that but I'll try to give advice if someone else wants to work on it. > Geronimo 2.0.2 misses ApacheDS (LDAP) function > -- > > Key: GERONIMO-3812 > URL: https://issues.apache.org/jira/browse/GERONIMO-3812 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: documentation, Plugins >Affects Versions: 2.0.2 > Environment: Debian Linux, java version "1.5.0_14", > geronimo-tomcat6-jee5-2.0.2 >Reporter: Sakari Maaranen > > Geronimo documentation at > http://cwiki.apache.org/GMOxDOC20/ldap-sample-application.html talks about > org.apache.geronimo.configs/directory in system modules, but that does not > exist in Geronimo 2.0.2. > There is also a reference to Geronimo plugins. However, when I go to Plugins > in the Geronimo console and search the geronimo-2.0.2 reposityory there is > nothing related to ApacheDS or Directory. Like if the ApacheDS function was > completely missing. > The ApacheDS plugin should be added to the 2.0.2 plugin repository. The > documentation should be updated to give the steps how to install ApacheDS > with or without the plugin. The LDAP demo is useless if ApacheDS is > unavailable. > I found this much earlier discussion on the topic: > http://www.mail-archive.com/[email protected]/msg52749.html > http://www.mail-archive.com/[email protected]/msg55148.html > Frankly, I don't think that the forward compatibility is so much an issue, > but 2.0.2 completely lacking LDAP server. Would be better have it, even > without forward compatibility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
