Rich Megginson wrote: > Do you need to use cert based auth? If not, just configure the > application to not use cert. based auth - just use username/password > auth over SSL (or TLS). If you must use cert. based auth, you may be > able to use the certutil command to change the trust flags of the cert > - see certutil -H. See also this page for information about cert. > based auth - http://directory.fedoraproject.org/wiki/Howto:CertMapping Hmm, this has given me an idea for a solution. After switching Encryption -> Client Authentication settings of dirsrv from "Allow client authentication" to "Do not allow client authentication" I got this working. It seems that whenever certificate authentication is an allowed possibility on the FDS server side, OpenLDAP client tries using it even if it is operating inside an OpenLDAP server environment (in which case it supplies its server certificate as client's - thus the problem). This case is special since OpenLDAP server acts as an LDAP client to FDS server. I think the problem is on OpenLDAP side (it shouldn't use its server certificate for client authentication when acting as an LDAP client). >> Like, say some tweaks in nss.conf? > NSS (Netscape^H^H^H^H^Hwork Security Services) for crypto and nss > (name switch service - as in nss_ldap) are completely different and > unfortunately share the same name. Read carefully: I wasn't talking about nsswitch.conf (which is for Name Service Switch), but nss.conf (which is a config file for mod_nss which is based on Network Secirity Services library). The FDS admin server (dirsrv-admin) is based on Apache and it uses mod_nss for handling SSL connections. So inside /etc/dirsrv/admin-serv/nss.conf you can tweak SSL-related behaviour of dirsrv-admin. I thought that there might be a similar method to tweak behaviour of dirsrv (although not through nss.conf since dirsrv doesn't use mod_nss and doesn't contain a http server in any part ), like some undocumented setting in dse.ldif. However, more correct fix turned out to be disallow certificate-based client authentication. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl -- Aleksander Adamowski Administrator system?w korporacyjnych; Instruktor Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Ch?odna 51 tel. brak kom. +48 601-318-080 S?d Rejonowy dla m.st. Warszawy w Warszawie, XII Wydzia? Gospodarczy Krajowego Rejestru S?dowego, KRS: 0000120139, NIP 118-00-08-391, Kapita? zak?adowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomo?? zawiera informacje zastrze?one i stanowi?ce tajemnic? przedsi?biorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do w?asnych cel?w jest zabronione. Je?eli otrzymali?cie Pa?stwo niniejsz? wiadomo?? omy?kowo, prosimy o niezw?oczne skontaktowanie si? z nadawc? oraz usuni?cie wszelkich kopii niniejszej wiadomo?ci. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message.
