Hallo zusammen, ich teste von Zeit zu Zeit meinen Server über internet.nl. Dabei tauchen nun zwei Fehler auf: > Verdict: > At least one of your mail servers supports one or more insufficiently secure hash functions for key exchange. > > Technical details: > Mail server (MX) Outdated hash function > mail.xxxxxx.yyyy. SHA1 > Test explanation: > We check if your receiving mail servers (MX) support secure hash functions to create the digital signature during key exchange. > > The receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function. > > Note that this subtest is only relevant for TLS 1.2. The supported hash functions can be configured via a separate TLS setting (e.g. SignatureAlgorithms in OpenSSL) and are not part of the cipher suite configuration. > > For more details on the status of SHA-1 and MD5, see RFC 9155. We do not test for MD5 because it is only supported by very outdated software. > > See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.3.5. > > Security level of hash functions for key exchange > > Good: SHA-256, SHA-384, SHA-512 > Phase out: SHA-224 (rarely used) > Insufficient: SHA-1, MD5 Sowie: > Verdict: > The public key of at least one of your mail server certificates is based on a signing algorithm with parameters that should be phased out as they are weaker, although you might still use them if absolutely needed. In a future update, they will likely become insufficient. > > Technical details: > Mail server (MX) Outdated signature parameter > mail.xxxxxx.yyyy. R13: RSAPublicKey-2048 > ... phase out > Test explanation: > We check if the public key of your mail server certificate and every intermediate certificate is based on a secure signing algorithm with secure parameters. > > The verification of certificates makes use of digital signatures. The public key of a certificate can be used to verify that a signature was created using the corresponding private key. > > Signing algorithm: The signing algorithm is determined when generating the certificate. A certificate can only contain one signing algorithm. It is possible to configure multiple certificates on a server to support more than one algorithm. Only the signing algorithms ECDSA, RSA and EdDSA are considered sufficiently secure. EdDSA is actually rarely, if ever, used. All mentioned algorithms are vulnerable to the quantum threat. They offer sufficient protection for now. Quantum-safe alternatives are not yet part of the TLS standards. > > Parameters: The security of ECDSA and EdDSA digital signatures depends on the chosen curve. The security of RSA is tied to the key length of the public key. > > For details on the relevant certificate field name see paragraph "4.1.2.7. Subject Public Key Info" of RFC 5280. > > See 'Transport Layer Security (TLS), Security guidelines version 2025-05' from NCSC-NL, paragraph 3.3.2 > > Security level of elliptic curves for ECDSA > > Sufficient: > > secp521r1 (rarely used) > secp384r1 > secp256r1 > x448 > x25519 > brainpoolP512r1 (rarely used) > brainpoolP384r1 (idem) > brainpoolP256r1 (idem) > Phase out: > > secp224r1 > Insufficient: > > Other curves > Security level of length of RSA keys > > Sufficient: At least 3072 bit > Phase out: 2048 – 3071 bit > Insufficient: Less than 2048 bit > Security level of Edwards curves for EdDSA (rarely used) > > Sufficient: > > Ed448 > Ed25519 > Insufficient: > > Other curves Dazu gab es die folgenden Support Beiträge welche nicht mehr aktuell sind: https://docs.mailcow.email/de/manual-guides/Postfix/u_e-postfix-harden_ciphers/ https://docs.mailcow.email/de/manual-guides/Dovecot/u_e-dovecot-harden_ciphers/ Kann mir jemand sagen was ich wo ändern muss damit mein Server wieder als grün angezeigt wird?

Puuuh. 🤔🤔🤔🤔🤷♂️🤷♂️🤷♂️ Lt. internet.nl kann ich mich der Frage nur anschließen. Sieht bei unserem System auch nicht ganz optimal aus. Jedoch große Testsysteme wie z. B. mxtoolbox.com kommen zu einem gegenteiligen Ergebnis. Ich habe zwar keine Verbesserung unseres Mailservers erreicht, dafür weiß ich jetzt, was ein Bimi-Logo ist 😂😂😂

@"Hindin-The-G"#p32114 hi. I've opened a request on Github to improve the Mailcow encryption suite, so you can get it again https://github.com/mailcow/mailcow-dockerized/issues/7208

@"Cisco30"#p32131 Vielen Dank für das erstellen des GitHub Issues! Ich bin gespannt, ob angepasst wird.

Guten Morgen, ich konnte zumindest den ersten Fehler beheben. Ich bin wie folgt vorgegangen: Datei anpassen oder erstellen: `/opt/mailcow-dockerized/data/conf/postfix/openssl.cnf` das muss rein: `openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] MinProtocol = TLSv1.2 CipherString = DEFAULT@SECLEVEL=2 #DAS IST DER FIX: SignatureAlgorithms = RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384` Dann In docker-compose.override.yml folgendes ergänzen: `services: postfix-mailcow: volumes: - ./data/conf/postfix/openssl.cnf:/etc/ssl/openssl.cnf:ro` Dann alles neu starten und danach war be mir das erste Finding gelöst. Allerdings kann nun mein Ceph Cluster keine E-Mails mehr an Mailcow abliefern, es kommt dann folgender Fehler: [upl-image-preview uuid=f7a64153-54c3-43bb-b961-9f29d23cdfed url=https://community.mailcow.email/assets/files/2026-04-30/1777529770-965125-cleanshot-2026-04-30-at-081558-at-2x.png alt={TEXT?}] Also erhöhte Sicherheit nimmt sich dann wieder die Balance mit Produktivität.

Die Einstellungen sollten standardmäßig "intermediate" sein. Servercow sollte in jedem Fall die neusten Cipher-Suites anbieten, sowie sämtliche veralteten und überholten Cipher als gesperrt abweisen. Was zeigt es eigentlich bei https://www.ssllabs.com/ssltest/ bei Euch an? Kann ich selbst nicht gegentesten, da hier Port 443 getestet wird und bei uns ein Reverse-Proxy antwortet.

Bei mir wird A+ angezeigt, was auch immer das bedeuten mag

@"Ganzjahresgriller"#p32136 Das Bedeutet "sehr gut". Also verwendet Ngix entweder bessere Cipher-Suites als per TLS over SMTP angeboten wird. Oder die Bewertungsmethode von internet.nl ist zu hart. Es bringt ja (noch) nichts alleinig die modernsten Cipher anzubieten, wenn 80% der großen Mailserver noch nicht umgestellt wurden. Somit endet die Nachrichtenzustellbarkeit sehr schnell. 😅😅

Bei mir auch. Aber die testen ja nur den Web Server, wo ja wiederum andere Cyphers konfiguriert sein können als für Postfix und Dovecot. Hier trotzdem noch das Rating und die Ciphers aus dem Test von SSL Labs: [upl-image-preview uuid=ddbc5b0e-291c-4d6e-877d-00fb33271b0b url=https://community.mailcow.email/assets/files/2026-04-30/1777541357-470727-image.png alt={TEXT?}] [upl-image-preview uuid=2fbf1692-4e6e-4569-aaae-22980e12a9b0 url=https://community.mailcow.email/assets/files/2026-04-30/1777541389-977229-image.png alt={TEXT?}]

Irgendwas scheint internet.nl geändert zu haben bei mir schlägt bei den Tests der Netfilter zu und blockt deren IP. Im Log steht: 62.204.66.10 matched rule id 4 (warning: non-SMTP command from internet.nl[62.204.66.10]: GET _ HTTP_1.1) Das hat aber schon mal sehr gut funktioniert.

@"mlcwuser"#p32138 So wird es vermutlich auch sein. Dass Ngix auf einen neuen Stand gebracht wurde, das "alte" SMTP Protokoll aber vernachlässigt.

mailcow Ciphers verstärken nicht merh aktuell

CK_beats

Postfix log:

08.05.2026, 18:50:51 postfix/smtpd: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher:../ssl/statem/statem_srvr.c:2220:
08.05.2026, 18:50:51 postfix/smtpd: SSL_accept error from internet.nl[62.204.66.10]: -1

😂😂😂😂😂
Jetzt ist komplett Ruhe.

Becker884

also jetzt hast du auch 100% ?

CK_beats

Eher 0%. 😂😂😂😂
Ich vermute, da ssl_prefer_server_ciphers = yes aktiviert ist werden serverseitig unsererseits erst einmal keine Cipher-Suites mehr offeriert? 🤔🤔
Keine Ahnung.
SHA-1 ist draußen. Das wird bestätigt. Sonst nichts mehr.
Außerdem bemängelt es immer noch, dass die Zertifikatskette ein abgelaufenes R13 Zertifikat enthält, was definitiv nicht stimmt.

Wenn ich hingegen dieses Tool https://www.checktls.com/TestReceiver nutze,
MTA-STS ebenfalls prüfe, sowie auf die SNI, das Ganze auf IPv4 und -v6 liegen wir bei 100%.
Einzig DANE funktioniert nicht, sowie DNSSEC, da unser DNS-Provider das nicht unterstützt.

Aber:
Serverseitig hat sich in jedem Fall etwas geändert. Unser Scanner konnte den Mailserver nicht mehr kontaktieren. Hier war SSL aktiviert und vermutlich sind nur alte Cipher installiert. Verbindung schlug fehl, was aber zuvor funktionierte.
Müsste hier bei Minolta nach einem Update fragen.
Habe einfach Verschlüsselung komplett deaktiviert. Läuft jetzt plain auf Port 25. Ist aber eh internes Netz, von daher…

Becker884

So schauts bei mir aus

Zuhause entsprechend Punktabzug:

wegen rDNS

CK_beats

So muss es sein!
Dann ist die volle Funktion in Bezug auf Zustellbarkeit & (hoffentlich auch) Sicherheit gegeben!

« Previous Page