Forced TLS Email - welche Domain muss in das Zertifikat?

Nov 17, 2023
265
31
28
Moin,
wir nutzen bereits TLS bei eingehenden E-Mails mit dem von Proxmox selbsterstellten Zertifikat, das funktioniert auch ganz toll, aber es wird beim Check der Domain mit https://www.checktls.com/TestReceiver noch ein Fehler angezeigt.

"

Certificate #1 of 1 (sent by MX):
Cert VALIDATION ERROR(S): self signed certificate
So email is encrypted but the recipient domain is not verified
MX Server: mailunity.domain.com


Um das Problem zu beheben, muss ich da einfach nur ein SSl-Zertifikat bei meinen SSL-Provider (PSW Group) für die Domain mailunity.domain.com bestellen und dann als /etc/pmg/pmg-tls.pem einfügen?

Ist das so korrekt? Oder ist das eine andere Domain?
 

Attachments

  • Bildschirmfoto 2025-05-13 um 11.29.52.png
    Bildschirmfoto 2025-05-13 um 11.29.52.png
    29.9 KB · Views: 1
Last edited:
Ich habe jetzt eine neues SSL-Zertifikat für die mailunity.domain.com gekauft und installiert.

Jetzt hat sich die Meldung von https://www.checktls.com/TestReceiver etwas geändert, aber immer noch nicht Grün sondern Gelb:

Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Perfect Forward Secrecy: yes
Session Algorithm in use: Curve X25519 DHE(253 bits)

Certificate #1 of 1 (sent by MX):
Cert VALIDATION ERROR(S): unable to get local issuer certificate
This may help: What Is An Intermediate Certificate
So email is encrypted but the recipient domain is not verified


Cert Hostname VERIFIED (mailunity.domain.com = mailunity.domain.com | DNS:mailunity.domain.com)
Not Valid Before: May 14 00:00:00 2025 GMT
Not Valid After: May 13 23:59:59 2026 GMT
subject: /CN=mailunity.domain.com
issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte TLS RSA CA G1
002.253] ~~> EHLO www11-do.CheckTLS.com
[002.453] <~~ 250-nmg.domain.com
250-PIPELINING
250-SIZE 104857600
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SMTPUTF8
250 CHUNKING
[002.453] TLS successfully started on this server
[002.453] ~~> MAIL FROM:<test@checktls.com>
[002.559] <~~ 250 2.1.0 Ok
[002.559] Sender is OK
[002.559] ~~> QUIT
[002.666] <~~ 221 2.0.0 Bye

Warum tritt dieser Fehler noch auf?

ich habe von meinem Zertifikat-Provider 3 Zertifikate bekommen:
Zertifikat, Zwischenzertifikat, Root-Zertifikat

Genommen habe ich wie immer das Zertifikat.
 

Attachments

  • Bildschirmfoto 2025-05-14 um 15.49.00.png
    Bildschirmfoto 2025-05-14 um 15.49.00.png
    48.3 KB · Views: 2
Last edited:
Also das Mail Gateway steht hinter einer Lancom UF360 Hardware Firewall. So wie alle Server in diesem Netzwerk.

Welche Ports in der Firewall müssen offen sein für das Mail Gateway?

Aktuell habe ich nur den Port 25 in der DMZ und somit von aussen erreichbar.

Ich habe jetzt einmal noch 465 und 587 in die DMZ gepackt.

Aber leider auch keine Verbesserung.
 
Last edited:
Normalerweise wird ein intermediate cert für die Ausstellung weiterer certs verwendet. Das reguläre cert sollte reichen bzw. verwendet werden. SMTP connections server to server laufen über Port 25.
 
  • Like
Reactions: magicpeter
Normalerweise wird ein intermediate cert für die Ausstellung weiterer certs verwendet. Das reguläre cert sollte reichen bzw. verwendet werden.
Ja, so habe ich es gemacht, aber leider erscheint immer noch diese Warnung. Das stört mich echt.
Ich hätte gerne alle Punkte Grün.

Wie sieht es denn bei euch aus wenn Ihr einen Test mit https://www.checktls.com/TestReceiver und euerer Domain macht?
Ist das alles Grün bei euch?
Oder bekommt ihr auch Warnungen.
 
Normalerweise wird ein intermediate cert für die Ausstellung weiterer certs verwendet. Das reguläre cert sollte reichen bzw. verwendet werden. SMTP connections server to server laufen über Port 25.
Was sagt denn diese Meldung aus:

Certificate #1 of 1 (sent by MX):
Cert VALIDATION ERROR(S): unable to get local issuer certificate
This may help: What Is An Intermediate Certificate
So email is encrypted but the recipient domain is not verified

Sollte ich viele doch das Zwischenzertifikat nutzen?
 
Die Certificate Chain eurer Server ist unvollstaendig im TLS-Handshake vorhanden. Wenn ihr euch ein Zertifikat fuer einen Server bzw. DNS-Namen von einer CA signieren lasst, dann macht diese das in aller Regel ueber ein sogenanntes "Intermediate Certificate" - das ist eine Zwischenstation in der kryptographischen Vertrauenskette zwischen dem Root Certificate (= die Kronjuewelen der CA) und dem fuer euch erstellten Leaf Certificate. Wenn das Intermediate Cert in eurer Konfiguration fehlt, kommt es dann am Client zu diesem Problem bei der Validierung, weil ihm der Weg vom Zertifikat eures Servers bis zum Root Certificate der CA nicht klar ist.

Als Admin muss man dafuer Sorge tragen, dass der eigene Server, der sich mit einem von CA XYZ signierten Zertifikat ausweist, alle zur Nachvollziehbarkeit der Vertrauenskette bis zum Root Certificate der CA notwendigen Intermediate Certificates korrekt konfiguriert hat und beim TLS Handshake an den verbindenen Client ausliefert. In der Praxis bedeutet das, dass ihr in der Konfiguration eures TLS-Server nicht nur das einsame Leaf Certificate fuer euren Server haben werdet muessen, sondern auch noch (mindestens) ein Intermediate Cert der CA, wo ihr euch signieren habt lassen.

Normalerweise schickt euch die CA die gesamte notwendige Certificate Chain zu, wenn ihr von ihr auch das signierte Leaf Certificate zugestellt bekommt (viel Let's Encrypt-Clients legen dazu bis zu drei Files pro signiertem Zertifikat an - einmal nur das Leaf, einmal nur dessen Certificate Chain, einmal alles - Leaf und Chain - in einem Bundle. Letzteres braucht ihr fuer euer Zertifikat von eurer CA fuer euren Server - dann klappt es auch mit der Validierung. Schaut am besten nochmal in die Mail, mit der ihr das signierte Leaf fuer euren Server von der CA erhalten habt, da ist das wahrscheinlich mit drin.

Generell wuere ich euch raten, auf Let's Encrypt zu wechseln - da automatisiert man das ein Mal, und hat dann Ruhe :)
 
Last edited: