[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Different TLSVerifyClient possible?
Hi,
Martin Lesser <admin-openldap@better-com.de> writes:
> Dieter Kluenter <dieter@dkluenter.de> writes:
>> Martin Lesser <admin-openldap@better-com.de> writes:
>> > For the slapd running on 127.0.0.1 I want to reduce TLSVerifyClient to
>> > never so only the slapd serving the external adress strictly depends on
>> > a valid client-cert. Otherwise I had to generate a client-cert for each
>> > local service which uses ldap.
>> Set TLSVerifyClient allow in slapd.conf and TLS_REQCERT try in your
>> hosts /etc/openldap/ldap.conf. Thus you only have to generate
>> client-certs for each host and not for each service.
>
> I don't think that would solve the problem: With 'TLSVerifyClient allow'
> also clients which don't have a valid cert are able to connect. On the
> external interface this it what I don't want - under no
> circumstances. Furthermore I want that invalid external connections are
> terminated as early as possible, a failing handshake would do that.
>
> I try to achieve two - perhaps contradictory - goals:
>
> 1. All _local_ users or services should be able to get all informations
> they need from local slapd without (resource consuming) encryption
> enforced.
>
> 2. All _remote_ users must present a valid cert.
>
> Partially I could solve it by applying appropriate ssf-rules to
> slapd.conf or the acl's but at least this would break goal #1.
>
> Did I overlook something?
The intention of TLS is to be under client control, that is, the
client has to verify the server certificate. If you set 'TLS_REQCERT
try', the client will verify the server certificate and will terminate
on a bad certificate, but will continue if no certificate is
presented. But you could set 'TLS_REQCERT demand', thus the
session will be terminated on a bad certificate and on presenting no
server certificate.
-Dieter
--
Dieter Kluenter | Systemberatung
Tel:040.64861967 | Fax: 040.64891521
mailto: dkluenter(at)dkluenter.de
http://www.avci.de