Hallo Liste (hallo Dieter Klünter ;-)), habe die Verschlüsselung in Openldap nach Dieters Buch vorbereitet und in /etc/openldap/slapd.conf auch die drei Zeilen TLSCertificateFile /etc/openldap/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ldapkey.pem TLSCACertificateFile /etc/openldap/cacert.pem eingefügt. Die Zertifikate sind mit CA.pl -verify überprüft -> OK. In /etc/sysconfig/openldap ist OPENLDAP_START_LDAPS="yes" eingestellt. Seltsamerweise lässt der LDAP-Server aber immer noch über Port 389 unverschlüsselte Verbindungen zu. Über Port 636 bekomme ich dagegen z.B. mit dem Programm Ldapadmin _keine_ Verbindung. openssl s_client -connect localhost:636 -showcerts zeigt auf dem LDAP-Server die Zertifikate und als letzte Zeile "Verify return code: 21 (unable to verify the first certificate)" Ich nehme aber an, das kommt vom "Self signed certificate". Jetzt die Frage: wie kann ich meinen LDAP-Server überreden dass er nur noch sichere Verbindungen zulässt und auch die "SSL secured connection"? (oder liegt's am Client)? Viele Grüsse Joachim
Hallo Joachim, Joachim Kieferle <joakie@architektur.fh-wiesbaden.de> writes:
Hallo Liste (hallo Dieter Klünter ;-)),
habe die Verschlüsselung in Openldap nach Dieters Buch vorbereitet und in /etc/openldap/slapd.conf auch die drei Zeilen TLSCertificateFile /etc/openldap/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ldapkey.pem TLSCACertificateFile /etc/openldap/cacert.pem eingefügt.
Die Zertifikate sind mit CA.pl -verify überprüft -> OK.
In /etc/sysconfig/openldap ist OPENLDAP_START_LDAPS="yes" eingestellt.
Seltsamerweise lässt der LDAP-Server aber immer noch über Port 389 unverschlüsselte Verbindungen zu.
Das ist der große Unterschied zwischen SSL und TLS :-) Auf Port 389 muss der Client die Verschlüsselung mit der Funktion ldap_start_tls initiieren, über Port 636 stellt der Server sofort eine verschlüsselte Verbindung her und der Client muss das Zertifikat prüfen oder ungeprüft übernehmen.
Über Port 636 bekomme ich dagegen z.B. mit dem Programm Ldapadmin _keine_ Verbindung.
Wie ist denn ldapadmin konfiguriert?
openssl s_client -connect localhost:636 -showcerts zeigt auf dem LDAP-Server die Zertifikate und als letzte Zeile "Verify return code: 21 (unable to verify the first certificate)"
Ich nehme aber an, das kommt vom "Self signed certificate".
Das liegt möglicherweise auch daran, dass der Client nicht den Pfad auf das cacert.pem kennt, hast du denn die entsprechenden Einträge in /etc/openldap/ldap.conf gemacht?
Jetzt die Frage: wie kann ich meinen LDAP-Server überreden dass er nur noch sichere Verbindungen zulässt und auch die "SSL secured connection"? (oder liegt's am Client)?
Wenn du slapd nur mit dem Parameter -h ldaps:/// startest, wird ausschließlich über Port 636 eine Verbindung hergestellt. Allerdings musst du dann auch alle Clients entsprechend konfigurieren. Eine andere Möglichkeit besteht in der Konfiguration entsprechender access Regeln, siehe dazu man slapd.access(5), Stichwort Security Strength Factor (ssf). -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53
Dieter Kluenter wrote:
Hallo Joachim,
Joachim Kieferle <joakie@architektur.fh-wiesbaden.de> writes:
Hallo Liste (hallo Dieter Klünter ;-)),
habe die Verschlüsselung in Openldap nach Dieters Buch vorbereitet und in /etc/openldap/slapd.conf auch die drei Zeilen TLSCertificateFile /etc/openldap/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ldapkey.pem TLSCACertificateFile /etc/openldap/cacert.pem eingefügt.
[ ... ]
Seltsamerweise lässt der LDAP-Server aber immer noch über Port 389 unverschlüsselte Verbindungen zu.
Das ist der große Unterschied zwischen SSL und TLS :-) Auf Port 389 muss der Client die Verschlüsselung mit der Funktion ldap_start_tls initiieren, über Port 636 stellt der Server sofort eine verschlüsselte Verbindung her und der Client muss das Zertifikat prüfen oder ungeprüft übernehmen.
Über Port 636 bekomme ich dagegen z.B. mit dem Programm Ldapadmin _keine_ Verbindung.
Wie ist denn ldapadmin konfiguriert?
Hallo Dieter, ldapadmin läuft unter Windows (http://ldapadmin.sourceforge.net/). Wenn ich "Use SSL secured connection" aktiviere, schaltet er automatisch Port 636 an. Beim Verbinden kommt dann aber "LDAP-Fehler: Server heruntergefahren". Ohne SSL verbindet er einwandfrei. Zertifikate kann ich nicht einlesen. ....
openssl s_client -connect localhost:636 -showcerts zeigt auf dem LDAP-Server die Zertifikate und als letzte Zeile "Verify return code: 21 (unable to verify the first certificate)"
Ich nehme aber an, das kommt vom "Self signed certificate".
Das liegt möglicherweise auch daran, dass der Client nicht den Pfad auf das cacert.pem kennt, hast du denn die entsprechenden Einträge in /etc/openldap/ldap.conf gemacht?
... ok, aber dann muss ich mich da erst mal nicht drum kümmern?
Jetzt die Frage: wie kann ich meinen LDAP-Server überreden dass er nur noch sichere Verbindungen zulässt und auch die "SSL secured connection"? (oder liegt's am Client)?
Wenn du slapd nur mit dem Parameter -h ldaps:/// startest, wird ausschließlich über Port 636 eine Verbindung hergestellt. Allerdings musst du dann auch alle Clients entsprechend konfigurieren. Eine andere Möglichkeit besteht in der Konfiguration entsprechender access Regeln, siehe dazu man slapd.access(5), Stichwort Security Strength Factor (ssf).
... würde ich dann "härten", sobald er prinzipiell läuft. Ist das aus Deiner Sicht sinnvoll? Viele Grüsse Joachim
Hallo Joachim, Joachim Kieferle <joakie@architektur.fh-wiesbaden.de> writes:
Dieter Kluenter wrote:
Hallo Joachim,
Joachim Kieferle <joakie@architektur.fh-wiesbaden.de> writes:
[...]
Über Port 636 bekomme ich dagegen z.B. mit dem Programm Ldapadmin _keine_ Verbindung.
Wie ist denn ldapadmin konfiguriert?
Hallo Dieter,
ldapadmin läuft unter Windows (http://ldapadmin.sourceforge.net/). Wenn ich "Use SSL secured connection" aktiviere, schaltet er automatisch Port 636 an. Beim Verbinden kommt dann aber "LDAP-Fehler: Server heruntergefahren". Ohne SSL verbindet er einwandfrei. Zertifikate kann ich nicht einlesen.
OK, ldapadmin beherrscht also nicht die Möglichkeit der Integritätsprüfung, dann mußt du die Konfiguration etwas ändern. In slapd.conf nicht das cacert.pem ausweisen, also nur die Parameter ,----[ slapd.conf ] | TLSCcertificateFile /pfad/auf/datei | TLSCertificateKeyFile /pfad/auf/datei `---- und in /etc/openldap/ldap.conf die Zeile TLS_REQCERT never
Wenn du slapd nur mit dem Parameter -h ldaps:/// startest, wird ausschließlich über Port 636 eine Verbindung hergestellt. Allerdings musst du dann auch alle Clients entsprechend konfigurieren. Eine andere Möglichkeit besteht in der Konfiguration entsprechender access Regeln, siehe dazu man slapd.access(5), Stichwort Security Strength Factor (ssf).
... würde ich dann "härten", sobald er prinzipiell läuft. Ist das aus Deiner Sicht sinnvoll?
Na ja, in diesem speziellen Fall wird ja nur der Datentransport verschlüsselt, eine Integritätsprüfung der beteiligten Parteien findet ja nicht statt. Trotzdem würde ich den Datentransport so geschützt wie möglich abwickeln und gegebenenfalls zusätzliche Sicherheitsmassnahmen auf dem Server vorsehen. Gegebenenfalls kann man durch geeignete Security Strength Factors das Risiko minimieren. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53
Dieter Kluenter wrote: [ ... ]
Über Port 636 bekomme ich dagegen z.B. mit dem Programm Ldapadmin _keine_ Verbindung.
Wie ist denn ldapadmin konfiguriert?
Hallo Dieter,
ldapadmin läuft unter Windows (http://ldapadmin.sourceforge.net/). Wenn ich "Use SSL secured connection" aktiviere, schaltet er automatisch Port 636 an. Beim Verbinden kommt dann aber "LDAP-Fehler: Server heruntergefahren". Ohne SSL verbindet er einwandfrei. Zertifikate kann ich nicht einlesen.
OK, ldapadmin beherrscht also nicht die Möglichkeit der Integritätsprüfung, dann mußt du die Konfiguration etwas ändern.
In slapd.conf nicht das cacert.pem ausweisen, also nur die Parameter
,----[ slapd.conf ] | TLSCcertificateFile /pfad/auf/datei | TLSCertificateKeyFile /pfad/auf/datei `----
und in /etc/openldap/ldap.conf die Zeile
TLS_REQCERT never
Wenn du slapd nur mit dem Parameter -h ldaps:/// startest, wird ausschließlich über Port 636 eine Verbindung hergestellt. Allerdings musst du dann auch alle Clients entsprechend konfigurieren. Eine andere Möglichkeit besteht in der Konfiguration entsprechender access Regeln, siehe dazu man slapd.access(5), Stichwort Security Strength Factor (ssf).
... würde ich dann "härten", sobald er prinzipiell läuft. Ist das aus Deiner Sicht sinnvoll?
Na ja, in diesem speziellen Fall wird ja nur der Datentransport verschlüsselt, eine Integritätsprüfung der beteiligten Parteien findet ja nicht statt. Trotzdem würde ich den Datentransport so geschützt wie möglich abwickeln und gegebenenfalls zusätzliche Sicherheitsmassnahmen auf dem Server vorsehen. Gegebenenfalls kann man durch geeignete Security Strength Factors das Risiko minimieren.
[ ... ] Hallo Dieter, danke für die Tipps. Es scheint, dass ldapadmin _nicht_ damit umgehen kann. Habe mit Yast2 von einer anderen Maschine darauf zugegriffen und SSL/TLS aktiviert, das funzt einwandfrei. Wie kann ich denn überprüfen, ob der Traffic wirklich verschlüsselt abläuft? /var/log/messages sagt nichts drüber. Wenn ich in der Firewall nur Port 636 offen lasse, bekommt der Client keine Verbindung, obwohl ich für ihn explizit Port 636 angegeben habe. Viele Grüsse Joachim
Hallo Joachim, Joachim Kieferle <joakie@architektur.fh-wiesbaden.de> writes:
Dieter Kluenter wrote:
Hallo Dieter,
ldapadmin läuft unter Windows (http://ldapadmin.sourceforge.net/). Wenn ich "Use SSL secured connection" aktiviere, schaltet er automatisch Port 636 an. Beim Verbinden kommt dann aber "LDAP-Fehler: Server heruntergefahren". Ohne SSL verbindet er einwandfrei. Zertifikate kann ich nicht einlesen.
OK, ldapadmin beherrscht also nicht die Möglichkeit der Integritätsprüfung, dann mußt du die Konfiguration etwas ändern.
danke für die Tipps. Es scheint, dass ldapadmin _nicht_ damit umgehen kann. Habe mit Yast2 von einer anderen Maschine darauf zugegriffen und SSL/TLS aktiviert, das funzt einwandfrei. Wie kann ich denn überprüfen, ob der Traffic wirklich verschlüsselt abläuft? /var/log/messages sagt nichts drüber. Wenn ich in der Firewall nur Port 636 offen lasse, bekommt der Client keine Verbindung, obwohl ich für ihn explizit Port 636 angegeben habe.
Du kannst mittels ethereal den Datenverkehr aufzeichnen lassen und anschließend analysieren, oder auch mittels tcpdump -vvv -w /pfad/auf/datei anschließend den Dump mittels ethereal analysieren. Wenn der Datentransport verschlüsselt wird, siehtst du in ehtereal den Hinweis 'unknown protocol'. Eine dritte Möglichckeit ist 'ssldump' ähnlich wie tcpdump, nur werden damit SSL/TLS Pakete analysiert. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53
participants (2)
-
Dieter Kluenter -
Joachim Kieferle