Mail Server Zertifikate

Mail Server Zertifikate

Am Wochenende ist das alte Sicherheits-Zertifikat unseres Mailenable Mailservers abgelaufen. Wir haben es rechtzeitig routinemäßig erneuert und seit Samstag 28.2.. ist das neue Zertifikat auf unseren Mailservern aktiv.

Das Zertifikat ist sozusagen der Stempel des Internet-Notars der bestätigt, dass unser Zertifikat korrekt ausgestellt ist, und wir im Besitz der Domain *.ccc.at sind.

Funktionen von Mail Server Zertifikaten

1. Sicher stellen dass der Client sich nicht irrtümlich mit einem Server verbindet, der sich als unser Mailserver ausgibt
2. Verschlüsselung der Daten die zwischen Client und Server übertragen werden
   (Das ist bei Mail ebenfalls wichtig, weil über diese Verbindung auch die Passwörter ausgetauscht werden)

Wenn es zu Problemen kommt, gibt es zwei Möglichkeiten:

Wie funktioniert der Ablauf?

Für den Mail Server wird ein Zertifikat ausgestellt. Die Ausstellende “Behörde” ist eine sogenannte Certificate Authority. Sie bestätigt, dass 4future.digital die Domain ccc.at besitzt mit einer Signatur (“Stempel”).

Wenn der Client seine Mails abruft zeigt der Mailserver das Zertifikat her, um zu beweisen, dass er der Server ist, mit dem der Client sprechen möchte (Authentification). Dieses Zertifikat wird auch für die Verschlüsselung des Mailverkehrs verwendet.

Wenn der Client die ausstellende “Behörde” nicht kennt, vertraut der Client dem Zertifikat (dem “Ausweis”) nicht, und bricht die Verbindung ab.

Wenn das Root Zertifikat am Client fehlt

Die Softwarehersteller müssen die Zertifikate des Notars (Certificate Authority) in den Certificate Store des Betriebssytems aufnehmen. Diese Zertifikate bestätigen die Zertifizierungsstelle und es ist notwendig dass die Software dem Notar vertraut.

In aktuellen Betriebssystemen ist das Zertifikat der Registrierungsstelle das unser Zertifikat ausstellt enthalten und das Betriebssystem vertraut dieser Zertifizierungsstelle (dem Notar). Bei älteren Betriebssystemen bzw. bei Betriebssystemen bei denen die Software-Updates nicht eingespielt werden kann dieses Zertifikat fehlen.

In diesem Falle sagt der Client dann: Ich sehe ein Zertifikat – aber da ist ein Stempel von einer Registrierungsstelle darauf, die ich nicht kenne – also vertraue ich der Verbindung nicht.

Das sieht dann als Fehlermeldung so aus:

An diesem Screenshot sieht man, dass unser Zertifikat für *.ccc.at ausgestellt ist (also für alle Server die mit .ccc.at enden), es ist von der Sectigo Public Server Authetication Certificat Authority DV R36 ausgestellt. Genau das Zertifikat exakt dieser Authority muss im Client verfügbar sein. Dieses Zwischenzertifikat ist wiederum von der Sectigo  Public Server Authentication Root R46 Authority gestempelt. Auch dieses Zertifikat muss am Client vorhanden sein. Wenn eines fehlt, lehnt der Client die Verbindung als unsicher ab. 

Wie kann man das Problem lösen? Eigentlich sollte es gar nicht existieren, wenn der Client aktuelle Software installiert hat und alle Betriebssystemupdates installiert wurden. Es gibt also 2 Gründe warum es fehlen könnte: 

1. Der Client hat ein vom Hersteller nicht mehr supportetes Betriebssystem im Einsatz
   (Dann ist der Client auch in anderer Hinsicht gefährdet und es sollte entweder auf ein neueres Betriebssystem umgestiegen werden, oder falls das nicht mehr möglich ist, die Hardware getauscht werden).
2. Die Security Updates wurden nicht eingespielt
   (Dann ist der Client ebenfalls gefährdet und das sollte ehebaldigst nachgeholt werden)

In beiden Fällen wäre der Client als unsicher im Internet einzustufen und Anfällig gegen Viren und andere Bedrohungen im Netz. 

Als Umgehungslösung ist es möglich das Root Zertifikat von Sectigo manuell in den Client einzuspielen. Dabei muss das Zertifikat von der Website des Zertifikatsanbieters manuell in den Certificate Store des Clients aufgenommen werden.

Das Root-Zertifikat sowie das Intermediate Zertifikat ist hier zu finden:

DV TLS Roots (After June 2, 2025)
RSA: Sectigo Public Server Authentication Root R46 (https://crt.sh/?d=4256644734)

DV TLS Intermediate (After June 2, 2025)
RSA: Sectigo Public Server Authentication CA DV R36 (https://crt.sh/?d=4267304690)

Diese beiden Zertifikate müssen im Certificate Store des Betriebssystems liegen und diesen Zertifikaten muss das Betriebssystem vertrauen.

Alle Root Zertifikate von Sectigo sind hier zu finden:
https://www.sectigo.com/faqs/detail/Sectigo-Public-Intermediates-and-Roots

Falscher Servernamen angegeben

Die zweite Möglichkeit ist, dass ein falscher Servername angegeben wurde, also z.B. mail.meinedomain.at statt i4.ccc.at/sm.ccc.at – dann beschwert sich der Client, dass das Zertifikat nicht mit dem Namen zusammen passt.

Oft lässt sich das durch einmalige Bestätigung beheben. Dann tritt das Problem erst das nächste mal wieder auf, wenn das Zertifikat am Server erneuert wird. In diesem Fall wird durch die Bestätigung des (für diesen Servernamen) falschen Zertifikats dem Zertifikat vertraut.

Zusammenfassung

Auf unserem Server sind alle Zertifikate korrekt. Es gibt nur zwei mögliche Gründe dafür dass der Client das Zertifikat ablehnt:

• Alte / nicht upgedatete Client Software
• Falsch konfigurierte Client Software