Passer au contenu 
Je te montre comment Serveur de messagerie TLS dans Postfix et de choisir des suites de chiffrement puissantes pour que les connexions SMTP soient systématiquement protégées. Sur la base de paramètres éprouvés pour TLS 1.2/1.3, DANE, MTA-STS et des paires de clés modernes, je te guide pas à pas à travers la configuration, les tests et le réglage, afin que ta connexion soit sécurisée. sécurité de la messagerie s'accroche proprement.
Points centraux
- Postfix configurer en toute sécurité : Activer TLS, limiter les protocoles, définir la journalisation.
- Cipher établir des priorités : ECDHE + GCM/CHACHA20, forcer le PFS, bloquer les charges héritées du passé.
- Certificats garder propre : RSA+ECDSA, chaîne complète, courbes fortes.
- DANE/MTA-STS utiliser les ressources : Ancrer les politiques et réduire les risques de déclassement.
- Tests et surveillance : vérifier régulièrement OpenSSL, le scanner TLS, les logs MTA.
SMTP sur TLS : ce qui est vraiment sécurisé
Je sécurise SMTP avec STARTTLS, pour que le transport des e-mails ne se fasse pas en texte clair. TLS opportuniste par smtpd_tls_security_level = may veille à ce que les connexions entrantes utilisent le cryptage dès que l'autre partie le propose. Pour les livraisons sortantes, j'utilise smtp_tls_security_level = dane sur des contrôles de politique basés sur le DNSSEC afin de rendre plus difficiles les attaques de déclassement. Sans TLS, les e-mails seraient lisibles et manipulables pendant le transport, ce qui est particulièrement dangereux pour les formulaires, les commandes ou les données de compte. Avec TLS actif en permanence, je réduis nettement les risques d'interception et de MITM, et j'obtiens de meilleurs taux de distribution, car les grands fournisseurs évaluent positivement les connexions sécurisées.
Clés, certificats et protocoles dans Postfix
Je tiens deux certificats à disposition : un RSA-et un certificat ECDSA, afin que les anciens et les nouveaux MTA se connectent de manière optimale. Je définis clairement les chemins d'accès dans Postfix, par exemple smtpd_tls_cert_file pour RSA et smtpd_tls_eccert_file pour ECDSA, à chaque fois avec la clé correspondante. Pour une authentification propre, je fais attention à la chaîne complète, à un CN/SAN qui correspond exactement à l'hôte et à une courbe telle que secp384r1 pour la clé ECDSA. Je désactive strictement les protocoles plus anciens, c'est-à-dire SSLv2 et SSLv3, pour éviter les rétrogradations forcées. Si tu es en train de peser le type de certificat, un petit coup d'œil sur DV, OV ou EV, Pour choisir le niveau de confiance qui te convient, il te suffit de consulter le site web de l'association.
Choix du chiffrement : Priorités pour TLS 1.2/1.3
Je donne la priorité aux suites de chiffrement avec PFS, ECDHE avant DHE, et misez sur GCM ou CHACHA20-POLY1305. Sous TLS 1.3, la pile te débarrasse de nombreuses charges anciennes, tandis que TLS 1.2 continue à avoir besoin d'une liste claire. Les suites non sécurisées ou faibles comme RC4, Je supprime 3DES, CAMELLIA, aNULL, eNULL. Pour Postfix, j'utilise smtpd_tls_ciphers = haut et une politique restrictive tls_high_cipherlist, pour éviter que des algorithmes obsolètes ne passent à la trappe. Si tu veux aller plus loin, le Guide des suites de chiffrement un classement bien compréhensible sans lest.
| Version TLS | Suites de chiffrement préférées | Statut | Remarque |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | actif | Sélection fixe dans le protocole, plus d'héritage. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | actif | Donner la priorité au PFS, privilégier le GCM/CHACHA. |
| Obsolète | RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL | bloqué | Désactiver complètement pour des raisons de sécurité. |
Postfix : paramètres concrets pour main.cf
Je définis une configuration claire pour que le MTA parle en toute sécurité aussi bien en entrant qu'en sortant. Pour ECDH éphémère, je définis avec smtpd_tls_eecdh_grade fixe la qualité des courbes et je désactive la compression pour éviter les attaques de type CRIME. Un fichier DH fort de 4096 bits empêche les traitements DHE faibles. Je limite sévèrement les protocoles et j'impose une qualité de chiffrement élevée, en utilisant de préférence TLS 1.3. Au démarrage, un niveau de log modéré m'aide à vérifier les handshake sans inonder le journal.
# Activation et politique
smtpd_tls_security_level = may
smtp_tls_security_level = dane
# Certificats (exemples de chemins d'accès)
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.fr.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.fr.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.example.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key
# Protocoles et chiffrement
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = haut
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
# Paramètres DH
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (si disponible)
smtp_dns_support_level = dnssec
# Journalisation
smtpd_tls_loglevel = 1
Je maintiens la chaîne de certificats complète, je veille à ce que les droits soient corrects pour les privé fichiers de clés et vérifie les logs après le rechargement. Si TLS 1.2 est nécessaire pour les anciens partenaires, je m'en tiens strictement à GCM/CHACHA et je bloque tout le reste. Pour TLS 1.3, je mise sur les standards de la pile et j'évite les chemins spéciaux qui compliquent la maintenance. L'empilage OCSP ne joue un rôle dans SMTP que si un proxy en amont le met à disposition, c'est pourquoi je ne le vérifie que pour les configurations correspondantes. Après chaque modification, je valide avec OpenSSL afin de détecter rapidement les effets secondaires et d'éviter les erreurs. cryptage des e-mails de manière cohérente.
Authenticité du transport avec DANE, MTA-STS, SPF, DKIM et DMARC
Je combine TLS avec DANE, en publiant des enregistrements TLSA signés sous DNSSEC. En outre, je place des MTA-STS pour que les correspondants sachent que mon hôte demande TLS et à quel MX ils doivent se conformer. Pour la liaison d'identité, je signe les e-mails sortants avec DKIM et sécurise la livraison du domaine par le biais d'un ensemble de règles SPF. Enfin, DMARC définit la manière dont les destinataires doivent traiter les divergences, ce qui rend l'usurpation d'identité très difficile. Ces modules agissent ensemble : TLS protège le transport, tandis que l'authentification renforce l'expéditeur et augmente sensiblement le taux de livraison.
Si la performance est un goulot d'étranglement, j'optimise la résomption de session, les fonctions matérielles et le handshake lui-même. Tu peux te familiariser avec les astuces pratiques avec TLS handshake plus rapide, afin de réduire la latence lors de l'établissement de la connexion. Important : je maintiens un équilibre entre le choix du chiffrement et la résomption, car les compromis faibles ne sont pas payants en termes de sécurité. Une négociation TLS rapide permet de réaliser des économies substantielles, surtout en cas de volume de courrier élevé. Ainsi, il reste Débit et la sécurité en lot.
Tests, suivi et audits
Je vérifie les poignées de main localement avec openssl en contrôlant la version du protocole, le chiffrement et la chaîne de certificats. La commande openssl s_client -connect mail.example.de:25 -starttls smtp me montre en direct ce que le serveur opposé négocie. Après des changements de configuration, j'utilise contrôle postfix et regarde de manière ciblée smtpd_tls_loglevel, pour isoler les images d'erreur. Des scanners TLS externes aident à classer la visibilité publique, en particulier après un changement de certificat. Un rythme d'audit régulier protège contre les détériorations insidieuses, par exemple lorsqu'un changement de bibliothèque affecte les priorités de chiffrement.
Mauvaises configurations fréquentes et corrections rapides
Je vois souvent des chiffrement obsolètes comme AES128-SHA, qui sont encore actives et empêchent la PFS. Une chaîne de chiffrement stricte et le blocage clair de LOW/MD5/RC4/3DES aident ici. Deuxième modèle : absence de certificats intermédiaires, ce qui empêche les sites distants de vérifier la chaîne ; je complète le fichier bundle et je teste à nouveau. Sur des appareils tels qu'une Synology, je règle le profil TLS sur moderne et je supprime les options héritées pour que les serveurs SMTP parlent de manière moderne. Sur Microsoft Exchange, je contrôle de manière ciblée les politiques TLS 1.2/1.3, l'attribution des certificats par connecteur et les éventuels Cipher Overrides dans la configuration de l'hôte, afin que les Handshake-Le choix est bon.
Prévision de l'avenir : TLS 1.3, 0-RTT et post-Quantum
Je préfère TLS 1.3, car le handshake est plus court et les anciennes options sont supprimées, ce qui réduit les surfaces d'attaque. Le choix des cipher est clairement limitée et les piles modernes fournissent de bons paramètres par défaut. Je n'utilise pas 0-RTT dans le contexte SMTP, car les attaques répétées entraînent des risques inutiles. Pour l'avenir, j'observe des procédures hybrides post-quantiques qui pourraient faire leur entrée dans l'environnement de messagerie dès que la standardisation et le support auront mûri. Il est important que je mette en place des politiques et une surveillance de telle sorte que les nouvelles procédures puissent être intégrées ultérieurement sans rupture.
Performance et taux de distribution en vue
Je mesure la Latence du handshake TLS et optimiser les caches pour permettre les réutilisations. La résomption de session (tickets/IDs) réduit la charge de calcul et accélère les connexions récurrentes entre les MTA. Pour la révocation de certificats, je mise sur des informations empilables au niveau du proxy en amont, si disponible, afin d'économiser des accès supplémentaires. Les grands destinataires évaluent positivement les transports sécurisés, ce qui renforce le taux de livraison, tandis que les chemins non sécurisés augmentent les risques de spam et de rejet. Avec une politique TLS claire, des enregistrements DNS solides et une chaîne de signature propre, je pose une base fiable pour Délivrabilité.
Ma feuille de route pour la configuration
Je commence par obtenir un certificat auprès d'une autorité de certification de confiance, je génère ECDSA et RSA et je les dépose proprement sur l'hôte. Ensuite, j'adapte les main.cf avec les paramètres TLS, en définissant des crypteurs forts et en désactivant les anciens protocoles. Un nouveau fichier DH de 4096 bits est ajouté, suivi d'un rechargement et des premières vérifications OpenSSL. Ensuite, je configure DANE, j'ajoute MTA-STS et je vérifie la validité de SPF/DKIM/DMARC. Enfin, j'effectue des tests par rapport à des cibles externes, je vérifie les logs en cours d'utilisation et je prévois des audits réguliers pour que les Configuration reste sûr à long terme.
Modules manquants : Soumission, SMTPS et SNI
Je ne sécurise pas seulement le port 25, mais aussi la soumission (587) et, en option, le SMTPS (465). Pour la soumission, je force le cryptage et l'authentification afin que les mots de passe des utilisateurs ne partent jamais en texte clair. Dans master.cf j'active les services et je mets des overrides ciblés :
# Soumission (port 587) avec STARTTLS et Auth obligatoire
soumission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
# SMTPS (port 465) en mode wrapper si nécessaire
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
Si je sers plusieurs domaines de messagerie sur un hôte avec mes propres certificats, j'utilise SNI. Avec une carte SNI, j'attribue le chemin de certificat approprié à chaque hôte cible et je m'assure que les clients MUA voient également le certificat correct. Je peux ainsi garantir la séparation des mandants et la cohérence de l'identité TLS.
Politiques par domaine : contrôle granulaire fin
En plus de la politique globale, je gère avec smtp_tls_policy_maps Exceptions et renforcements par domaine destinataire. Cela me permet de migrer progressivement des partenaires hérités ou d'imposer des directives particulièrement strictes pour des cibles sensibles.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (entrées d'exemple)
example.org dane-only
legacy.example.net may
secure.example.com secure
dane-only impose une protection DANE sans dépendance CA, secure exige une chaîne de CA valide et refuse la livraison en texte clair, may reste opportuniste. Après des modifications, je construis la map avec postmap et recharge Postfix.
DANE et MTA-STS : mise en œuvre concrète
Pour DANE je publie des enregistrements TLSA sous DNSSEC. J'utilise de préférence DANE-EE (3 1 1), car il permet des épinglages sur la clé publique et facilite les changements de certificats avec la même clé. Un exemple d'enregistrement TLSA sous _25._tcp.mail.exemple.fr ressemble à ceci :
_25._tcp.mail.exemple.fr. IN TLSA 3 1 1
Je génère le hachage à partir du certificat ECDSA ou RSA et je veille à le faire tourner avant l'expiration. Il est important que la zone DNS soit signée et que la chaîne des délégations soit validée sans faille.
Pour MTA-STS j'héberge le fichier de politique via HTTPS et je complète l'entrée TXT-DNS. Je détermine ainsi que les sites distants parlent TLS et ne sont acceptés qu'avec des MX définis. Un fichier de politique minimaliste :
version : STSv1
mode : enforce
mx : mail.exemple.fr
max_age : 604800
Pour cela, un enregistrement TXT est ajouté dans le DNS sous _mta-sts.exemple.fr avec la version actuelle. En option, je mets en place TLS-RPT par TXT sous _smtp._tls.exemple.fr pour obtenir des rapports sur les violations de politique. Cette télémétrie m'aide à détecter rapidement les échecs, les rétrogradations et les certificats défectueux.
Renforcer les protocoles, préciser le chiffrement
Je renforce les limites des protocoles et impose la préférence du serveur. Les TLS 1.0/1.1 sont aujourd'hui superflus ; je n'autorise plus que les TLS 1.2 et 1.3. Pour TLS 1.2, je définis une liste positive explicite afin d'exclure les stocks mixtes d'anciens chiffres :
# Durcissement supplémentaire (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Liste explicite de chiffrement TLS 1.2 (PFS + AEAD uniquement)
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!MD5:!RC4:!3DES:!CAMELLIA
# Utiliser la préférence de serveur
tls_preempt_cipherlist = yes
Je m'assure que ECDHE est privilégié et que DHE n'est plus qu'une solution de repli. Je tiens mon fichier DH à jour ; sous TLS 1.3, il ne joue aucun rôle, mais il reste utile pour les rares opérations DHE.
Résumés de session et caches
Pour accélérer les choses, j'active les caches de session pour le client et le serveur afin de réduire les coûts de reconnexion. La charge de l'unité centrale et la latence diminuent sensiblement, en particulier lorsque le débit de messagerie est élevé :
# Cache de session (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = yes
J'observe le taux de réussite dans les logs et je m'assure qu'il n'y a pas d'informations trop courtes. ticket_lifetimes dans la librairie TLS pour freiner Resumption. Important : Resumption ne doit pas affaiblir la politique ; je reste sur des exigences de chiffrement identiques.
Entreprise certifiée : rotation et entretien de la chaîne
J'automatise le renouvellement et le rechargement du MTA afin d'éviter que des certificats expirés ne se retrouvent dans l'entreprise. Après chaque renouvellement, je vérifie que la feuille et les certificats intermédiaires se trouvent entièrement dans le bundle. Pour le double ECDSA/RSA, je m'assure que les deux paires tournent avant qu'un changement en masse ne pose problème aux clients. Je teste le chemin SNI et la soumission séparément, car les MUA peuvent présenter des images d'erreur différentes de celles des MTA.
Approfondir le logging et le diagnostic
J'augmente temporairement la profondeur des logs lorsqu'un problème survient et j'utilise des outils de bord pour les recoupements :
# journalisation ciblée (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
Avec posttls-finger cible.exemple.com je vérifie quelle politique est attendue par un MTA distant et quels chiffrement/protocole sont négociés. J'utilise postconf -n | grep tls, pour ne voir que les paramètres TLS explicitement définis ; je trouve ainsi plus rapidement les différences par rapport aux valeurs par défaut. Dans les logs, je recherche des termes tels que pas de cryptogramme partagé, certificate verify failed ou version du protocole, Les messages d'alerte sont des messages qui indiquent directement des mésappariements de chiffrement, des problèmes de chaîne ou des limites de protocole trop strictes ou trop souples.
Gérer la compatibilité sans sacrifier la sécurité
Je planifie les transitions en toute connaissance de cause : je m'arrête en priorité sur may, J'ai choisi de ne pas perdre les e-mails des anciens serveurs, mais de consigner les livraisons en texte clair. En partant de là, je reste strict (DANE/MTA-STS/secure) et j'utilise smtp_tls_policy_maps pour les cas particuliers. Si des partenaires isolés ne parviennent à mettre en place que TLS 1.2 avec AES-GCM, c'est supportable ; tout ce qui est en dessous, je le gère par le biais d'exceptions concertées avec une durée limitée, je les documente et je les intègre dans la planification de la migration. Ainsi, le niveau global reste élevé sans bloquer l'activité commerciale.
Vue d'ensemble des défauts TLS du système
Je note que Postfix utilise la bibliothèque TLS du système. Les mises à jour d'OpenSSL/LibreSSL peuvent modifier les priorités de chiffrement et le comportement TLS 1.3. Après les mises à jour du système, je vérifie donc de manière aléatoire les handshake et compare la sortie de postconf -n avec mes valeurs de consigne. Un réglage niveau_de_compatibilité dans Postfix aide à maintenir des valeurs par défaut stables, mais je ne m'y fie pas aveuglément et je documente les écarts explicites dans le main.cf/master.cf.
Bilan succinct pour les administrateurs
Je retiens que des chiffres forts avec PFS, des certificats propres et des politiques claires sont essentiels pour SMTP décisif. TLS 1.3 te libère des charges héritées du passé, tandis que TLS 1.2 exige une liste de chiffrement disciplinée. DANE et MTA-STS durcissent le chemin de transport, SPF/DKIM/DMARC sécurisent l'identité et le reporting. Des tests réguliers et des analyses de logs montrent rapidement si une modification entraîne des effets secondaires indésirables. Grâce à ce guide, tu peux mettre en place ton serveur de messagerie de manière sûre, performante et durable - sans dépenses inutiles. Risques.
