15 nov 2010 kl. 00.01 skrev Joel Carnat:
> -----Message initial-----
> @: Joel Carnat <[email protected]>;
> Cc: [email protected];
> De: Philip Guenther <[email protected]>
> Envoyi: dim. 14-11-2010 02:25
> Sujet: Re: ldapd and self-signed certificate
>> On Sat, Nov 13, 2010 at 12:02 PM, Joel Carnat <[email protected]> wrote:
>>> I want to use LDAP to store postfix, apache and dovecot users.
>>> This sounds a quite simple need so I plan to use the native ldapd.
>> ...
>>> Then I created a self-signed certificate in /etc/ldap/ using directions
> from
>>> starttls(8).
>>> The ldapd starts and listens to ldap and ldaps ports.
>>> But when I run: # ldapmodify -x -H ldaps://ldapd.tumfatig.local -D
>>> "cn=admin,dc=tumfatig,dc=local" -W -f /tmp/tumfatig
>>> I get: "additional info: error:14090086:SSL
>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"
>>> The ldapd (in debug mode) says: "SSL library error: ssl_session_accept:
>>> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca"
>>>
>>> Can I use ldapd with self-signed certificate ?
>>> Did I miss a step ?
>>
>> There are two aspects to verifying a cert:
>> 1) does it have a valid signature?
>> 2) is the CA that signed this trustable at all?
>>
>> The point of this is to know whether you can trust the contents of the
>> cert so that you're protected from Man-in-the-Middle attacks. If you
>> accepted any self-signed cert then anyone could generate a cert that
>> claimed to be your server, then splice your TCP connection and snoop
>> and modify all your data.
>>
>> So, you need some way to know which certs to trust; that's where #1
>> and #2 come in. #1 validates that this cert can be traced back to a
>> particular CA, while #2 is where you decide whether that CA is okay.
>> #1 is done automatically by the OpenSSL code; #2 is done by putting
>> all the CAs you want to trust in location(s) that OpenSSL checks.
>>
>> For a self-signed cert, step #1 is basically trivial, while #2 is done
>> by either putting a link to the cert in /etc/ssl/certs/ with a name
>> that's derived from a hash of the cert's subject, or adding the cert
>> itself to /etc/ssl/cert.pem. The latter is easy but you may find it
>> cluttered. To do the former, do something like:
>> cert_file=/absolute/path/to/the/cert.pem
>> ln -s $cert_file /etc/ssl/certs/`openssl x509 -noout -in
>> $cert_file -subject_hash`.0
>>
>> Note that /etc/ssl/cert* are the default trust paths for practically
>> all openssl-based apps, so a cert added there will be trusted for lots
>> of things. If you don't like that idea then you'll need to look at
>> how to set the CA paths for the apps you want to trust that cert.
>> That's fairly specific to the involved app. starttls(8) describes the
>> settings for sendmail, ldap.conf(5) describes it for the OpenLDAP
>> libldap and clients, etc.
>>
>>
>> Philip Guenther
>>
>
> Thank you for this detailed explanation.
>
> For the moment, I just testing things in a "closed" environment.
> This is why I used self-signed certificates. In a "real" environment, I
> would go with certificates signed by publicly known CA.
>
> I did try creating /etc/ssl/certs and linking my self-signed certificates
> as you describe. But that doesn't seem to work neither.
>
> I also took one of my certificates, signed by a publicly know CA but I
> still got the same message... I checked the certificate and it contains
> the path to the CA.
>
> But I still get the "tlsv1 alert unknown ca" error :(
As Philip pointed out, you can specify the trusted CA certificate (or the
certificate itself in case of self-signed certs) as specified in ldap.conf(5),
provided you are using OpenLDAP.
Try this in you ~/ldaprc:
TLS_CACERT /path/to/ldapd.crt
-martin
