Our requirement is that we need to test if a server certificate from Openldap server is valid and then upload to our trust store and use the certificate for further communications using SSL to the ldap server. I configured Openldap for SSL as per the Openldap admin guide - generated the 3 certificates cacert.pem,servercert.pem and serverkey.pem and put the corresponding entries in slapd.conf file. My assumption is cacert.pem is the file for the CA,servercert.pem is the server certificate file(?!) and the serverkey.pem is the file containing the private key to the server. After configuring my client ldap.conf file to point to cacert.pem as per the following directives -
TLS_CACERTDIR <path to my cacert.pem file> TLS_REQCERT hard
I was able to execute an ldapsearch command successfully. My problem is that after adding cacert.pem to my truststore, I am unable to use the certificate in java using SSL. I get the following exception -
javax.naming.CommunicationException: simple bind failed: vcheung-181.lab.xxxx.net:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Netscape cert type does not permit use for SSL server] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:197) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2658) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:287) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.<init>(InitialContext.java:197) at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82) at com.xxxx.analyst.manager.database.LDAPSchemaTest.areAllAttributesPresent(LDAPSchemaTest.java:84) at com.xxxx.analyst.presentation.action.ReCreateDomainAction.doAttributeCheck(ReCreateDomainAction.java :249) at com.xxxx.analyst.presentation.action.ReCreateDomainAction.execute(ReCreateDomainAction.java:182) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.xxxx.util.ReLiveUserFilter.doFilter(ReLiveUserFilter.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.xxxx.analyst.util.ReAccessFilter.doFilter(ReAccessFilter.java:191) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.jav a:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:619)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Netscape cert type does not permit use for SSL server at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:975) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:123) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:393) at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:334) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:192) ... 47 more
I googled for the above exception and from what I got, I thought I had to configure for a client certificate but we have to test the server certificate for validity not the client certificate. I am not sure I am following the procedure correctly. My question is - Is servercert.pem the file that I need to use as server certificate. How can I validate it(I mean make sure that it is a valid server certificate file)? (Pointing to the servercert.pem file in ldap.conf gave me an error) -
ldap_create ldap_url_parse_ext(ldaps://vcheung-181.lab.xxxx.net:636) ldap_bind_s ldap_simple_bind_s ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP vcheung-181.lab.xxxx.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.25.4.181:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=California/O=yyyy/OU=yyyy/CN=vcheung-181.lab.xxxx.net, issuer: /C=US/ST=California/O=yyyy/OU=yyyy/CN=vcheung-181.lab.xxxx.net TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect. ldap_perror ldap_bind: Can't contact LDAP server (-1)
Is there some other directive in ldap.conf file which points to this file (
I thought only 3 valid directives are present TLS_CACERTDIR,TLS_CACERT,TLS_REQCERT). There were other directives TLS_CERT
- but these point to the client certificate.
Thanks
Sirisha.
s g sirisha.kmb@gmail.com writes:
Our requirement is that we need to test if a server certificate from Openldap server is valid and then upload to our trust store and use the certificate for further communications using SSL to the ldap server. I configured Openldap for SSL as per the Openldap admin guide - generated the 3 certificates cacert.pem,servercert.pem and serverkey.pem and put the corresponding entries in slapd.conf file. My assumption is cacert.pem is the file for the CA,servercert.pem is the server certificate file(?!) and the serverkey.pem is the file containing the private key to the server. After configuring my client ldap.conf file to point to cacert.pem as per the following directives - TLS_CACERTDIR <path to my cacert.pem file> TLS_REQCERT hard
[...]
I would recommend to use TLS_CACERT <path to cacert.pem> The parameter CACERTDIR requires the CA's in this directory to be hashed.
-Dieter
On Fri, May 28, 2010 at 9:39 AM, s g sirisha.kmb@gmail.com wrote:
javax.naming.CommunicationException: simple bind failed: vcheung-181.lab.xxxx.net:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Netscape cert type does not permit use for SSL server] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:197) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2658) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:287)
You probably have your certs round the wrong way. The server cert (on the ldap server) should have 'SSL Server' usage flag the client cert (on the ldap client) should have 'SSL Client' usage flag.
The usage flags are embedded when you make the csr (certificate request) which will then usually be reflected in the generated certificate, unless your CA overrides them.
Do a "openssl x509 -in <cert file> -noout -text" to compare the two certificates.
Cheers Brett
Thanks for replying. I was a bit occupied, so I could not back soon. Going by your mail, I went through the certificate generation process again. What I found is that for some reason, the cacert.pem file(which is the certificate for the CA) shows the following - X509v3 extensions: X509v3 Basic Constraints: CA:FALSE I am attaching the steps I followed and the certificate files generated as per the tutorial http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html#4.2.
Shouldn't the above field be CA:true? Also, how do I make sure that the flag that you mentioned below gets set to "SSL server". Thanks, Sirisha.
On Fri, May 28, 2010 at 11:44 PM, Brett @Google brett.maxfield@gmail.comwrote:
On Fri, May 28, 2010 at 9:39 AM, s g sirisha.kmb@gmail.com wrote:
javax.naming.CommunicationException: simple bind failed: vcheung-181.lab.xxxx.net:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Netscape cert type does not permit use for SSL server] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:197) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2658) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:287)
You probably have your certs round the wrong way. The server cert (on the ldap server) should have 'SSL Server' usage flag the client cert (on the ldap client) should have 'SSL Client' usage flag.
The usage flags are embedded when you make the csr (certificate request) which will then usually be reflected in the generated certificate, unless your CA overrides them.
Do a "openssl x509 -in <cert file> -noout -text" to compare the two certificates.
Cheers Brett
s g sirisha.kmb@gmail.com writes:
Thanks for replying. I was a bit occupied, so I could not back soon. Going by your mail, I went through the certificate generation process again. What I found is that for some reason, the cacert.pem file (which is the certificate for the CA) shows the following - X509v3 extensions: X509v3 Basic Constraints: CA:FALSE I am attaching the steps I followed and the certificate files generated as per the tutorial http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html#4.2.
Did you read the note on top of this paper?
Shouldn't the above field be CA:true? Also, how do I make sure that the flag that you mentioned below gets set to "SSL server".
edit openssl.cnf accordingly, or use tinyCA to create a certificate chain http://tinyca.sm-zone.net/index.html
-Dieter
openldap-technical@openldap.org
-
Brett ＠Google -
Dieter Kluenter -
s g