![](https://seccdn.libravatar.org/avatar/71c84eb753c5845eb1d9071a337e30ce.jpg?s=120&d=mm&r=g)
Sven Gehr
Am Mi 11.05.2005 14:37 schrieb claus
: Sven Gehr wrote:
Hallo,
failed to update database TXT_DB error number 2 Signed certifikate is in newcert.pem
Ist meine prinzipielle Vorgehensweise denn überhaupt richtig? Auf meinen 'alten' Systemen habe ich immer nur ein Zertifikat gebraucht und deshalb hatte ich nie dieses Problem.
Ich werweisse mal ... Wenn ich richtig liege ist das ein "dupplicate key" Fehler beim Datenbankinsert. Verwendest du den gleichen CommonName bei deinen 2 Zertifikaten? Siehe auch... http://www-unix.globus.org/mail_archive/discuss/2005/01/msg00359.html
ja ich verwende für die Zertifikate den FQH. Das habe ich im Buch so gelesen. Bisher habe ich immer nur das Zertifikat dür den LDAP-Server so angelegt und da gab es natürlich keine Probleme. Ich dachte mir nur ich lege für die anderen Server-Dienste (IMAP, SMTP und HTTP) gesonderte Zertifikate an. Das wollte ich machen das ich, im Falle das ich ein Zertifikat verwerfen muß nur das einzelne verwerfen.
Muß ich bei den Zertifikaten für die anderen Dienste nicht den FQH als common Name benutzen? dann könnte ich ja immer [Dienst].[lokale_Domain] benutzen also:
Nimm für jeden Host ein Zertifikat, das können sich dann alle Dienste teilen. So mache ich das auch mit SMTPD und Imapd, hauptsache CN=FQHN
als common name benutzen. Was mich interessieren würde ist warum ich z.B. beim LDAP überhaupt den FQH nehemn muß/soll ?
Ganz einfach, weil der Common Name des Zertifikats ausgelesen wird und mit der angegebenen Adresse verglichen wird. Das ist aber nicht nur bei LDAP der Fall sondern bei allen Diensten, die StartTLS verwenden, wie z.B. imapd, smtpd u.a. Wenn du z.B. ein ldapsearch -ZZ -H ldap://localhost ... ausführen möchtest, im Serverzertifkat steht aber als CN host.example.com, dann wird die Verbindung vom Client nicht akzeptiert. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53