TLS pour les e‑mails : pourquoi un « certificat valide » échoue encore (et la vraie solution)

Ce que « certificat valide » signifie réellement dans l’univers SMTP

Quand quelqu’un dit « le certificat est valide », il veut généralement dire : la signature du certificat de feuille se vérifie, il n’est pas expiré,
et il se rattache à une racine de confiance dans certains clients. C’est le minimum. SMTP ajoute d’autres façons d’être incorrect.

Dans l’e‑mail, l’identité TLS du serveur est liée aux noms DNS, au comportement des MX et à la politique. Certains clients valident strictement les noms.
D’autres non. Certains tiennent compte du SNI. D’autres ne peuvent pas gérer le SNI. Certains appliquent des suites modernes. D’autres restent coincés en 2012 mais livrent encore le courrier d’une banque.
« Valide » est un spectre, et le MTA distant choisit où il trace la ligne.

Faits et contexte historique intéressants (brefs, concrets et utiles)

• STARTTLS pour SMTP a été normalisé en 2002 (RFC 3207). Il a été conçu pour une montée en sécurité opportuniste, pas pour une application stricte.
• SMTP a initialement été livré sans chiffrement parce que l’Internet primitif supposait un environnement coopératif ; le chiffrement a été ajouté après coup.
• Le « TLS opportuniste » est devenu la norme pendant des années : chiffrer si possible, retomber en clair sinon. Parfait pour la délivrabilité, médiocre pour la confidentialité.
• Les vérifications de nom de certificat ont historiquement été incohérentes entre les MTAs. Cette incohérence explique pourquoi « ça marche avec Gmail » n’est pas un test de certificat.
• Le SNI est arrivé plus tard que beaucoup de piles SMTP. Certains anciens MTAs n’envoient toujours pas de SNI, ce qui compte sur des serveurs multi‑locataires.
• La Perfect Forward Secrecy s’est généralisée après 2013. Des préférences de chiffrement plus anciennes peuvent encore casser l’interopérabilité quand une partie désactive trop agressivement les options « legacy ».
• MTA-STS est relativement récent (RFC 8461, 2018) et a déplacé une partie du TLS e‑mail du « meilleur effort » vers une application basée sur la politique.
• DANE pour SMTP existe (enregistrements TLSA, RFC 7672) et peut imposer TLS sans CA publique—utile, jusqu’à ce que DNSSEC ne soit pas vraiment déployé de bout en bout.
• Beaucoup de MTAs considèrent encore le port 465 comme « SMTPS » pour l’usage type soumission, tandis que le port 25 reste centré sur STARTTLS pour serveur à serveur.

Il y a une incompatibilité fondamentale : le web est « client vers un seul nom de serveur », tandis que SMTP est « serveur vers le ou les noms retournés par les MX DNS,
potentiellement multiples, changeants, ou derrière des load balancers ». Les certificats détestent l’ambiguïté. SMTP l’adore.

Une citation à garder en tête pendant le debugging : L’espoir n’est pas une stratégie. (idée paraphrasée attribuée à la culture des opérations, largement utilisée en SRE et gestion de projet)

« Valide » est ce que la partie distante accepte. Votre travail consiste à prédire ce qu’une grande variété de pairs distants acceptera—puis à configurer en conséquence.

Mode d’emploi pour un diagnostic rapide (vérifiez ceci, puis cela)

Quand le TLS mail casse, vous pouvez perdre des heures en débogage intuitif. Ne le faites pas. Exécutez ceci dans l’ordre et vous trouverez généralement le goulot rapidement.

1. Première étape : confirmez quel nom est validé.
   • Vous connectez‑vous à mx1.example.com, mail.example.com, ou au domaine nu ?
   • Le certificat couvre‑t‑il ce nom exact via les SAN ?
   • Êtes‑vous derrière un load balancer ou un proxy qui change le point de terminaison TLS ?
2. Deuxième étape : capturez la handshake que voit le MTA distant.
   • Utilisez openssl s_client avec STARTTLS et (si applicable) SNI.
   • Vérifiez la présentation de la chaîne : feuille + intermédiaire(s), dans le bon ordre.
3. Troisième étape : lisez vos logs MTA pour la gestion des politiques.
   • La partie distante applique‑t‑elle MTA-STS, DANE, ou « TLS requis » pour la soumission ?
   • Votre côté applique‑t‑il des vérifications de nom d’hôte ou des versions minimales de TLS ?
4. Quatrième étape : vérifiez le recoupement des protocoles et des suites de chiffrement.
   • TLSv1.2 est le plancher pour beaucoup de MTAs modernes ; TLSv1.0/1.1 sont de plus en plus refusés.
   • Mais désactiver tout sauf TLSv1.3 peut nuire si le pair est ancien.
5. Cinquième étape : éliminez le « c’est le firewall » avec des preuves.
   • Confirmez les ports, la NAT, et tout dispositif d’interception/inspection TLS.
   • Vérifiez la MTU/fragmentation si vous voyez des blocages étranges au milieu de la handshake.

Blague n°1 : Le dépannage TLS pour e‑mail est comme un roman policier où le coupable est toujours « un intermédiaire manquant », portant un chapeau différent à chaque chapitre.

Pourquoi TLS échoue même avec un certificat valide

1) Incompatibilité de nom d’hôte : le certificat est valide, juste pas pour ce nom MX

C’est le problème numéro un du « mais il est valide ! ». Le certificat peut être valide pour mail.example.com,
tandis que le MTA expéditeur se connecte à mx1.example.com. Ou il se connecte au domaine indiqué dans l’enregistrement MX qui pointe vers
un nom fournisseur dont vous avez oublié l’existence. La chaîne est correcte ; l’identité est incorrecte.

SMTP ajoute une subtilité : beaucoup de MTAs valident par rapport au nom auquel ils se sont connectés (la cible MX), pas par rapport à ce que le serveur annonce dans la bannière SMTP.
La bannière peut être honnête et néanmoins hors sujet.

Correction : mettez les noms des hôtes MX dans les SAN du certificat, ou changez les MX vers un nom que vous contrôlez et que vous pouvez certifier.
« Ça marche dans mon navigateur » n’a aucun sens si votre navigateur ne se connecte jamais au nom MX.

2) Intermédiaire manquant : les navigateurs le récupèrent, les MTAs souvent non

Les navigateurs modernes sont très tolérants. Ils mettent en cache les intermédiaires, les récupèrent via AIA, et comblent les configurations de serveur bâclées.
Beaucoup de MTAs, par conception, ne font pas de récupération AIA. Ils s’attendent à ce que le serveur présente une chaîne complète.

C’est pourquoi un certificat peut se vérifier sur votre portable et échouer en production de messagerie.
Le MTA distant tourne sur une ancienne version d’OpenSSL dans un conteneur avec un store de confiance minimal et sans récupération AIA.
Il voit la feuille, ne peut pas construire la chaîne, et la rejette.

Correction : configurez votre MTA pour présenter feuille + intermédiaires dans le bon ordre. N’incluez pas la racine.

3) SNI et points de terminaison multi‑locataires : vous obtenez le certificat « par défaut »

Si plusieurs domaines partagent une IP, le serveur a besoin du SNI pour choisir le bon certificat. Beaucoup de clients SMTP envoient maintenant le SNI,
mais pas tous. Certains anciens MTAs se connecteront sans SNI et recevront le certificat par défaut, qui peut être valide, mais pas pour vous.

La partie amusante : cela peut être intermittent. Certains expéditeurs réussissent (ils envoient le SNI), d’autres échouent (ils ne l’envoient pas). Vous obtenez une histoire de fantômes dans les logs.

Correction : définissez le certificat par défaut pour couvrir en toute sécurité le nom MX principal, ou dédiez des IPs pour le mail quand c’est possible.
Si vous devez faire du multi‑tenancy, testez avec et sans SNI.

4) Incompatibilité de version TLS et suites de chiffrement : « moderniser » peut signifier « casser le mail »

Les équipes de sécurité aiment les guides de durcissement. Les SRE aiment ne pas être appelés à 2h du matin. Ces amours ne s’alignent pas toujours.
Si vous désactivez TLSv1.2 ou retirez des suites de chiffrement courantes, vous pouvez laisser sur le carreau des expéditeurs plus anciens mais légitimes.

De l’autre côté, si le pair exige TLSv1.2+ et que votre pile est bloquée sur TLSv1.0, vous êtes le legacy.
Cela se manifeste par des échecs de handshake, des alertes de version de protocole ou des erreurs de négociation de chiffrement.

Correction : gardez TLSv1.2 activé sur les serveurs SMTP. TLSv1.3 est excellent, mais n’en supposez pas le support universel.
Désactivez les suites connues comme faibles, mais conservez un ensemble de recouvrement sensé.

5) Confusion sur la politique STARTTLS : opportuniste vs requis

STARTTLS a été conçu pour être opportuniste. Cela signifie : si le chiffrement échoue, le mail peut quand même être livré en clair.
Mais plusieurs mécanismes peuvent modifier ce comportement :

• Soumission (587) exige souvent TLS, car elle transporte des identifiants utilisateur.
• Transport partenaire à partenaire peut imposer TLS via une politique explicite ou des paramètres de connecteur.
• MTA-STS indique aux expéditeurs : « Livrez uniquement vers moi via TLS valide, ou ne livrez pas. »
• DANE peut imposer TLS au niveau DNS (lorsque DNSSEC valide).

Vous pouvez donc avoir un certificat « valide » qui échoue parce que la politique exige la validation du nom d’hôte, ou un nom particulier,
ou une chaîne particulière, pas seulement le chiffrement.

6) Nom EHLO/HELO incorrect et reverse DNS : pas TLS, mais souvent confondu avec TLS

Celui‑ci fait perdre du temps parce qu’il se trouve à côté des erreurs TLS dans les logs. Certains MTAs refuseront ou pénaliseront
les connexions avec un rDNS défaillant, un HELO incohérent, ou des bannières génériques. Cela peut ressembler à un « problème TLS »
alors qu’il s’agit en réalité d’un problème d’identité/réputation.

Correction : alignez PTR (reverse DNS), A/AAAA forward, et le nom HELO que votre serveur utilise. Cela ne réparera pas une chaîne cassée,
mais réduira le bruit pendant que vous réparez TLS.

7) Middleboxes : inspection TLS, NAT et firewalls « utiles »

STARTTLS SMTP déclenche particulièrement les middleboxes d’entreprise qui pensent que tout devrait ressembler à du HTTPS.
Certains appareils ébrèchent la négociation STARTTLS, suppriment des extensions, ou réinitialisent les connexions quand ils voient des handshakes inhabituels.

Correction : contournez l’inspection TLS pour SMTP, ou utilisez un chemin qui ne traverse pas le dispositif d’inspection.
Si vous ne pouvez pas, préparez‑vous à souffrir et documentez chaque exception ajoutée.

8) Mauvais format de certificat / clé non correspondante / permissions : basique mais réel

Le certificat peut être valide et pourtant ne pas se charger. Postfix, Exim, et d’autres échoueront ouvertement ou fermeront selon la configuration.
Si votre service retombe en clair ou présente un certificat par défaut parce qu’il ne peut pas lire le bon, vous aurez des symptômes confus.

Correction : vérifiez que le service en cours d’exécution utilise bien le fichier que vous pensez et que la clé correspond.

9) DANE et MTA-STS : quand les règles changent sous vos pieds

DANE avec DNSSEC permet d’autoriser des certificats auto‑signés ou de CA privée si l’enregistrement TLSA correspond. C’est puissant—et fragile.
Vous faites une rotation de certificat et oubliez de mettre à jour TLSA ? Vous venez de vous infliger votre propre panne.

MTA-STS est différent : il repose toujours sur la PKI publique, mais il impose la « validité du certificat » et le « nom correct » d’une manière que le TLS opportuniste ne fait pas.
Si vous publiez une politique MTA-STS et que vos points de terminaison MX ne sont pas constamment corrects, vous verrez des échecs de livraison soudains chez les expéditeurs qui la respectent.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici des vérifications de qualité production. Ce n’est pas de la théorie. Exécutez‑les, lisez la sortie, décidez de la suite.
Les commandes supposent un serveur Linux avec des outils courants.

Tâche 1 : Voir quel certificat votre serveur SMTP présente réellement (STARTTLS sur 25)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts -verify_return_error
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R11
verify return:1
depth=0 CN=mail.example.com
verify return:1
---
Certificate chain
 0 s:CN=mail.example.com
   i:C=US, O=Let's Encrypt, CN=R11
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C=US, O=Let's Encrypt, CN=R11
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
...

Ce que cela signifie : Le CN du certificat de feuille est mail.example.com, mais vous vous êtes connecté à mx1.example.com.
Si les SAN n’incluent pas mx1.example.com, les expéditeurs stricts vous rejeteront.

Décision : Réémettre un certificat qui inclut les noms MX en SAN, ou changer les MX pour correspondre au certificat.

Tâche 2 : Vérifier explicitement la couverture SAN

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com 

cr0x@server:~$ openssl x509 -noout -text | sed -n '/Subject:/,/X509v3 Subject Alternative Name:/p'
Subject: CN = mail.example.com
            X509v3 Subject Alternative Name:
                DNS:mail.example.com, DNS:smtp.example.com

Ce que cela signifie : Pas de mx1.example.com dans les SAN. Le CN seul n’est pas fiable, et la validation moderne utilise les SAN de toute façon.

Décision : Ajoutez mx1.example.com (et tout autre target MX) aux SAN lors de l’émission.

Tâche 3 : Vérifier l’absence d’intermédiaires (complétude de la chaîne)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/{i++}{print > ("cert" i ".pem")}'
cr0x@server:~$ for f in cert*.pem; do echo "== $f =="; openssl x509 -noout -subject -issuer -in "$f"; done
== cert1.pem ==
subject=CN = mail.example.com
issuer=C = US, O = Let's Encrypt, CN = R11
== cert2.pem ==
subject=C = US, O = Let's Encrypt, CN = R11
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

Ce que cela signifie : Le serveur a présenté feuille + intermédiaire. Bien. Si vous n’aviez vu que cert1.pem,
beaucoup de MTAs échoueraient à construire la chaîne.

Décision : Si l’intermédiaire manque, corrigez le smtpd_tls_cert_file (Postfix) ou l’équivalent pour inclure le fullchain.

Tâche 4 : Confirmer que la clé privée correspond au certificat de feuille

cr0x@server:~$ openssl x509 -noout -modulus -in /etc/ssl/mail/fullchain.pem | openssl md5
MD5(stdin)= 6f0c9a7d5b0c0b3f4b6a7e3c2d1a9e10
cr0x@server:~$ openssl rsa -noout -modulus -in /etc/ssl/mail/privkey.pem | openssl md5
MD5(stdin)= 6f0c9a7d5b0c0b3f4b6a7e3c2d1a9e10

Ce que cela signifie : Les hash des modules correspondent : la clé et le certificat vont ensemble.
S’ils ne correspondaient pas, votre MTA pourrait échouer le TLS ou présenter autre chose.

Décision : En cas de non‑correspondance, déployez la paire clé/cert correcte et rechargez le service.

Tâche 5 : Confirmer ce que Postfix est configuré pour utiliser (et s’il est réellement activé)

cr0x@server:~$ postconf -n | egrep 'smtpd_tls_|smtp_tls_|myhostname|mydomain'
myhostname = mx1.example.com
smtpd_tls_cert_file = /etc/ssl/mail/fullchain.pem
smtpd_tls_key_file = /etc/ssl/mail/privkey.pem
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1

Ce que cela signifie : TLS entrant et sortant sont opportunistes (may), et le niveau de log est bas mais non nul.

Décision : Si vous essayez de satisfaire une exigence partenaire, vous pourriez avoir besoin de politiques par domaine, pas d’un encrypt global.

Tâche 6 : Transformer les logs en preuves (détail des logs TLS Postfix)

cr0x@server:~$ sudo postconf -e 'smtpd_tls_loglevel=2' 'smtp_tls_loglevel=2'
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Feb  4 12:10:21 mx1 postfix/smtpd[22110]: Anonymous TLS connection established from mail-oi1-f169.google.com[209.85.167.169]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
Feb  4 12:10:44 mx1 postfix/smtpd[22110]: warning: TLS library problem: error:0A000086:SSL routines::certificate verify failed: TLS alert unknown ca

Ce que cela signifie : Première ligne : succès avec un expéditeur moderne. Deuxième ligne : un autre pair a échoué la vérification (ou votre serveur a échoué à vérifier le leur, selon la direction).

Décision : Si les échecs sont entrants et que vous n’exigez pas de certificats client, assurez‑vous de ne pas être mal configuré pour vérifier les clients. Si c’est sortant, vérifiez votre magasin de confiance.

Tâche 7 : Identifier si le SNI change le certificat présenté

cr0x@server:~$ openssl s_client -starttls smtp -connect 203.0.113.25:25 -showcerts 2>/dev/null | openssl x509 -noout -subject
subject=CN = default.invalid
cr0x@server:~$ openssl s_client -starttls smtp -connect 203.0.113.25:25 -servername mx1.example.com -showcerts 2>/dev/null | openssl x509 -noout -subject
subject=CN = mx1.example.com

Ce que cela signifie : Sans SNI vous obtenez le certificat par défaut (default.invalid), avec SNI vous obtenez le bon.

Décision : Si vous ne pouvez pas dédier des IPs, définissez le certificat par défaut sur quelque chose d’acceptable pour votre MX principal, et testez avec un client non SNI.

Tâche 8 : Tester le recouvrement des protocoles (forcer des versions TLS)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_2 -servername mx1.example.com 

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_1 -servername mx1.example.com
...
ssl3_read_bytes:tlsv1 alert protocol version
...

Ce que cela signifie : TLS 1.2 fonctionne ; TLS 1.1 est refusé. C’est une bonne hygiène en 2026.
Si votre pair ne supporte que TLS 1.1, lui échouera.

Décision : Gardez TLS 1.2 activé. Décidez au cas par cas de supporter des pairs legacy (généralement pas sur un MX public).

Tâche 9 : Confirmer quelles suites de chiffrement votre serveur offre (côté serveur)

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_tls_mandatory_protocols|smtpd_tls_protocols|smtpd_tls_mandatory_ciphers|tls_high_cipherlist'
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high

Ce que cela signifie : Les protocoles obligatoires sont TLSv1.2+. L’opportuniste permet encore plus sauf limitation.
« high » est vague ; cela dépend d’OpenSSL.

Décision : Si des problèmes d’interopérabilité existent, définissez explicitement une liste de chiffrement moderne mais compatible plutôt que de compter sur la magie « high ».

Tâche 10 : Vérifier les enregistrements MX et voir vers quels noms le monde se connecte réellement

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.
cr0x@server:~$ dig +short A mx1.example.com
203.0.113.25
cr0x@server:~$ dig +short AAAA mx1.example.com
2001:db8:25::25

Ce que cela signifie : Ce sont les hostnames qui doivent être couverts par des certificats (ou au moins présenter des défauts corrects).

Décision : Assurez‑vous que chaque target MX dispose d’un certificat dont les SAN incluent ce nom exact, pour les points de terminaison IPv4 et IPv6.

Tâche 11 : Vérifier l’alignement du reverse DNS (réduit les problèmes qui ressemblent à TLS)

cr0x@server:~$ dig +short -x 203.0.113.25
mx1.example.com.
cr0x@server:~$ hostname -f
mx1.example.com

Ce que cela signifie : Le PTR correspond à votre FQDN. Beaucoup de récepteurs apprécient cela. Certains l’exigent pour le scoring de réputation.

Décision : Si le PTR est incorrect, faites‑le corriger par votre fournisseur d’IP. Ne poursuivez pas des fantômes TLS tant que l’identité de base n’est pas alignée.

Tâche 12 : Vérifier l’état MTA-STS depuis le DNS (imposez‑vous le TLS strict ?)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=2024020401"
cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Ce que cela signifie : Vous publiez MTA-STS et le reporting TLS. Les expéditeurs qui respectent STS peuvent maintenant imposer la validité du certificat et les vérifications de nom.

Décision : Si vous n’êtes pas prêt pour la stricte, ne publiez pas MTA-STS. Si vous l’êtes, assurez‑vous que les noms MX et certificats sont cohérents partout.

Tâche 13 : Consulter TLSRPT (si vous collectez des rapports) pour voir qui échoue et pourquoi

cr0x@server:~$ sudo grep -R "sts-policy" -n /var/mail/tlsrpt/ | head
/var/mail/tlsrpt/report-2026-02-04.json:42:    "result_type": "sts-policy-invalid"
/var/mail/tlsrpt/report-2026-02-04.json:43:    "sending_mta_ip": "198.51.100.10"

Ce que cela signifie : Certains expéditeurs échouent à cause de politiques STS, pas de la mécanique brute du TLS.

Décision : Corrigez la publication de la politique STS et son alignement, ou ajustez temporairement le mode politique pour éviter des pannes sévères durant la transition.

Tâche 14 : Confirmer que votre service écoute et annonce STARTTLS

cr0x@server:~$ nc -v mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!
220 mx1.example.com ESMTP Postfix
cr0x@server:~$ printf "EHLO test.example\r\nQUIT\r\n" | nc -v mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!
220 mx1.example.com ESMTP Postfix
250-mx1.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME

Ce que cela signifie : STARTTLS est proposé. S’il est absent, les expéditeurs ne peuvent pas monter en TLS—même si vous avez un excellent certificat.

Décision : Si STARTTLS n’est pas annoncé, corrigez l’activation TLS du MTA et assurez‑vous qu’aucun proxy ne supprime les extensions.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : La panne causée par une mauvaise hypothèse (validation du nom d’hôte)

Une entreprise SaaS de taille moyenne a migré son courrier entrant vers un nouveau cluster. L’équipe a fait la chose « mature » :
nouvelles IPs, nouveaux enregistrements MX, et un joli certificat d’une CA publique. Ils ont testé avec quelques comptes externes,
ont vu le flux de mails et ont déclaré victoire.

Puis le gateway sécurité d’un gros client a commencé à différer des messages avec une raison d’échec TLS. Pas de rebond. Des remises différées.
C’est pire : ça s’accumule et devient le problème du lendemain, juste quand vous espériez dormir.

Le certificat de l’entreprise était valide pour mail.example.com. Leurs MX pointaient vers mx1.example.com et mx2.example.com.
Ils ont supposé que le CN couvrirait ça (« ce n’est pas ce que font les certificats ? »), et ils ont supposé que les MTAs expéditeurs valident par rapport au nom de bannière.
Le gateway du client validait par rapport au nom MX auquel il se connectait. Strictement. Correctement.

La correction a été ennuyeuse : réémettre le certificat avec des SAN couvrant les deux noms MX et le nom de soumission,
déployer le fullchain, recharger Postfix. La livraison a repris immédiatement pour ce client et pour plusieurs autres qui avaient été silencieusement différés.

La leçon : un certificat valide n’est pas une identité ; c’est une affirmation. Les pairs SMTP décident s’ils y croient et à quoi ils le comparent.
Vos hypothèses n’ont pas de voix au chapitre.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (durcissement devenu incompatibilité)

Une initiative sécurité a traversé une grande entreprise : standardiser « TLS moderne partout ». L’équipe mail a reçu l’ordre de désactiver
les protocoles et suites plus anciens « pour se conformer ». Personne n’a contesté l’objectif ; tout le monde a disputé le calendrier.
Le calendrier a gagné.

Ils ont déployé une configuration qui exigeait effectivement TLS 1.3 pour le SMTP entrant. Sur le papier, c’était progressiste.
En pratique, cela a transformé leur MX en videur zélé.

Certains expéditeurs négociaient TLS 1.3 sans problème. D’autres—appareils industriels, petits MTAs d’entreprise, et quelques systèmes partenaires sur des bibliothèques anciennes—
ne supportaient que TLS 1.2. La livraison a commencé à échouer de façon intermittente. Pas seulement des sources spammy. De vraies factures. De vraies mises à jour de tickets.
L’incident a d’abord été mal classé comme « instabilité réseau » parce qu’il semblait aléatoire selon les expéditeurs.

La remédiation a été un rollback contrôlé : autoriser TLS 1.2, garder TLS 1.0/1.1 désactivés, et utiliser une suite de chiffrement sensée qui se recoupe encore
avec les builds OpenSSL courants. Ils ont aussi mis en place un monitoring de la distribution des versions TLS sur les connexions entrantes.

La leçon : le durcissement n’est pas un seul bouton. C’est une négociation. SMTP est un écosystème, pas votre application.
Optimisez pour la sécurité sans tester l’interopérabilité, et vous « sécuriserez » la perte de courrier.

Mini-récit 3 : La pratique ennuyeuse et correcte qui a sauvé la mise (TLSRPT + application progressive)

Une autre entreprise voulait imposer le chiffrement pour le mail entrant. Ils avaient des exigences juridiques et un vrai modèle de menace.
Au lieu de tout activer d’un coup, ils ont procédé par étapes comme des adultes : observer, mesurer, puis appliquer.

Ils ont publié le reporting TLS et collecté centralement les rapports TLSRPT. Pendant des semaines, l’équipe mail a revu les catégories d’échec.
La plupart étaient du bruit attendu, mais quelques‑unes étaient réelles : un nœud MX présentait la mauvaise chaîne après une mise à jour de paquet ;
un autre avait une adresse IPv6 servant un certificat obsolète parce que l’automatisation ne mettait à jour que les VIP IPv4.

Ils ont corrigé les incohérences, ajouté un job quotidien qui vérifie chaque endpoint MX sur IPv4 et IPv6,
et n’ont basculé en mode enforce MTA-STS qu’après. Quand ils ont finalement appliqué l’enforcement, le taux d’échec n’a pas explosé.
Il a même baissé—parce qu’ils avaient éliminé des mauvaises configurations qui causaient silencieusement des rétrogradations opportunistes du TLS.

La leçon : l’observabilité ennuyeuse bat le débogage héroïque. Si vous voulez un TLS strict, gagnez‑le en rendant d’abord vos endpoints ennuyeusement cohérents.

Blague n°2 : La seule chose plus persistante qu’un intermédiaire manquant est l’invitation à une réunion pour « y revenir » le trimestre prochain.

Erreurs courantes : symptôme → cause racine → correction

1) « Échec de la handshake TLS » avec un certificat qui semble correct dans un navigateur

Symptôme : Les MTAs distants loguent certificate verify failed ou unknown ca ; votre navigateur affiche un cadenas.

Cause racine : Intermédiaire manquant dans la chaîne. Les navigateurs récupèrent ; beaucoup de MTAs ne le font pas.

Correction : Servez le fullchain.pem (feuille + intermédiaires) depuis votre MTA. Ne comptez pas sur la récupération AIA.

2) Ça marche pour certains expéditeurs, échoue pour d’autres (apparemment aléatoire)

Symptôme : Un sous‑ensemble d’expéditeurs échoue systématiquement la validation STARTTLS ; d’autres réussissent.

Cause racine : Sélection du certificat dépendant du SNI, ou différence de rigidité de validation entre MTAs.

Correction : Testez avec et sans SNI. Rendez le certificat par défaut acceptable pour votre nom MX ou dédiez des IPs.

3) « mismatch nom d’hôte » ou « le certificat ne correspond pas »

Symptôme : Les logs mentionnent un mismatch ; la livraison est différée ou le TLS rétrogradé.

Cause racine : Les SAN du certificat n’incluent pas le nom cible MX (fréquent durant les migrations).

Correction : Réémettez le certificat pour inclure tous les hostnames MX en SAN ; ou ajustez les MX pour correspondre à un nom de certificat existant.

4) STARTTLS non proposé, même si vous avez configuré des certificats

Symptôme : La sortie EHLO ne contient pas 250-STARTTLS.

Cause racine : TLS désactivé dans la config MTA ; chemins chroot ; problèmes de permissions ; ou proxy qui supprime les extensions.

Correction : Assurez‑vous que TLS est activé, que le certificat/la clé est lisible par le MTA, et qu’aucun middlebox ne modifie les extensions SMTP.

5) Échecs soudains après activation de MTA-STS

Symptôme : Du courrier auparavant livré est maintenant différé par de gros fournisseurs ; TLSRPT montre des échecs de politique.

Cause racine : La publication de MTA-STS a transformé le TLS opportuniste en validation forcée, révélant des incohérences de nom/chaîne.

Correction : Alignez les certificats sur tous les endpoints MX (y compris IPv6), vérifiez les noms, corrigez la présentation de la chaîne, puis repassez en enforce.

6) Seule la livraison IPv6 échoue pour TLS

Symptôme : Le chemin IPv4 fonctionne ; le chemin IPv6 montre un mauvais certificat ou une chaîne expirée.

Cause racine : VIP séparé, listener séparé, automatisation obsolète, ou pool de load balancer différent pour les AAAA.

Correction : Testez explicitement les endpoints A et AAAA ; unifiez l’automatisation pour que le déploiement de certificats couvre les deux.

7) « pas de chiffrement partagé » ou « échec de handshake » après durcissement

Symptôme : Le TLS échoue lors de la négociation ; les logs montrent mismatch de chiffrement ou alerte de protocole.

Cause racine : Sur‑durcissement qui a supprimé le recouvrement commun (ou forcé TLS 1.3 uniquement).

Correction : Gardez TLS 1.2 ; utilisez une liste de chiffrement moderne mais compatible. Validez contre une matrice de stacks d’expéditeurs réels.

8) Le certificat tourne, puis les partenaires cassent (surtout avec DANE)

Symptôme : Après rotation, un sous‑ensemble d’expéditeurs refuse TLS bien que le nouveau certificat soit valide.

Cause racine : Enregistrements TLSA non mis à jour (DANE), ou pinning/caches chez les partenaires.

Correction : Mettez à jour TLSA avant ou pendant la rotation ; planifiez des fenêtres de chevauchement ; communiquez avec les partenaires stricts.

Listes de vérification / plan étape par étape

Étape par étape : faire fonctionner réellement un certificat SMTP

1. Inventairez vos noms publics.
   • Listez toutes les cibles MX (y compris les MX de secours).
   • Listez les hostnames de soumission/IMAP/POP s’ils partagent des endpoints.
   • Incluez les endpoints IPv6 AAAA.
2. Émettez des certificats pour les noms auxquels les gens se connectent.
   • Mettez chaque hostname MX dans les SAN.
   • Ne comptez pas sur le seul CN.
   • Décidez si vous avez besoin de wildcard SANs (évitez généralement pour le mail ; les noms explicites sont plus propres).
3. Déployez correctement la chaîne complète.
   • Utilisez fullchain.pem (feuille + intermédiaires).
   • N’incluez pas la CA racine dans la chaîne présentée.
4. Définissez le certificat par défaut intentionnellement.
   • Supposez que certains clients n’enverront pas SNI.
   • Rendez le certificat par défaut valide pour le nom MX principal.
5. Choisissez les versions TLS en gardant l’interopérabilité à l’esprit.
   • Activez TLS 1.2 et TLS 1.3.
   • Désactivez TLS 1.0/1.1 sauf nécessité métier restreinte et contrôles compensatoires.
6. Testez depuis l’extérieur de votre réseau.
   • Exécutez des vérifications STARTTLS contre chaque nom MX et chaque famille d’IP.
   • Testez avec et sans SNI.
7. Décidez attentivement des mécanismes d’application.
   • Le TLS opportuniste suffit pour une « sécurité de base ».
   • MTA-STS/DANE servent quand vous pouvez garder votre configuration cohérente malgré les changements.
8. Opérationnalisez les rotations.
   • Automatisez le déploiement et les reloads.
   • Surveillez les expirations, la correction de la chaîne et la parité des endpoints (IPv4/IPv6).

Checklist : avant de publier MTA-STS en mode enforce

• Chaque endpoint MX public (toutes les adresses A/AAAA) présente la même chaîne correcte.
• Le SAN du certificat inclut chaque nom cible MX.
• Le certificat par défaut est acceptable quand le SNI est absent.
• TLS 1.2 fonctionne partout ; TLS 1.3 fonctionne là où c’est supporté.
• Aucun middlebox ne supprime STARTTLS ni ne détourne la négociation.
• Vous avez des logs et un processus pour enquêter rapidement sur les échecs TLS.

Checklist : dépannage d’un connecteur partenaire « TLS requis »

• Obtenez le nom d’hôte exact et le port vers lequel le partenaire se connecte.
• Obtenez le texte d’erreur exact et précisez s’il survient durant la handshake, la vérification de nom, ou la validation de chaîne.
• Testez votre côté avec openssl s_client -starttls smtp contre ce nom d’hôte.
• Si vous terminez TLS derrière un load balancer, validez le certificat LB et le comportement SNI.
• Vérifiez que le partenaire n’a pas de pinning sur un ancien certificat ou intermédiaire.

FAQ

1) Pourquoi mon certificat se vérifie dans un navigateur mais échoue pour SMTP ?

Les navigateurs récupèrent souvent les intermédiaires manquants et ont des stores de confiance riches. Beaucoup de MTAs ne récupèrent pas les intermédiaires et se fient à ce que vous présentez.
De plus, les pairs SMTP valident le nom MX auquel ils se connectent, pas forcément ce que vous avez testé dans un navigateur.

2) Ai‑je besoin d’un certificat séparé pour chaque serveur MX ?

Pas strictement. Vous pouvez utiliser un seul certificat avec des entrées SAN pour tous les hostnames MX, déployé partout.
Opérationnellement, c’est souvent plus simple—une seule pipeline d’émission, un seul calendrier de renouvellement—si vous maîtrisez bien la distribution.

3) Dois‑je utiliser un certificat wildcard pour le mail ?

En général : évitez sauf raison forte. Les wildcards ne couvrent pas les noms à multi‑étiquettes et peuvent masquer un inventaire bâclé.
Des SAN explicites facilitent les audits et l’application des politiques.

4) Le port 465 est‑il requis pour l’email sécurisé ?

Pour le server‑to‑server : non, le port 25 avec STARTTLS est la norme. Pour la soumission client, le port 587 est standard avec STARTTLS,
et le port 465 est couramment utilisé pour la soumission implicite TLS. Utilisez ce que vos clients supportent, mais ne déplacez pas le trafic MX hors du 25.

5) Quelle est la différence entre TLS opportuniste et TLS appliqué dans SMTP ?

Le TLS opportuniste monte en TLS quand c’est possible et peut retomber en clair si la négociation échoue. Le TLS appliqué (via MTA-STS, DANE,
ou connecteurs partenaires) refuse la livraison si le TLS ne peut pas être validé selon la politique.

6) Tous les MTAs valident les noms d’hôte dans les certificats ?

Non, mais de plus en plus le font—surtout sous MTA-STS ou lorsqu’ils sont configurés en « TLS requis ».
Vous devez supposer que certains pairs valideront strictement et configurer en conséquence.

7) Quelle est la erreur de configuration la plus courante que vous voyez ?

Servir uniquement le certificat de feuille sans l’intermédiaire. C’est le classique « ça marche sur mon portable » sous l’habit du PKI.

8) Si nous utilisons DANE, pouvons‑nous éviter les CA publiques entièrement ?

Potentiellement oui, si votre domaine est correctement signé DNSSEC et si vos correspondants valident DNSSEC et DANE pour SMTP.
En pratique, il faut comprendre l’écosystème de vos correspondants avant de parier la délivrabilité sur une validation DNSSEC universelle.

9) Pourquoi certains expéditeurs se connectent à l’IPv6 et échouent, alors que l’IPv4 marche ?

Parce que votre AAAA pointe vers un listener ou un pool différent avec un certificat obsolète, une chaîne incorrecte, ou un certificat par défaut différent.
Testez et gérez l’IPv6 comme un endpoint de première classe, pas comme une case à cocher.

10) Dois‑je inclure le certificat racine dans la chaîne que je présente ?

Non. Présentez la feuille et les intermédiaires nécessaires pour atteindre une racine de confiance. Inclure la racine est inutile et parfois problématique.

Conclusion : étapes pratiques suivantes

« Certificat valide » est une phrase réconfortante, comme « le serveur est up ». Ce n’est pas une réponse.
Le TLS e‑mail échoue dans les interstices : mauvais nom d’hôte, chaîne incomplète, mismatch SNI, application de politique, endpoints incohérents.
Le réparer consiste moins à acheter un meilleur certificat qu’à faire concorder l’identité, le DNS et le déploiement partout.

1. Exécutez des tests STARTTLS contre chaque nom MX (et en IPv4/IPv6). Capturez la chaîne présentée et les SAN.
2. Faites correspondre le certificat à la façon dont le monde se connecte : SAN pour tous les targets MX, certificat par défaut correct, déploiement cohérent.
3. Servez la chaîne complète (feuille + intermédiaires) et vérifiez avec des outils non‑navigateur.
4. Gardez TLS 1.2 activé ; ajoutez TLS 1.3 ; évitez un durcissement qui supprime le recouvrement commun sans preuve.
5. Si vous voulez l’application (MTA-STS/DANE), gagnez‑la en rendant vos endpoints ennuyeusement cohérents avant d’activer.

Faites ces cinq choses et la plupart des « mystérieuses pannes TLS mail » cessent d’être mystérieuses. Elles redeviennent ce qu’elles ont toujours été :
dérive de configuration, mismatch d’identité, et hypothèses optimistes confrontées au monde réel.