Échec de la négociation TLS SMTP : corriger correctement certificats, suites et chaînes

Playbook de diagnostic rapide

Si vous êtes de garde, vous n’avez pas besoin d’un cours. Vous avez besoin d’une boucle serrée : reproduire, classer, corriger la couche correcte, passer à autre chose.

1) Confirmez où ça échoue : avant STARTTLS, pendant le handshake, ou après

• Avant STARTTLS : STARTTLS non proposé, port incorrect, firewall, ou politique refusant le chiffrement (oui, ça existe).
• Pendant le handshake : incompatibilité protocole/cipher, chaîne de certificats incorrecte, mauvais certificat via SNI, certificat expiré, ou problème de magasin de confiance côté client.
• Après le handshake : échec d’authentification SMTP, politique qui rejette, ou problèmes applicatifs mal reportés comme TLS.

2) Lancez une sonde canonique depuis le côté qui échoue

Faites-le depuis le même segment réseau et l’hôte qui expérimente l’erreur. TLS est sensible aux mensonges « ça marche depuis mon laptop ».

Utilisez openssl s_client avec STARTTLS et capturez la chaîne de certificats ainsi que le protocole et la suite négociés.

3) Décidez dans quel panier vous êtes

• « No peer certificate » / « handshake failure » immédiatement : incompatibilité protocole/cipher, STARTTLS pas réellement déclenché, ou le serveur interrompt à cause de politique/SNI.
• « verify error:num=20/21 unable to get local issuer certificate » : présentation de chaîne cassée ou intermédiaire manquant.
• « certificate has expired » / « not yet valid » : cycle de vie du certificat ou dérive d’horloge.
• « hostname mismatch » : mauvais certificat, SNI non utilisé ou mal configuré, ou MX qui pointe ailleurs que vous pensiez.

4) Corrigez le serveur d’abord, sauf si vous contrôlez le client

En SMTP, vous ne contrôlez souvent pas l’autre extrémité. Cela signifie : corrigez ce que vous présentez et ce que vous négociez. Si votre serveur initie le mail sortant (rôle client), corrigez aussi votre magasin de confiance et vos politiques, mais n’approuvez pas des rustines du genre « accept_invalid_certs = yes ». Ce n’est pas une correction ; c’est un plan de violation.

Comment les négociations TLS SMTP se cassent réellement (et pourquoi les logs mentent)

SMTP TLS a deux modes courants :

• TLS implicite (SMTPS sur 465) : TLS commence immédiatement après la connexion TCP.
• STARTTLS (généralement sur 25 ou 587) : le client se connecte en clair, envoie EHLO, voit STARTTLS, puis met à niveau la connexion.

Les échecs de handshake sont souvent rapportés par une seule ligne déprimante, mais l’échec réel est généralement l’un de ceux-ci :

1. Incompatibilité de négociation : aucun protocole partagé (TLS 1.0 vs TLS 1.2+) ou aucune suite de chiffrement commune.
2. Problèmes de chaîne de certificats : le serveur présente un certificat leaf mais oublie les intermédiaires. Certains clients peuvent récupérer les intermédiaires manquants ; beaucoup de piles SMTP ne le font pas.
3. Problèmes de confiance : le client ne fait pas confiance à la chaîne (magasin de racines obsolète, CA privée, racine manquante, ou CA récemment retirée de la confiance).
4. Problèmes d’identité : le certificat ne correspond pas au nom attendu par le client (hostname MX vs nom de bannière vs SNI).
5. Politiques : le serveur exige des certificats client, exige SNI, refuse des signatures faibles, ou applique des attentes MTA-STS/DANE côté pair.
6. Middleboxes : firewalls qui « aident » en interceptant ou en dénaturant STARTTLS, ou inspection TLS sortante qui tourne mal.

Une vérité opérationnelle : SMTP est un écosystème. Vous pouvez avoir une configuration parfaite et échouer quand même avec un pair mal configuré. Votre travail est de garder votre côté correct, observable et raisonnablement compatible—sans redevenir le dernier serveur TLS 1.0 sur Terre.

Idée paraphrasée, avec attribution : « L’espoir n’est pas une stratégie. » — souvent attribuée dans les cercles de fiabilité à Gene Kranz, reflétant la pensée opérationnelle (paraphrase).

Faits et histoire utiles que vous pouvez exploiter

• STARTTLS était une voie d’amélioration, pas une refonte totale. Il existe parce que l’email était déjà partout en clair, et personne n’allait replatformer la planète.
• Le port 465 a eu une vie compliquée. Il a commencé comme « SMTPS », a été déprécié au profit de STARTTLS, puis est revenu comme port de soumission TLS reconnu dans la pratique moderne.
• TLS 1.3 a changé la forme du handshake. Moins d’aller-retour, noms de suites différents et moins de réglages legacy. Parfait pour la sécurité ; déroutant pour les vieux scripts de supervision.
• Certaines piles SMTP ne récupèrent pas les intermédiaires manquants. Les navigateurs sont indulgents ; les MTA souvent non. N’espérez pas que tout soit réparé automatiquement.
• SNI est plus jeune que la plupart des serveurs mail. Si vous hébergez plusieurs domaines sur une IP, les clients modernes envoient SNI, mais toutes les piles SMTP ne le faisaient pas historiquement.
• La dépréciation de SHA-1 hante encore les appliances longévives. Du matériel ancien peut rejeter de nouvelles signatures, et du matériel récent rejette les anciennes. Tout le monde est déçu.
• Les enregistrements CAA peuvent briser silencieusement les renouvellements. Si votre automatisation renouvelle via ACME et que CAA bloque l’émetteur, vous l’apprenez quand le certificat expire—le week-end.
• La sécurité basée sur DNS (DANE, MTA-STS) a changé les attentes. Certains expéditeurs exigent maintenant un TLS valide et vérifiable pour la livraison, et différeront plutôt que de rétrograder.
• Les magasins de confiance sont des documents politiques. Une CA peut être approuvée aujourd’hui et désapprouvée demain. Votre argument « c’est un certificat valide » ne suffira pas si la racine a disparu.

Tâches pratiques : commandes, sorties, décisions

Ce sont les tâches que j’exécute réellement pendant les incidents. Chacune inclut la commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Check that the server offers STARTTLS on port 25

cr0x@server:~$ nc -nv mail.example.net 25
(UNKNOWN) [203.0.113.10] 25 (smtp) open
220 mx1.example.net ESMTP Postfix

Signification : TCP fonctionne et vous avez atteint une bannière SMTP. Si ça bloque ou expire, vous ne déboguez pas TLS pour l’instant.

Décision : Si TCP échoue, corrigez le routage/firewall/DNS d’abord. Si la bannière est le mauvais hôte, traquez MX et load balancers.

Task 2: Confirm STARTTLS is advertised

cr0x@server:~$ printf "EHLO probe.example\r\nQUIT\r\n" | nc -nv mail.example.net 25
(UNKNOWN) [203.0.113.10] 25 (smtp) open
220 mx1.example.net ESMTP Postfix
250-mx1.example.net
250-PIPELINING
250-SIZE 52428800
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
221 2.0.0.0 Bye

Signification : STARTTLS existe. S’il manque, soit TLS est désactivé soit une politique le masque (rare mais réel).

Décision : Si STARTTLS manque sur le MX entrant, vérifiez la config MTA et assurez-vous que le listener TLS est activé.

Task 3: Perform a STARTTLS handshake probe with SNI

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net -showcerts -verify_return_error
CONNECTED(00000003)
depth=2 C = US, O = Example Root CA, CN = Example Root CA R1
verify return:1
depth=1 C = US, O = Example Issuing CA, CN = Example Issuing CA G2
verify return:1
depth=0 CN = mail.example.net
verify return:1
---
Certificate chain
 0 s:CN = mail.example.net
   i:C = US, O = Example Issuing CA, CN = Example Issuing CA G2
-----BEGIN CERTIFICATE-----
...snip...
-----END CERTIFICATE-----
 1 s:C = US, O = Example Issuing CA, CN = Example Issuing CA G2
   i:C = US, O = Example Root CA, CN = Example Root CA R1
-----BEGIN CERTIFICATE-----
...snip...
-----END CERTIFICATE-----
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Verify return code: 0 (ok)

Signification : Vous avez négocié TLS 1.3 et la validation a réussi. La chaîne inclut l’intermédiaire.

Décision : Si vos clients en production échouent encore, comparez leur magasin de confiance, le support de protocole, le comportement SNI et les exigences de politique.

Task 4: Probe without SNI to catch the “default cert” problem

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.net:25 -showcerts -verify_return_error
CONNECTED(00000003)
depth=0 CN = default.invalid
verify error:num=62:Hostname mismatch
80DB5E2E677F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1889:
---
Certificate chain
 0 s:CN = default.invalid
   i:C = US, O = Example Issuing CA, CN = Example Issuing CA G2
---
Verify return code: 62 (Hostname mismatch)

Signification : Sans SNI, le serveur remet un certificat par défaut pour un autre nom.

Décision : Si vous hébergez plusieurs noms, assurez-vous que votre démon SMTP supporte SNI et a un mapping par nom correct ; sinon dédiez une IP ou présentez un certificat couvrant tous les noms pertinents via SANs.

Task 5: Identify protocol version mismatch (client too old or server too strict)

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.net:25 -tls1
CONNECTED(00000003)
140735215769152:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1950:
no peer certificate available

Signification : Le serveur refuse TLS 1.0. C’est normal en 2026.

Décision : Si un client legacy ne peut pas faire TLS 1.2+, mettez-le à niveau ou isolez-le derrière un relais contrôlé. Ne réactivez pas TLS 1.0 sur votre MX internet sauf si vous aimez les rétrospectives d’incident.

Task 6: Identify cipher suite mismatch

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.net:25 -tls1_2 -cipher 'RC4-SHA'
CONNECTED(00000003)
140735215769152:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1605:SSL alert number 40
no peer certificate available

Signification : Vous avez proposé une suite ancienne ; le serveur a refusé. Bien.

Décision : Si l’inverse se produit (le client n’offre que de la camelote), la correction est côté client. Si votre serveur n’offre que de la camelote, corrigez votre bibliothèque TLS et votre config.

Task 7: Verify the certificate chain file on disk

cr0x@server:~$ openssl x509 -in /etc/ssl/mail/mail.example.net.crt -noout -subject -issuer -dates -ext subjectAltName
subject=CN = mail.example.net
issuer=C = US, O = Example Issuing CA, CN = Example Issuing CA G2
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:mail.example.net, DNS:mx1.example.net

Signification : Les dates et SAN semblent correctes. L’expiration est proche : incident programmé.

Décision : Si le SAN ne correspond pas au nom auquel vos pairs se connectent (souvent le nom MX), corrigez l’émission et l’alignement des noms DNS.

Task 8: Ensure the presented chain is complete and ordered

cr0x@server:~$ openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted /etc/ssl/mail/intermediate.pem /etc/ssl/mail/mail.example.net.crt
/etc/ssl/mail/mail.example.net.crt: OK

Signification : Avec l’intermédiaire, le leaf se vérifie contre les racines système.

Décision : Si ça échoue, vous avez probablement le mauvais intermédiaire, une chaîne incomplète, ou un cert d’une CA privée non approuvée par les pairs.

Task 9: Inspect what the SMTP service actually presents (not what you think it presents)

cr0x@server:~$ openssl s_client -starttls smtp -connect 203.0.113.10:25 -servername mail.example.net 2>/dev/null | openssl x509 -noout -subject -issuer -ext subjectAltName
subject=CN = mail.example.net
issuer=C = US, O = Example Issuing CA, CN = Example Issuing CA G2
X509v3 Subject Alternative Name:
    DNS:mail.example.net, DNS:mx1.example.net

Signification : Vous vérifiez le service live, pas le fichier dans /etc/ssl que personne n’a chargé.

Décision : Si la sortie live diffère du disque, vous avez des problèmes de reload, un chemin erroné dans la config, ou plusieurs MTA/listeners.

Task 10: Confirm your MTA is listening where you think

cr0x@server:~$ ss -ltnp | egrep ':(25|465|587)\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1243,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1243,fd=14))
LISTEN 0      100          0.0.0.0:465       0.0.0.0:*    users:(("master",pid=1243,fd=15))

Signification : Le master Postfix est lié aux trois ports. Si 465 n’est pas présent, SMTPS n’est pas activé.

Décision : Faites correspondre la réalité des listeners à vos paramètres publiés et aux attentes des clients.

Task 11: Pull the exact TLS errors from Postfix logs

cr0x@server:~$ sudo grep -E "warning: TLS|SSL_accept|SSL_connect|handshake" /var/log/mail.log | tail -n 8
Jan 03 11:04:18 mx1 postfix/smtpd[22418]: warning: TLS library problem: error:0A000076:SSL routines::no suitable signature algorithm:../ssl/t1_lib.c:3364:
Jan 03 11:04:18 mx1 postfix/smtpd[22418]: lost connection after STARTTLS from unknown[198.51.100.23]
Jan 03 11:06:44 mx1 postfix/smtpd[22502]: warning: TLS library problem: error:0A000410:SSL routines::sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1605:SSL alert number 40
Jan 03 11:06:44 mx1 postfix/smtpd[22502]: lost connection after STARTTLS from mail.partner.example[203.0.113.77]

Signification : « No suitable signature algorithm » pointe souvent vers un décalage RSA/EC ou des limitations de pair très anciennes.

Décision : Décidez si vous allez supporter la pile TLS de ce partenaire. Si c’est un partenaire business majeur, routiez via un relais dédié avec compatibilité ciblée ; ne fragilisez pas le MX principal.

Task 12: Check the outbound side: what your server negotiates when acting as a client

cr0x@server:~$ openssl s_client -starttls smtp -connect mx.partner.example:25 -servername mx.partner.example -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN = mx.partner.example
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK

Signification : La négociation sortante a réussi ; protocole/suite modernes.

Décision : Si le sortant échoue depuis votre MTA mais réussit avec OpenSSL, vérifiez la politique TLS du MTA, le support SNI et les chemins de fichiers CA.

Task 13: Validate system clock and time sync (yes, it matters)

cr0x@server:~$ timedatectl
Local time: Sat 2026-01-03 11:12:29 UTC
Universal time: Sat 2026-01-03 11:12:29 UTC
RTC time: Sat 2026-01-03 11:12:29
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Signification : L’heure est synchronisée. Si ce n’est pas le cas, les erreurs « not yet valid » seront garantis.

Décision : Réparez NTP avant de toucher aux configs TLS. Une horloge fausse rend tout certificat suspect.

Task 14: Confirm the CA store your MTA uses is populated

cr0x@server:~$ ls -l /etc/ssl/certs/ca-certificates.crt
-rw-r--r-- 1 root root 214392 Jan  2 02:14 /etc/ssl/certs/ca-certificates.crt

Signification : Vous avez un bundle CA consolidé. Certains MTA utilisent des bundles personnalisés ; assurez-vous qu’ils existent et sont mis à jour.

Décision : Si vous utilisez un fichier CA personnalisé, documentez-le et automatisez les mises à jour. Sinon, gardez le chemin standard de l’OS.

Blague 1 : Un échec de handshake TLS, c’est comme deux cadres qui se rencontrent : chacun insiste sur sa compatibilité, et aucun ne changera ses defaults.

Chaînes de certificats : comment les construire correctement

La première cause d’échec TLS SMTP que je vois en production : serveurs présentant une chaîne incomplète. Les navigateurs réparent souvent cela en récupérant les intermédiaires via Authority Information Access (AIA). Les clients SMTP, généralement, ne le font pas. Assumez que rien ne sera auto-réparé.

Ce que « chaîne correcte » signifie en termes SMTP

• Certificat leaf : pour le nom SMTP auquel les pairs se connectent (typiquement le nom MX).
• Certificat(s) intermédiaire(s) : nécessaires pour relier le leaf à une racine du magasin de confiance client.
• Certificat racine : généralement non envoyé par le serveur ; les clients l’ont déjà. L’envoyer est en général sans conséquence mais peut embrouiller certaines piles cassées et rendre le dépannage plus bruyant.

L’ordre importe

Quand vous concaténez des certificats, faites-le dans l’ordre : leaf d’abord, puis chaque intermédiaire remontant la chaîne. N’incluez pas la racine sauf raison spécifique. Si vous avez reçu un « fullchain.pem » de votre CA, c’est habituellement leaf + intermédiaires, ce que vous voulez présenter.

Comment les problèmes de chaîne apparaissent dans des logs réels

• Erreur côté client : « unable to get local issuer certificate » ou « unknown ca ».
• Symptôme côté serveur : connexion interrompue juste après STARTTLS, souvent loguée comme « lost connection after STARTTLS ».
• Odeur opérationnelle : certains récepteurs acceptent le mail, d’autres différeront des heures, selon leur pile TLS et la fraîcheur de leur magasin de confiance.

Ne mélangez pas les fichiers de chaîne par service sans prudence

Un hôte peut servir HTTPS, IMAPS, POP3S et SMTP. Chaque service peut être configuré pour utiliser un chemin de certificat différent. Si vous « renouvelez le cert » mais n’avez mis à jour que le serveur web, félicitations : vous avez réparé le mauvais service. Ça arrive plus souvent qu’on l’admet.

Suites de chiffrement et versions : arrêtez de négocier comme en 1999

Quand le handshake échoue avec « no shared cipher » ou « protocol version », vous êtes face à deux situations :

1. Votre serveur est trop strict pour un pair légitime que vous devez supporter.
2. Le pair est obsolète, et vous ne devriez pas abaisser votre niveau de sécurité.

Voici la partie opinionnée : pour un MX accessible depuis Internet, par défaut visez TLS 1.2 et TLS 1.3, des ciphers AEAD modernes, et des courbes raisonnables. Si quelqu’un ne peut pas parler avec ça, il peut livrer sans TLS seulement si votre politique le permet — ou il peut se mettre à jour. Votre travail est la livraison de mail et la gestion du risque, pas tenir un musée de compatibilité.

Réalité SMTP : vous ne contrôlez pas la plupart des pairs

Mais vous pouvez contrôler la façon dont vous échouez :

• Pour l’inbound : vous pouvez proposer TLS mais accepter le clair si votre politique le permet. Cela permet au mail de circuler sans imposer la sécurité.
• Pour l’outbound : vous pouvez exiger TLS pour certains domaines (cartographie de politique), ou appliquer MTA-STS/DANE lorsqu’ils sont disponibles.

Piège d’optimisation : « On a désactivé TLS 1.2 parce que 1.3 est plus rapide »

TLS 1.3 est excellent. Vous avez encore besoin de TLS 1.2 pour la compatibilité avec une part de l’infrastructure SMTP qui n’a pas migré, y compris des appliances managées. Gardez TLS 1.2 activé sauf si vous avez un environnement contrôlé et des exceptions écrites.

SNI, correspondance de nom et le piège du « mauvais certificat »

SNI (Server Name Indication) permet au client d’indiquer au serveur quel hostname il souhaite lors du handshake TLS. Sans SNI, le serveur choisit un certificat par défaut. Cela va pour un serveur mono-domaine. C’est un désastre pour des gateways mail multi-tenant.

D’où vient le nom attendu

Les clients SMTP se connectent typiquement au nom MX qu’ils ont obtenu via DNS. Ils valident le certificat contre ce nom. Si votre enregistrement MX pointe vers mx1.example.net mais que votre certificat ne contient que mail.example.net, vous venez de créer votre propre panne. Corrigez le nom d’abord ; ne tentez pas de « contourner » la vérité DNS.

Trois plans de nommage que vous devez aligner

• DNS : MX pointe vers un hostname ; A/AAAA le mappe aux IPs.
• Bannière SMTP : ce que votre serveur dit dans le greeting 220. Pas directement utilisé pour la validation TLS, mais cela affecte le debug et les signaux de réputation.
• SANs du certificat : les noms pour lesquels le certificat est valide. C’est ce qui compte pour les vérifications TLS.

Si vous hébergez plusieurs domaines sur un MX, vous pouvez utiliser un seul certificat couvrant plusieurs hostnames via SANs, ou utiliser la sélection par SNI si votre MTA la supporte proprement. Le « bon » choix dépend de la complexité opérationnelle : les SANs en pagaille sont laids, mais une mauvaise configuration SNI est pire.

Modèles de configuration MTA (Postfix, Exim) qui tiennent dans le temps

Je reste pratique : vous voulez des configs explicites, testables et rechargables sans surprises.

Postfix : essentiels TLS entrants

• Utilisez un fichier de chaîne complète pour smtpd_tls_cert_file (leaf + intermédiaires).
• Pointez smtpd_tls_key_file vers la clé privée correspondante.
• Définissez un niveau minimum de protocole en accord avec votre posture de risque ; typiquement TLS 1.2.
• Loggez suffisamment pour déboguer (smtpd_tls_loglevel), mais pas au point de DDoS vos disques.

Postfix : essentiels TLS sortants

À l’outbound la politique devient réelle. Vous pouvez faire du TLS opportuniste par défaut et imposer TLS par domaine quand nécessaire.

• Opportuniste : tentez STARTTLS quand il est offert, mais livrez sans s’il n’est pas disponible.
• Imposé par domaine : exigez TLS pour des partenaires spécifiques et échouez fermé quand il n’est pas dispo.

Exim : même physique, autres knobs

Exim vous laissera aussi tirer la mauvaise configuration TLS. Le principe guide est le même : présentez une chaîne complète, assurez la correspondance de nom, gardez des versions de protocole modernes, et testez avec et sans SNI si pertinent.

Trois mini-récits d’entreprise du terrain

1) La panne causée par une mauvaise hypothèse

L’entreprise avait une unique gateway mail gérant l’inbound pour plusieurs marques. Le DNS était propre, les MX pointaient vers mx.brand-a.example et mx.brand-b.example, tous deux résolvant vers la même IP. L’équipe a renouvelé les certificats via un client ACME, et tout « semblait correct » depuis un navigateur.

Lundi matin, un sous-ensemble de partenaires a commencé à différer le mail vers la marque B. Les logs montraient « TLS handshake failed » côté expéditeur, tandis que le récepteur voyait « lost connection after STARTTLS » sans erreurs de certificat évidentes. L’ingénieur on-call a fait ce que beaucoup font sous pression : a activé plus de logs et a fixé les yeux dessus. Rien.

L’hypothèse erronée était subtile : ils croyaient que tous les clients SMTP envoient SNI comme les clients web modernes. Beaucoup le faisaient. D’autres non. Ces clients recevaient le certificat par défaut—le certificat de la marque A—parce que le démon mail sélectionnait le premier certificat configuré en absence de SNI.

La correction n’a pas été de supplier les partenaires de se mettre à jour. La correction a été de rendre SNI non nécessaire pour la correction. Ils ont émis un certificat avec des SANs couvrant les deux hostnames MX et configuré le service SMTP pour présenter ce certificat unique. Ils ont aussi mis à jour la supervision pour tester avec et sans SNI, parce que la réalité a des coins.

Après coup, l’équipe a écrit la règle qui aurait dû exister : pour le SMTP public, SNI est une fonctionnalité de performance/organisation, pas une dépendance de correction—sauf si vous avez explicitement validé votre écosystème de pairs.

2) L’optimisation qui s’est retournée contre eux

Une autre organisation était fière d’avoir durci la sécurité. Ils ont désactivé TLS 1.2 sur leur service de submission parce que « TLS 1.3 est plus sûr et plus rapide. » Cela a été déployé avec un nouveau load balancer et un joli rapport de conformité. Tout le monde dormait bien.

Deux semaines plus tard, une vague de plaintes d’utilisateurs : clients mail mobiles incapables d’envoyer de façon intermittente. Pas tous les clients. Pas tous les réseaux. Bien sûr. Le helpdesk a accusé des mots de passe et forcé des réinitialisations, aggravant le problème et énervant les utilisateurs.

La cause racine était la compatibilité : plusieurs clients mobiles gérés en entreprise négociaient encore TLS 1.2 uniquement. Ces clients n’étaient pas « faux » tant que « lents à mettre à jour », état par défaut de la gestion des endpoints en entreprise. Les logs du LB montraient des échecs de handshake ; les logs applicatifs étaient en grande partie silencieux.

La correction a été de réactiver TLS 1.2 sur la submission et de préférer TLS 1.3. Ils ont aussi déplacé le processus de changement de posture de sécurité pour inclure un test de compatibilité canari : avant de désactiver une version de protocole, mesurer qui l’utilise encore sur le bord de submission.

La leçon : les améliorations de sécurité qui cassent l’email ne sont pas des améliorations ; ce sont des attaques de productivité auto-infligées.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Un fournisseur SaaS de taille moyenne exploitait ses relayeurs mail dans deux datacenters. Rien d’exotique. Ils faisaient deux choses religieusement : tenir l’inventaire des certificats dans la gestion de configuration, et exécuter des sondes synthétiques quotidiennes qui validaient les handshakes TLS comme le feraient de vrais pairs SMTP.

Un jour, une CA a fait tourner un intermédiaire de manière parfaitement légitime. Leur client ACME a renouvelé le leaf, mais la pipeline de déploiement a accidentellement envoyé seulement le leaf à un des relayeurs d’un datacenter—sans l’intermédiaire. La moitié de leurs livraisons sortantes ont commencé à être différées par des récepteurs plus stricts. L’autre moitié continuait de passer, car l’autre datacenter était configuré correctement.

Pourquoi ça n’est pas devenu un « incident majeur » : leur sonde synthétique l’a détecté en quelques minutes parce qu’elle testait openssl s_client -starttls smtp -showcerts et vérifiait la longueur de chaîne et le statut de vérification. L’alerte n’était pas « file d’attente mail élevée ». C’était « chaîne TLS incomplète sur mx2. » Précis, exploitable, ennuyeux.

Le rollback a été immédiat. Pas d’héroïsme. Pas d’archéologie Slack. Juste un redeploy propre avec le fullchain correct et un postmortem axé sur pourquoi la pipeline a permis un artifact de chaîne partielle.

La correction ennuyeuse est sous-estimée jusqu’à ce qu’elle soit la seule chose entre vous et une semaine de réputation « email peu fiable ».

Erreurs courantes : symptôme → cause → fix

1) Symptom: “STARTTLS not offered”

• Cause racine : TLS désactivé dans le MTA, mauvais service (submission vs MX), ou un proxy/load balancer qui strippe les extensions.
• Fix : Confirmez avec une sonde EHLO brute. Activez STARTTLS sur le listener correct. Si un proxy est en frontal, assurez-vous qu’il transmet SMTP de façon transparente ou qu’il termine TLS correctement.

2) Symptom: “lost connection after STARTTLS” on your server logs

• Cause racine : le pair a abandonné le handshake à cause d’une chaîne non approuvée, d’un mismatch hostname, ou d’une incompatibilité protocole/cipher.
• Fix : Exécutez openssl s_client -starttls smtp -servername ... -showcerts depuis le côté pair si possible ; sinon reproduisez depuis un hôte externe. Validez la complétude de la chaîne et le protocole négocié.

3) Symptom: “verify error:num=20 unable to get local issuer certificate”

• Cause racine : intermédiaire(s) manquant(s) dans ce que le serveur présente.
• Fix : configurez le service pour présenter la chaîne complète (leaf + intermédiaires). N’assumez pas que les clients vont récupérer l’AIA.

4) Symptom: “certificate has expired” but you renewed it

• Cause racine : le service utilise encore l’ancien fichier, reload pas effectué, mauvais listener mis à jour, ou un load balancer qui termine TLS avec son propre cert.
• Fix : interrogez le certificat live et comparez son numéro de série/dates avec le disque. Reloadez le bon démon. Mettez à jour le store du load balancer s’il termine TLS.

5) Symptom: “wrong version number” in OpenSSL

• Cause racine : vous vous êtes connecté en TLS implicite sur un port STARTTLS (ou inversement), ou un service non-TLS écoute sur ce port.
• Fix : utilisez -starttls smtp pour les ports 25/587 et openssl s_client -connect host:465 pour 465.

6) Symptom: works from some senders, fails from others

• Cause racine : dépendance SNI, différences de présentation de chaîne entre nœuds, ou pairs avec différents magasins de confiance/support protocole.
• Fix : testez avec et sans SNI ; testez chaque nœud/IP MX ; assurez un déploiement de chaîne cohérent sur la flotte.

7) Symptom: handshake failure only after a crypto library upgrade

• Cause racine : defaults plus stricts (taille clé minimum, algorithmes de signature, ciphers legacy désactivés).
• Fix : inspectez la signature/cipher négociée, ajustez la politique intentionnellement, et documentez les exceptions. Ne réactivez pas globalement des algorithmes obsolètes sans justification.

Blague 2 : Si vous activez encore TLS 1.0 « pour ce partenaire », vous adoptez essentiellement un tigre domestique parce qu’il avait l’air seul.

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

Checklist d’incident : faire circuler le mail sans créer un incident de sécurité

1. Reproduire depuis le point de vue qui échoue. Même hôte/réseau si possible.
2. Identifier le mode : STARTTLS (25/587) vs TLS implicite (465).
3. Capturer la preuve du handshake : protocole, cipher, chaîne présentée, code de vérification.
4. Valider le nom : quel hostname les pairs utilisent (MX), et est-il présent dans le SAN ?
5. Valider la complétude de la chaîne : leaf + intermédiaires présentés, correctement ordonnés.
6. Vérifier expiration et sync horaire : dates du certificat, horloge système, statut NTP.
7. Vérifier le comportement SNI : comparer la sonde avec et sans -servername.
8. Vérifier la cohérence de la flotte : tester chaque IP MX directement, pas seulement le nom.
9. Ce n’est qu’ensuite qu’il faut ajuster la politique TLS : protocoles/ciphers minimum, exceptions par pair si critique pour l’entreprise.
10. Déployer prudemment : recharger les services, confirmer le certificat live, et relancer les sondes.
11. Fermer la boucle : vider les files, surveiller les déferrals, confirmer l’acceptation par les partenaires.
12. Rédiger la note post-incident : ce qui a cassé, ce que la détection a manqué, ce que vous automatiserez.

Checklist de durcissement : garder la compatibilité sans être imprudent

• Activer TLS 1.2 et TLS 1.3 ; désactiver TLS 1.0/1.1 sur les services exposés sauf exception scellée et limitée.
• Préférer les ciphers AEAD ; éviter les échanges statiques RSA.
• Utiliser un certificat avec SANs correspondant aux hostnames MX. Ne comptez pas sur le CN seul.
• Présenter une chaîne complète (leaf + intermédiaires). Testez avec un vérificateur strict.
• Automatiser les renouvellements et les reloads, et vérifier la présentation live après déploiement.
• Superviser depuis l’extérieur avec des sondes STARTTLS, pas seulement des vérifs HTTPS.
• Documenter où TLS est terminé (MTA vs load balancer). Un seul point de terminaison par flux est une caractéristique de sanity.

Plan de gestion du changement : faire des modifications TLS sans pannes surprises

1. Collecter la télémétrie : versions de protocole et ciphers négociés actuellement (sur submission et si possible sur inbound).
2. Stagez les changements sur un nœud (canari MX), mesurez les déferrals et erreurs de handshake.
3. Communiquez en avance les changements impactant les partenaires quand vous imposez TLS.
4. Déployez sur la flotte avec validation automatisée : sondez chaque nœud/IP et vérifiez chaîne et correspondance de nom.
5. Gardez une voie de rollback d’urgence qui n’implique pas de réactiver globalement des protocoles dépréciés.

FAQ

1) Pourquoi OpenSSL vérifie OK mais Postfix (ou un partenaire) échoue toujours ?

Magasins de confiance différents, defaults différents, et parfois comportement SNI différent. OpenSSL peut utiliser le bundle CA de l’OS ; votre MTA peut utiliser un fichier CA personnalisé ou des maps de politique plus strictes.

2) Dois-je inclure la CA racine dans la chaîne que je présente ?

Normalement non. Présentez leaf + intermédiaires. Les racines appartiennent aux magasins clients. Inclure la racine aide rarement et peut parfois embrouiller des clients cassés.

3) Quelle est la faute la plus courante sur les chaînes ?

Déployer seulement le certificat leaf. Les clients SMTP ne récupéreront souvent pas les intermédiaires, donc la vérification échoue même si « le cert est valide » dans un navigateur.

4) Puis-je corriger les échecs de handshake en autorisant des ciphers plus faibles ?

Parfois, mais c’est souvent la mauvaise solution. Si un pair ne supporte que des ciphers faibles, routez ce trafic via un relais contrôlé avec une politique ciblée. Ne fragilisez pas votre MX principal pour l’internet.

5) Pourquoi certains expéditeurs différeront au lieu de livrer sans TLS ?

Certains expéditeurs appliquent des politiques TLS (exigences par domaine, MTA-STS, DANE, ou conformité interne). Ils préfèrent différer plutôt que risquer une livraison en clair.

6) Que signifie généralement « no suitable signature algorithm » ?

La négociation d’algorithme de signature a échoué—souvent parce que le pair est très ancien ou que votre type cert/clé (RSA-PSS/ECDSA) ne correspond pas à ce qu’il peut valider. La correction est une politique de compatibilité ou la mise à niveau du pair, pas des changements arbitraires de ciphers.

7) Le port 465 est-il « mauvais » pour SMTP ?

Non. Le port 465 est couramment utilisé pour la submission implicite TLS. Pour le transport serveur-à-serveur, le port 25 avec STARTTLS reste la norme. Utilisez le mode adapté à votre audience.

8) Comment savoir si SNI est le problème ?

Faites une sonde avec et sans -servername. Si le certificat change, vous avez une sélection basée sur SNI. Décidez si vous pouvez en dépendre ou émettez un cert couvrant tous les noms requis.

9) Si mon certificat couvre le mauvais hostname—puis-je juste changer l’enregistrement MX ?

Vous pouvez, mais faites-le délibérément. Les noms MX font partie de votre identité mail et de votre empreinte de réputation. Souvent, la correction plus sûre est de réémettre le cert pour correspondre au MX existant et d’aligner DNS, bannière et SANs.

Conclusion : prochaines étapes qui survivent aux audits

Les échecs de handshake TLS SMTP sont rarement « aléatoires ». Ils sont généralement déterministes : mauvais nom, chaîne incomplète, protocole/cipher incompatible, ou déploiement incohérent sur les nœuds. La voie de sortie est d’arrêter de deviner et de commencer à interroger le service live avec des sondes strictes.

Faites ces actions ensuite :

1. Exécutez une sonde STARTTLS avec -showcerts et capturez le protocole/cipher négocié et le code de vérification.
2. Répétez sans SNI et directement contre chaque IP MX pour révéler les certificats par défaut et les dérives.
3. Corrigez la présentation de la chaîne (leaf + intermédiaires) et assurez que les SANs correspondent aux hostnames MX.
4. Gardez TLS 1.2 + 1.3 activés ; évitez les rétrogradations globales pour un seul pair legacy—utilisez des relais ciblés ou une politique par destination.
5. Automatisez la validation : après chaque renouvellement et chaque changement lié au TLS, vérifiez ce que le service présente sur le réseau.

Si vous ne faites qu’une seule chose différemment après avoir lu ceci : cessez de faire confiance au fichier de certificat sur le disque. Faites confiance à ce que le réseau voit.