Hallo zusammen, schrieb Sven Gehr: ich bin ein Stück weiter gekommen.

ich habe mir (unter SuSE-9.1) eine CA mit: ./CA.sh -newca erstellt. Anschließend habe ich mit: CA.sh -newcert ein Zertifikat erstellt. Wenn ich nun versuche das Zertifikat mit: CA.sh -signcert zu signieren erhalte ich folgnde Meldung: Cert passphrase will be request twince - bug? Getting request Private Key Enter pass phrase for newreq.pem: [Passworteingabe] Generating certificate request Using configuration from /etc/ssl/openssl.conf 3011:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:329:group=CA_default name=unique_subject Enter pass phrase for ./demoCA/private/cakey.pem:

Dieser Fehler beim signieren das Zertifikate tritt nicht mehr auf wenn man in der Datei openssl.cnf die Zeile: unique_subject = no aktiviert. Soweit schonmal gut. Jedoch erhalte ich, wenn ich anschließend versuche die erkannten und verifizierten Zertifikate, mit dem Befehl: openssl s_client -connect localhost:389 -showcerts anzuzeigeb folgenden Fehler: CONNECTED(00000003) 2925:error140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: Weiterhin steht im Buch zu diesem Handshake-Fehler: ".. Achten Sie darauf, dass in den Konfiguationsdateien slapd.conf und ldap.conf und ldaprc keine Doppelpunkte (:) oder Gleichheitszeichen (=) gesetzt sind. Dies unachtsamkeit hat uns drei Tage verzweifeltes Suchen eingebacht." Wenn ich mir die entsprechenden Dateien anschaue sind da aber sehr wohl diese 'verbotenen' Zeichen drin: **slapd.conf** access to dn.base="" by * read [...] sufix "dc=kundennetz" usw. **ldap.conf** rootbinddn cn=root,dc=kundennetz [...] pam_filter abjectclass=posixAccount [...] um nur mal einige zu nennen. Das hat der Verfasser sicher anderts gemeint, oder? Viele Grüße Sven

Hallo zusammen, Am Samstag, 22. Mai 2004 22:18 schrieb Andreas Winkelmann:

schrieb Sven Gehr:

...

aktiviert. Soweit schonmal gut. Jedoch erhalte ich, wenn ich anschließend versuche die erkannten und verifizierten Zertifikate, mit dem Befehl:

...

openssl s_client -connect localhost:389 -showcerts

...

anzuzeigeb folgenden Fehler:

...

CONNECTED(00000003) 2925:error140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:

...

Weiterhin steht im Buch zu diesem Handshake-Fehler:

...

".. Achten Sie darauf, dass in den Konfiguationsdateien slapd.conf und ldap.conf und ldaprc keine Doppelpunkte (:) oder Gleichheitszeichen (=) gesetzt sind. Dies unachtsamkeit hat uns drei Tage verzweifeltes Suchen eingebacht."

Das hat damit nix zu tun. Du versuchst mit OpenSSL den "normalen" Port abzufragen. Auf diesem Port ist eine Verschlüsselung nur über TLS (starttls) möglich, dazu müsste openssl aber "ldap" Sprechen es kann zur Zeit aber nur smtp allerhöchstens noch pop3.

Wenn Du das Kommando probieren möchtest, musst Du den ldap-server auch für den ldaps:-Port aktivieren (/etc/sysconfig/openldap) und wenn der läuft dann änderst Du den Port von 389 nach 636

d.h ich muss den LDAP-Server einfach über die sysconfig auf Port 636 brinden? Muß dazu nicht das TLS/SLL funktionieren (was bei mir ja nicht der Fall ist). Oder mache ich hier nun einen Gedanklichen Fehler?

$ openssl s_client -connect localhost:636 -showcerts

Probieren kann ich das leider erst Morgen. Viele Grüße Sven Gehr

Hallo, Am Sonntag, 23. Mai 2004 19:05 schrieb Andreas Winkelmann:

Am Sonntag, 23. Mai 2004 18:56 schrieb Sven Gehr:

...

...

Wenn Du das Kommando probieren möchtest, musst Du den ldap-server auch für den ldaps:-Port aktivieren (/etc/sysconfig/openldap) und wenn der läuft dann änderst Du den Port von 389 nach 636

d.h ich muss den LDAP-Server einfach über die sysconfig auf Port 636 brinden? Muß dazu nicht das TLS/SLL funktionieren (was bei mir ja nicht der Fall ist). Oder mache ich hier nun einen Gedanklichen Fehler?

...

$ openssl s_client -connect localhost:636 -showcerts

Wenn Du den ldap-server auch für den ldaps-port (636) startest, kannst Du dieses Kommando ausprobieren, mit dem normalen ldap-port (389) geht das nicht.

Wwwenn das Kommando dann was sinnvolles anzeigt, wäre das doch schon ein Schritt in die richtige Richtung.

ok das werde ich gleich Morgen probieren und berichten. Viele Grüße Sven

Hallo, ich glaube es geht voran. schrieb Sven Gehr:

...

...

d.h ich muss den LDAP-Server einfach über die sysconfig auf Port 636 brinden? Muß dazu nicht das TLS/SLL funktionieren (was bei mir ja nicht der Fall ist). Oder mache ich hier nun einen Gedanklichen Fehler?

Ich habe den LDAP über sysconfig auf LDAPS = yes gesetzt. Habe anschließend alle Zertifikate und die CA komplett gelöscht. Danach habe ich den gesamten Vorgang (CA -newca, CA -newcert, CA -signcert und Passwort mit openssl rsa ... entfern).

...

...

...

$ openssl s_client -connect localhost:636 -showcerts Wwwenn das Kommando dann was sinnvolles anzeigt, wäre das doch schon ein Schritt in die richtige Richtung.

Wenn ich nun ein: $ openssl s_client -connect localhost:636 -showcerts aufrufen erhalte ich: CONNECTED(00000003) depth=0 /C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver.kundennetz verify error:num=20:unable to get local issure certificate verify return:1 depth=0 /C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver.kundennetz verify error:num=21:unable to verify the first certificate --- Certificate chain 0 s:/C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver.kundennetz i:/C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver.kundennetz -----BEGIN CERTIFICATE----- MIIEczCCA1ugAwIBAgIBATANBgkqhkiG9w0BAQQFADB6MQswCQYDVQQGEwJkZTEO MAwGA1UECBMFYmFkZW4xETAPBgNVBAcTCG1hbm5oZWltMRMwEQYDVQQKEwprdW5k ZW5uYW1lMRMwEQYDVQQLEwprdW5kZW5uZXR6MR4wHAYDVQQDExV0ZXN0c2VydmVy Lmt1bmRlbm5ldHowHhcNMDQwNTI0MDQzMjQ5WhcNMDUwNTI0MDQzMjQ5WjB6MQsw CQYDVQQGEwJkZTEOMAwGA1UECBMFYmFkZW4xETAPBgNVBAcTCG1hbm5oZWltMRMw EQYDVQQKEwprdW5kZW5uYW1lMRMwEQYDVQQLEwprdW5kZW5uZXR6MR4wHAYDVQQD ExV0ZXN0c2VydmVyLmt1bmRlbm5ldHowggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCwBmFxvIW44Ehc0otle8rCiryZWqrsqKJREc4nxniykD4ATwUurBic 9iAjIdoBeirxiWymGG0dijk8LLNrZL8C9M/ZtJ+K2jQU6cJHV8dQU7qOTeKD5bYY vAEs+9sx1W4KsswqtZ63pJ0iX4FDqb8LDzv/ghGleM50vgt82txzJumZ2n0u3A8J OWV81IWIpMPY2pn9gAoF4WFuNhCHjPHzUiAHlP/molLxxzP0hgdq+oeBlIRWUKKY iK2I61kdjXKufIQl8qNh4rTyqsuJST4zv95kTNLfb0YXq7AeCIP76iifBMlHSqKC 6i/U9sXTnO/KkYzOxXuZUkfrVuZwHy8DAgMBAAGjggECMIH/MAkGA1UdEwQCMAAw LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G A1UdDgQWBBTvlLX03hRrEf72eerPz9T6yNJrPjCBpAYDVR0jBIGcMIGZgBTgQOTT LyamVsehuQeX0w8G/ChvCKF+pHwwejELMAkGA1UEBhMCZGUxDjAMBgNVBAgTBWJh ZGVuMREwDwYDVQQHEwhtYW5uaGVpbTETMBEGA1UEChMKa3VuZGVubmFtZTETMBEG A1UECxMKa3VuZGVubmV0ejEeMBwGA1UEAxMVdGVzdHNlcnZlci5rdW5kZW5uZXR6 ggEAMA0GCSqGSIb3DQEBBAUAA4IBAQCMqFotLXInRaAFLApCQroe6khBipGjk5qr zZGsyse9JeZlpcpXNDCyh9ke/sFl8Ad/K57a8TQE056YziOQVXAesnncoYF/vrH3 QQuqN/jPC23wYwln5BiXDeNfnhY5OPGFYwRbHUazaVsFrFStLCP2HzD1uWNW5NQR LtDWHLlRYpHf4qXR4SazbfkFD3No/CpaJ3NqC7JBdAHnBJEx612rwuAGlSSLK797 U1YHMBjnk8BvDr+4VSlzwHkef6XwDxv7WNNCFQyU171Nq8IG1fRWKfFmjiYO8BBf 5KF33rkZa6dGRgRBehcOJ0WpQIXI4FsE0jWecnXUDAX0L3BBuFHz -----END CERTIFICATE----- --- Server certificate subject=/C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver.kundennetz issuer=/C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver.kundennetz --- No client certificate CA names sent --- SSL handshake has read 1305 bytes and written 468 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 63ED5C94E7D28AE4C5F3A11FB990C3802A12D43479E3F6CE577AD6728AF6C29D Session-ID-ctx: Master-Key: 55B42C27C19CF8FBA88723077BD57AA0857B265B3EFD8AB28233814F0A7169C4E07FDA740AABE8ED3E3BC9F2B25CCBF3 Key-Arg : None Start Time: 1085373680 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- Am Ende bleit es einfach stehen, ohne mir die Eingabeaufforderung zu zeigen. Ich habe dann einfach [Strg]+[c] gemacht. Hoffe das bringt uns weiter. Viele Grüße Sven

Am Montag, 24. Mai 2004 07:56 schrieb Sven Gehr:

Hallo,

ich glaube es geht voran.

schrieb Sven Gehr: [...] CONNECTED(00000003) depth=0 /C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver. kundennetz verify error:num=20:unable to get local issure certificate verify return:1 depth=0 /C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver. kundennetz verify error:num=21:unable to verify the first certificate [...]

Da sehe ich gerade eine weitere mögliche Fehlerquelle. Du hast im Server-Zertifikat als Host 'testserver.kundennetz' eingetragen, ist das der Hostname und die Domain die über die Funktion 'gethostbyname' aufgelöst werden können? Andernfalls wird die TLS Verbindung vom Client verweigert. Noch eine weitere mögliche Fehlerquelle fält mir ein. Du setzt möglicherweise openssl-0.9.7 ein. Meine CA.pl Beispiele wurden mit openssl-0.9.6g erstellt. Bei openssl-0.9.7 müssen andere Paramter aufgerufen werden. CA.pl -newca CA.pl -newreq CA.pl -sign Alles andere ist noch gültig. Mit den von mir zitierten Parametern -newcert und -signcert wird jetzt ein 'self signed certificate' erstellt. Ich habe das nicht geprüft, aber möglicherweise wird hierbei cacert.pem nicht zum signieren benutzt. -Dieter -- Dieter Klünter | Systemberatung Tel.: +49.40.64861967 Fax : +49.40.64891521 http://www.avci.de

Hallo, schrieb Dieter Kluenter:

schrieb Sven Gehr:

...

CONNECTED(00000003) depth=0 /C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver. kundennetz verify error:num=20:unable to get local issure certificate verify return:1 depth=0 /C=de/ST=baden/L=mannheim/O=kundenname/OU=kundennetz/CN=testserver. kundennetz verify error:num=21:unable to verify the first certificate

Da sehe ich gerade eine weitere mögliche Fehlerquelle. Du hast im Server-Zertifikat als Host 'testserver.kundennetz' eingetragen, ist das der Hostname und die Domain die über die Funktion 'gethostbyname' aufgelöst werden können? Andernfalls wird die TLS Verbindung vom Client verweigert.

das ist der FQDN der läßt sich über nsloockup auflösen. Der Befehl 'gethostbyname' existiert auf meinem System nicht. Wenn ich jedoch ein: getent hosts mache bekomme ich die Ausgabe: 127.0.0.1 localhost 192.168.1.1 testserver.kundennetz testserver

Noch eine weitere mögliche Fehlerquelle fält mir ein. Du setzt möglicherweise openssl-0.9.7 ein.

Ich benutze die Version 0.9.7d

Meine CA.pl Beispiele wurden mit openssl-0.9.6g erstellt. Bei openssl-0.9.7 müssen andere Paramter aufgerufen werden. CA.pl -newca CA.pl -newreq CA.pl -sign

Ok, ich habe folgendes gemacht. Alle Dateien wieder entfernt und die Zertifikat- und CA Erstellung nochmal von vorne: ./CA.sh -newca ./CA.sh -newreq ./CA.sh -sign openssl rsa -in newreq.pem -out ldapkey.pem mv newcert.pem ldapcert.pem ./CA.sh -verify ldapcert --> ok

Alles andere ist noch gültig. Mit den von mir zitierten Parametern -newcert und -signcert wird jetzt ein 'self signed certificate' erstellt. Ich habe das nicht geprüft, aber möglicherweise wird hierbei cacert.pem nicht zum signieren benutzt.

Jedoch bringt 'openssl s_client -connect localhost:636 -showcerts' noch genau die identisch gleiche Ausgabe. Anschließd habe ich den Paramter den ich zu Anfang in der /etc/ssl/openssl.cnf aktiviert habe: unique_subject = no wieder auskommentiert und das Ganze nochmal von vorne gemacht dann erhalte ich aber wieder beim Aufruf von './CA.sh -sign' die Meldung: Using configuration from /etc/ssl/openssl.cnf 2982:error:0E06D06C:lib(40):UI_set_result:result too small:ui_lib.c:847:You must type in 4 to 8191 charecters Enter pass phrase for ./demoCA/privat/caky.pem: Check that the request matches the signature Signature ok Also nach der Passworteingabe geht es dann weiter und ich bekomme die Zertifikat-Details angzeigt. Hier ist mir aufgefallen das unter den [...] X509v3 extensions X509v3 Basic Constraints: CA:FALSE [...] Das war aber schon immer, also unabhängig von der Option 'unique_subject = no', so. steht, evtl ist das ein Problem? Ich mache dann weiter und beantworte die Frage ob das das Zertifikat signiert werden soll mit y Anschließend kommt noch die Frage: 1 out of 1 certificate requests certified, commit? [y/n] Wieso er mich nochmal fragt verstehe ich nicht so recht. Nur so am Rande. Kann es sein das meine LDAP-Probleme aus den Zertifikat-Problemen resultieren und wir zuerst diese Lösen sollten? Viele Grüße Sven

Sven Gehr writes:

Hallo,

schrieb Dieter Kluenter:

...

schrieb Sven Gehr:

...

Da sehe ich gerade eine weitere mögliche Fehlerquelle. Du hast im Server-Zertifikat als Host 'testserver.kundennetz' eingetragen, ist das der Hostname und die Domain die über die Funktion 'gethostbyname' aufgelöst werden können? Andernfalls wird die TLS Verbindung vom Client verweigert.

das ist der FQDN der läßt sich über nsloockup auflösen. Der Befehl 'gethostbyname' existiert auf meinem System nicht.

Das ist kein Befehl, sondern eine Funktion der C Bibliothek.

Wenn ich jedoch ein:

getent hosts mache bekomme ich die Ausgabe:

127.0.0.1 localhost 192.168.1.1 testserver.kundennetz testserver

OK.

...

Noch eine weitere mögliche Fehlerquelle fält mir ein. Du setzt möglicherweise openssl-0.9.7 ein. [...] Ok, ich habe folgendes gemacht. Alle Dateien wieder entfernt und die Zertifikat- und CA Erstellung nochmal von vorne:

./CA.sh -newca ./CA.sh -newreq ./CA.sh -sign openssl rsa -in newreq.pem -out ldapkey.pem mv newcert.pem ldapcert.pem ./CA.sh -verify ldapcert --> ok

Jedoch bringt 'openssl s_client -connect localhost:636 -showcerts' noch genau die identisch gleiche Ausgabe.

Das ist sehr eigenartig, das kann ich nicht reproduzieren.

Anschließd habe ich den Paramter den ich zu Anfang in der /etc/ssl/openssl.cnf aktiviert habe:

unique_subject = no

Den Parameter kenne ich nicht, macht aber auch nichts.

wieder auskommentiert und das Ganze nochmal von vorne gemacht dann erhalte ich aber wieder beim Aufruf von './CA.sh -sign' die Meldung:

Using configuration from /etc/ssl/openssl.cnf 2982:error:0E06D06C:lib(40):UI_set_result:result too small:ui_lib.c:847:You must type in 4 to 8191 charecters

Das hat wohl nicht zu sagen, in openssl.conf ist kein Paßwort eingetragen, oder das Paßwort hat nur drei Zeichen.

Enter pass phrase for ./demoCA/privat/caky.pem: Check that the request matches the signature Signature ok

Also nach der Passworteingabe geht es dann weiter und ich bekomme die Zertifikat-Details angzeigt. Hier ist mir aufgefallen das unter den

[...] X509v3 extensions X509v3 Basic Constraints: CA:FALSE [...] Das war aber schon immer, also unabhängig von der Option 'unique_subject = no', so.

Das sollte auch so sein, den 'Basic Constraints: CA:FALSE ist ein Parameter für ein Certificate Request, aber nicht für ein CA Request. Bei einem CA Request würde dort CA:TRUE stehen, siehe auch openssl.conf

steht, evtl ist das ein Problem? Ich mache dann weiter und beantworte die Frage ob das das Zertifikat signiert werden soll mit y

Anschließend kommt noch die Frage:

1 out of 1 certificate requests certified, commit? [y/n]

Wieso er mich nochmal fragt verstehe ich nicht so recht.

Ganz einfach, daß sind zwei Prozesse, zuerst wird das Zertifikat signiert, dann die Zertifizierung abgeschlossen, könnte ja sein, daß du mehrere Zertifkate signieren möchtest.

Nur so am Rande. Kann es sein das meine LDAP-Probleme aus den Zertifikat-Problemen resultieren und wir zuerst diese Lösen sollten?

Ich denke, das sind mehrere Ursachen. Zum Einen das Mißverständnis von SASL -> saslauthd, dann die stillschweigende Voraussetzung, daß saslauthd eine Authentifizierung gegen ldap vornehmen kann. Versuche das alles erst einmal ohne SSL oder TLS, wenn das funktioniert, dann kannst du TLS hinzufügen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de

Sven Gehr writes:

Hallo,

schrieb Dieter Kluenter:

...

Sven Gehr writes:

...

schrieb Dieter Kluenter:

...

schrieb Sven Gehr:

...

...

Nur so am Rande. Kann es sein das meine LDAP-Probleme aus den Zertifikat-Problemen resultieren und wir zuerst diese Lösen sollten?

...

Ich denke, das sind mehrere Ursachen. Zum Einen das Mißverständnis von SASL -> saslauthd, dann die stillschweigende Voraussetzung, daß saslauthd eine Authentifizierung gegen ldap vornehmen kann. Versuche das alles erst einmal ohne SSL oder TLS, wenn das funktioniert, dann kannst du TLS hinzufügen.

Das hat ja ohne TLS/SSL funktioniert. Wie schon mehrfach gesagt konnte ich mich an der lokalen Maschiene mit dem User 'sven' welcher ja bekantlich NUR im LDAP-VErzeichnis existierte anmelden.

ERGO funktionierte PAM in Zusammenarbeit mit LDAP. Ich hatte lediglich das Problem das die Eingabeaufforderung nicht sven vor dem @ zeigte sondern

I have no name...@

Das Homeverzeichnis /data/home/sven existiert aber, oder? Was zeigt denn 'whoami'. Sonst liegt der Fehler darin,daß irgendeine Loginanwendung, XDM, KDM oder sonstige noch /etc/passwd prüfen und dort keinen Eintrag finden. Das ist dann aber ein Problem der PAM-Konfiguration. ... Ich kann diesen Fehler nicht reproduzieren. Ich habe jetzt mal einen Testuser test2 als Posixaccount angelegt, nur im Verzeichnisdienst, und manuell das Verzeichnis /home/test2 angelegt. auf der Konsole kann ich mich als test2 mit Passwort einloggen und bekomme /home/test2 ,----[ Testuser ] | dieter@orange:~> su test2 | Password: | test2@orange:/home/dieter> cd | test2@orange:~> `---- Ich möchte test2 jetzt nicht mit einem Windowmanager starten oder über ein graphisches Login gehen, aber du siehst, daß das prinzipiell funktioniert.

Obwohl ich das Prinzip mitlerweil schon verstanden habe trete ich auf der Stelle und nix funktioniert. Ich weiß schon dass das mein Problem ist, aber wenn man nach fast einem Jahr ein und dasselbe Problem nochimmer nicht gelöst hat bekommt man Zweifel ob man einfach zu doof ist oder das System einfach zu unausgereift.

Diese TLS-Geschichte ist mir rätselhaft, daher versuche doch erst einmal die simpelste Form. In slapd.conf gib nur den Pfad auf das Hostzertifikat und Key bekannt, kein cacert. Deine bereits erstellten Zertifikate sollten dafür genügen. TLSCertificateFile /etc/openldap/cert/ldapcert.pem TLSCertificateKeyFile /etc/openldap/cert/ldapkey.pem Die Pfade aber bitte auf deine Zertifikate setzen :-) In /etc/openldap/ldap.conf nur TLS_REQCERT never Jetzt solltest du mit ldapsearch -d3 -H ldap://testserver.kundenservice -b "" -s base + -x -Z die Verbindung beobachten können. Über Error 19 und self signed certificate solltest du dir keinen Kopf machen, die Verbindung wird trotzdem verschlüsselt. Wenn da keine Verbindung zustande kommt, weiß ich auch nicht weiter :-( Diese Methode ist eigentlich nicht zu empfehlen,da hier keine Integritätsprüfung vorgenommen werden kann, sondern nur eine Verschlüsselung des Datentransports, aber für eine Funktionsprüfung genügt es. -Dieter -- Dieter Klünter | Systemberatung Tel.: +49.40.64861967 Fax : +49.40.64891521 http://www.avci.de