You’re on the right track, but I’d make a couple of adjustments.
1- Do use your eDir CA trusted root cert, consider using the “LDAPVerifyServerCert OFF” global directive so Apache doesn’t try to resolve the cert signing chain as it would a globally published cert, such as from Verisign or Go Daddy for example.
2- Convert your “dgw-edir.der” certificate (assuming this is your eDir trusted root cert) from the “.der” format to a “pem” formatted cert. The .der file should work with the Novell LDAP SDK being present, but just eliminate the possibly of something being wrong in this stack by using a cert format all OpenLDAP stacks will understand. www.sslshopper.com can handle this for you easily (specifically, http://www.sslshopper.com/ssl-certificate-tools.html ). It’s what I do and I usually use a .crt extension, but it really doesn’t matter
3- To simplify your configuration consider using the “LDAPTrustedMode SSL” global directive and the “ldaps://” format in your “AuthLDAPURL” directive. TLS connections have different nuances and require more configuration effort and assessment to identify working configurations. Ensure SSL is working, simply, before implementing TLS if needed.
4- Lose the port specification in your AuthLDAPURL directive. Technically it should work but the directive understands ldap (unsecure and TLS secured) and ldaps on the standard ports of 389 and 636 respectively. Simple is better and only specify ports that are non-standard as best practice.
5- Lose the “AuthzLDAPAuthoritative on” directive as it’s on by default (again, simple is better). I include it in presentations for demonstrative purposes only. Basically with it on Apache will not fall back to other authentication criteria (like local databases or htaccess files) if LDAP auth fails.
6- Lose the “AuthBasicAuthoritative off” directive … if you’re only using LDAP authentication than the "“AuthzLDAPAuthoritative” directive has you covered
7- Use DSTrace in your eDir environment to see what’s being talked about at your eDir LDAP server
8- Finally, if necessary use the ldapsearch util on the SLES server to test LDAP connections to the eDir backend. Ensure the “/etc/openldap/ldap.conf” file is configured with the same global SSL parameters. This file is used by LDAP clients on the server whereas the “/etc/ldap.conf” is used by the server and Apache, for example. Try using the “LDAPTLS_CACERT=” directive preceding the ldapsearch command line (but on the same command line seperated by a space) if you don’t want to modify the “/etc/openldap/ldap.conf” file.
This can be a busy tool to use but it’s the troubleshooting scalpel you’ll need to get accurate insight into what is or isn’t happening with your LDAP backend.
From what I’ve seen so far this should be enough to help get your basic configuration going. Do consider that once it is working consider there may be more to do. Can or should you use TLS instead of SSL ? Can you optimise the configuration further ? Can or should you implement more granular authorisation security (group membership or other attribute value validation) ?
Let us know how it goes and how we can help further … Have alot of fun …