Probleme beim anlegen mehrere Zertifikate
![](https://seccdn.libravatar.org/avatar/4b52bad59e34ba2a8ed4ec86bfb8dd75.jpg?s=120&d=mm&r=g)
Hallo zusammen, ich habe ein Problem beim einrichten der CA bzw. der Zertifikate. Das anlegen der CA mache ich mit: 1.) # CA einrichten # ./CA.sh -newca [Return] Enter PEM pass phrase: [rootpw] Verifying - Enter PEM pass phrase: [rootpw] Country Name: DE State or Province Name (full name): Baden-Wuerttemberg Locality Name (eg, city): Mannheim Organization Name (eg, company): Schlocke Organizational Unit Name (eg, section): Common Name (eg, your name): schlockeserver.schlockenet Email Address: root@schlockeserver.schlockenet das funktioniert auch. Anschließend lege ich das erste Zertifikat mit: 2.) # Zertifikate einrichten # ./CA.sh -newreq Enter PEM pass phrase: [rootpw] Verifying - Enter PEM pass phrase: [rootpw] Country Name: DE State or Province Name (full name): Baden-Wuerttemberg Locality Name (eg, city): Mannheim Organization Name (eg, company): Schlocke Organizational Unit Name (eg, section): Common Name (eg, your name): schlockeserver.schlockenet Email Address: root@schlockeserver.schlockenet A challenge password: [nichts eingeben] An optional company name [nichts eingeben] ./CA.sh -sign Enter pass phrase for ./demoCA/private/cakey.pem: [rootpw] Sign the certificate? :y 1 out of 1 certificate requests certified, commit? :y mv newcert.pem ldapdcert.pem openssl rsa -in newreq.pem -out ldapdkey.pem Enter pass phrase for newreq.pem: [rootpw] ./CA.sh -verify ldapdcert.pem auch das funktioniert. Nun möchte ich ab dem Punkt 1 das ganze für das nächste Zertifikat wiederholen. Hier erhalte ich am Ende, beim Aufruf von './CA.sh -sign' einen Fehler. Zunächst wird das Zertifikat angezeigt und gefragt: Sign the certificate? [y/n] Wenn ich hier mit 'y' antworte erhalte ich den Fehler: 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. Viele Grüße Sven
![](https://seccdn.libravatar.org/avatar/8a3c8f61f95866170e218b2bef401c2c.jpg?s=120&d=mm&r=g)
Hallo Sven, Sven Gehr wrote:
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 Gruss, Claus
![](https://seccdn.libravatar.org/avatar/4b52bad59e34ba2a8ed4ec86bfb8dd75.jpg?s=120&d=mm&r=g)
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: imap.schlockenet als common name benutzen. Was mich interessieren würde ist warum ich z.B. beim LDAP überhaupt den FQH nehemn muß/soll ? Viele Grüße Sven
![](https://seccdn.libravatar.org/avatar/8a3c8f61f95866170e218b2bef401c2c.jpg?s=120&d=mm&r=g)
Hallo Sven, Sven Gehr wrote:
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.
Ich weiss nicht, ob das nötig / sinnvoll ist. Ich hatte das letztes Mal einfach jedem Dienst eine eigene FQHN zugewiesen, welche dann aber auf die gleiche IP zeigten. imap.schlockenet, smptp.schlockenet und http.schlockenet und das lief damals mit Postfix, UW IMAP und Apache 2. Ich kann keine Aussage was da "good practice" oder so ist, vielleicht hat hier jemand dazu eine Meinung...
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:
Genauso lief's bei mir. Vom Indianer weiss ich, dass er sich weigert sich, wenn der CN dess Zertifikats nicht dem "ServerName" entspricht, aber das weisst du wahrscheinlich bereits, bei den Anderen bin ich nie angestossen, d.h. ich weiss es nicht.
als common name benutzen. Was mich interessieren würde ist warum ich z.B. beim LDAP überhaupt den FQH nehemn muß/soll ?
Weiss da Dieter vielleicht mehr darüber? Er ist doch hier der LDAP Crack ;-) Gruss, Claus
![](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
![](https://seccdn.libravatar.org/avatar/71c84eb753c5845eb1d9071a337e30ce.jpg?s=120&d=mm&r=g)
Sven Gehr
Hallo zusammen,
ich habe ein Problem beim einrichten der CA bzw. der Zertifikate. Das anlegen der CA mache ich mit:
1.) # CA einrichten #
./CA.sh -newca [Return] [...] Anschließend lege ich das erste Zertifikat mit:
2.) # Zertifikate einrichten #
./CA.sh -newreq [...] ./CA.sh -sign Enter pass phrase for ./demoCA/private/cakey.pem: [rootpw] Sign the certificate? :y 1 out of 1 certificate requests certified, commit? :y
mv newcert.pem ldapdcert.pem openssl rsa -in newreq.pem -out ldapdkey.pem Enter pass phrase for newreq.pem: [rootpw] ./CA.sh -verify ldapdcert.pem [...] Sign the certificate? [y/n] [...] Wenn ich hier mit 'y' antworte erhalte ich den Fehler:
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.
Deine Vorgehensweise ist schon richtig, openssl legt ab er im Arbeitsverzeichnis eine kleine Liste mit den bereits signierten Certifikaten an und diese ist nicht synchron, prüfe das mal. Du hast möglicherweise vorher Zertifikate ohne Signatur erstellt. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53
participants (3)
-
claus
-
Dieter Kluenter
-
Sven Gehr