-----Message initial----- @: Joel Carnat <j...@carnat.net>; Cc: misc@openbsd.org; De: Philip Guenther <guent...@gmail.com> 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 <j...@carnat.net> 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 :( Joel Carnat
