Sendmail Probleme nach Erneuerung des CAcert Zertifikats

Sosch

Lt. Junior Grade
🎅Rätsel-Elite ’25
Registriert
Apr. 2007
Beiträge
389
Hallo,

mein Mailserver hat gerade ein neues CAcert Zertifikat erhalten, d.h. ich habe mit openssl einen Key erstellt, die ganze Registrierungsgeschichte (also der "schriftliche Kram") hinter mich gebracht und habe nun einen gültigen Schlüssel zugesandt bekommen.

Das Mailsystem ist "sendmail" auf einem suse Server. Da ich jedoch nicht das vorherige Zertifikat eingerichtet habe, weiss ich nicht so recht wie das Ändern von statten geht.

Ich habe in der /etc/sendmail.cf die verweisenden Einträge gefunden (O CACertPath, CA File, Server Cert, Server Private Key), werde daraus jedoch nicht schlauer. Die Zertifikate werden in /etc/ssl/cert/ abgelegt - habe ich überprüft und die Alten auch gefunden.

Es sind 2 Dateien, die in der sendmail.cf angegeben sind:

xyz.cert
und
xyz.key

in welche der Dateien muss ich nun welche Schlüssel eintragen?
In der bisherigen xyz.cert waren 3 oder 4 verschiedene Schlüssel eingetragen, in der xyz.key nur Einer.

Ich habe testweise mal immer nur eine der beiden Dateien geleert und dann den mir zugesandten Key eingetragen. Beide Male kommt dann z.b. beim Senden per Thunderbird die Fehlermeldung "Eine sichere Verbindung mit dem SMTP-Server smtp.abc.de kann nicht mit STARTTLS aufgebaut werden, da der Server diese Funktion nicht angibt." usw.

Ich bin da leider recht ratlos. Wäre ja auch zu einfach gewesen.

Ich hoffe ihr könnt mir helfen. :)

Gruß und danke fürs Lesen,
Sosch
Ergänzung ()

Gehe ich richtig in der Annahme, dass ich den von mir vorher per openssl erstellen RSA Key in die xyz.key und den mir zugesandten Key in die xyz.cert eintragen muss?
Die scheint bei mir zumindest das "richtige" Zertifikat für den Thunderbird zu sein. Mir wird dann zwar das "richtige" Zertifkat angezeigt, laut Thunderbird ist dieses aber falsch!

"Zertifikat-Status
Diese Webseite versucht sich mit ungültigen Informationen zu identifizieren."

Kann es ein Fehler sein, dass der Server eigentlich xyz.abc.de heisst (und auf diesen Hostnamen auch das Zertifikat angepasst wurde), die Mails jedoch per smtp.abc.de versandt werden wollen?
 
Hi Sosch,

wenn du dich an der englischen Sprache nicht störst, dann kannst du Dir gerne mal diese Anleitung (Sendmail SMTP Auth TLS) ansehen.

Einige Schritte kannst du wahrscheinlich überspringen, da du ja sicher schon einiges installiert hast, um OpenSSL zu nutzen.

Hier ist noch eins von Sendmail direkt und dieses ist in Deutsch.
 
Ich habs mit Sendmail noch nicht gemacht, nur mitm Apache... aber das Kernprinzip von Certs ist ja überall gleich.
- du hast einen private Key, den du irgendwo nur für Root lesbar (und zur Sicherheit noch nicht einmal schreibbar) lagerst. Gleichzeitig hast du eine auf diesen Key ausgerichtete Cert-File, in der eigentlich dein auf den Key abgestimmter Cert Request sowie die Cert Chain stehen sollten.
 
Was genau ist der private Key? Der von mir erstellte RSA Key, den ich zur Zertifizierung weitergeleitet habe? Das Cert-File müsste dann ja das Zertifikat sein, was mir daraufhin zugesandt worden ist. Ich habe jetzt aktuell in der xyz.key den o.g. RSA Key eingefügt und in die xyz.cert das Zertifikat. Dadurch erhalte ich jedoch die Fehlermeldung (beim Senden) "Diese Webseite versucht sich mit ungültigen Informationen zu identifizieren."
Oder was ist mit dem Cert Request und Cert Chain gemeint?

Muss vielleicht ein Alias gesetzt werden (smtp.abc.de)? Das Zertifkat wird nämlich als hostname.abc.de angezeigt.
 
Request: du erzeugst auf deiner Maschine einen RSA-Key und eine auf diesen Key abgestimmte Anfrage (dafür gibts Shell Commands). Diese Anfrage packst du dann deiner Certification Authority vor die Nase und die generieren daraus ein Zertifikat (das eben von dieser CA ausgestellt wurde).
Chain: Es ist ja schön, dass deine CA das Zertifikat ausgestellt hat, aber wer sagt, dass diese CA kein Schweineverein ist? Genau: die nächsthöhere Stelle. Die Cert Chains sagen nix anderes als sinngemäß: Guck ma, das Zertifikat ist von A. Die Vertrauenswürdigkeit von A kannst du bei B prüfen. Ob B was taugt erzählt die C, und C wiederum ist die absolute Spitze des Eisbergs.

Falls dein Englisch passt und du den Gedankensprung von nem recht speziellen Tutorial zu etwas Allgemeinerem hin bekommst:
http://www.howtoforge.com/securing-...-free-class1-ssl-certificate-from-startssl-p2
 
Aaaalso, ich habe nun noch ein neues Zertifkat mit dem selben Request angefordert, in welchem aber zusätzlich die Aliase "imap.abc.de" und "smtp.abc.de" enthalten sind.

Ich habe danach nun wie erklärt gemacht, Request RSA Key in die xyz.key und das mir zugesandte Zertifikat INKLUSIVE der Chain (Deutsche Telekom Root CA etc.) in die xyz.cert eingepflegt. Sieht nun auch quasi aus wie vorher -> 4 Certs in der xyz.cert und ein RSA Key in der .key

Trotzdem wird mir nun (auch nach nem sendmail Neustart) beim Thunderbird weissgemacht, dass das Zertifikat nicht vertrauenswürdig ist. Muss der Client noch irgend etwas tun? Ich lese da auch irgendwas von Nutzerzertifkaten im Webinterface der CA Stelle, werden aber nicht weiter beschrieben... : /
(Vielen Dank schonmal bis hierher)
Gruß
 
Wenn der TBird dieselbe Macke hat wie der FF, dann mag er kombinierte Certs nicht so gerne. Während Chrome kein Problem mit ner Webseite hatte, die im Apache nur Keyfile & n kombiniertes Cert hatte, hat Firefox so lange rumgemeckert, bis ich die Cert aufgeteilt habe in das eigentliche Cert, das CACert und die ChainFile. Der FF wollte nix anderes akzeptieren, auch keine Bundle-Deklaration.
 
Hmm...zur Not muss ich das mal aufteilen. Aber mir fällt gerade ein neues merkwürdiges Problem auf, bzw. das habe ich vorhin übersehen:
Es scheint so, als würde das Gültigkeitsdatum auf einmal wieder das "alte" sein (05.2007-05.2012 -> wenn man sich das Zertifikat im Thunderbird anzeigen lässt). Damit wäre es wieder abgelaufen?!

Muss die Chain vielleicht auch "erneuert" werden? Also bekomme ich normalerweise neue Zertifikate von den übergeordneten Prüfstellen, bzw. muss ich welche anfragen? Oder wie kann es sein, dass das gerade erst beantragte Zertifikat abgelaufen ist? (und zufällig exakt das gleiche Ablaufdatum aufweist wie das alte Zertifikat, welches aber ersetzt wurde und dadurch auch nicht mehr aktiv ist)
 
Zurück
Oben