Try something like this: /usr/local/libexec/slapd -u ldap -h "ldap:// ldaps://" Geert -----Original Message----- From: openldap-software-bounces+geert.van.muylem=skynet.be(a)OpenLDAP.org [mailto:openldap-software-bounces+geert.van.muylem=skynet.be@OpenLDAP.org] On Behalf Of Rob Tanner Sent: dinsdag 31 oktober 2006 1:39 To: openldap-software(a)openldap.org Subject: OpenLDAP configured for TLS not listenting on port 636 I am just now venturing for the first time into using SSL with OpenLDAP. The principal problem (or at least the first symptom of the problem) is that the server is listening only on port 389 and not 636 (according to netstat) OpenLDAP was built with the '--with-tls' configuration parameter. While I intend get a regular certificate, for testing purposes I created my own certificate using CA.pl. I copied the output files to where I want to keep them and added the additional configuration info to slapd.conf: TLSCertificateFile /usr/local/etc/openldap/Certs/newcert.pem TLSCertificateKeyFile /usr/local/etc/openldap/Certs/newkey.pem When I start OpenLDAP, I'm prompted to enter the PEM pass phrase. A ps command confirms that the start-up script did the right thing: /usr/local/libexec/slapd -u ldap -h ldap:/// ldaps:/// But ssl connections fail and a netstat command only shows the server listening on port 389. Is there something I'm missing at this point merely to get the server listening on port 636? Thanks. -- Rob Tanner UNIX Services Manager Linfield College, McMinnville OR

I always use the following command: # slapd -h "ldap://:389 ldaps://:636" Regards, Phillip On Tue, 2006-10-31 at 07:53 +0100, Geert Van Muylem wrote:

Dieter, The quotes are for the shell so that "ldap:/// ldaps:///" are not broken into two hunks by shell. They won't show up in a "ps" command because they're not passed (and aren't supposed to be passed) to slapd. Thanks to some help from Geert Van Muylen, I found the source of the problem in the startup script and fixed it. It will take me a while to actually understand the failure mechanism, but since I could pinpoint it, I was able to successfully work around it. -- Rob On 10/30/2006 11:47 PM, Dieter Kluenter wrote: