Résumé : si t'as configuré ton serveur d'emails Postfix pour qu'il prenne en compte les enregistrements DNS DANE TLSA et qu'un email n'est pas envoyé au motif d'erreur « Server certificate not verified », vérifie la validité de l'enregistrement TLSA associé au serveur emails du destinataire avec l'outil tlsa
de la suite logicielle hash-slinger : il ne correspond très probablement pas au certificat x509 présenté par le serveur emails. Contacte l'hébergeur du serveur en utilisant whois -B <adresse_IP_du_serveur
. On notera que le message d'erreur de Postfix n'est pas explicite, donc qu'il y a encore du boulot de ce côté-là avant une généralisation de DANE TLSA.
DANE TLSA permet de stocker, dans le DNS signé avec DNSSEC, les certificats x509 afin d'obtenir une deuxième chaîne de validation et de combler ainsi les immenses lacunes conceptuelles du modèle de sécurité de la norme x509. Détails et utilisation concrète ici.
Il y a quelques jours, j'ai rencontré, en production, mon premier pépin dont l'origine est DANE TLSA.
J'envoie un email. Un jour après, pour comprendre une toute autre chose, je consulte le journal de Postfix, mon serveur d'emails. Par hasard (tail -f
et nouvelle tentative d'envoi récente), j'y lis ceci :
postfix/smtp[23743]: 235AB2AE: to=[CENSURE], relay=[CENSURE][[CENSURE]]:25, delay=82176, delays=82176/0.15/0.13/0, dsn=4.7.5, status=deferred (Server certificate not verified)
Notons que si je n'avais pas consulté le journal, j'aurais quand même été informé du problème en recevant, après 5 jours (valeur par défaut du paramètre maximal_queue_lifetime
de Postfix), un email présentant le problème émis par « Mail Delivery System / MAILER-DAEMON », c'est-à-dire Postfix lui-même.
Je cherche à obtenir plus d'infos.
Ajouter « -v » dans la colonne « command + args » des services « tlsmgr » et « smtp » dans master.cf
(exemple : « tlsmgr unix - - y 1000? 1 tlsmgr -v ») + systemctl reload postfix
rend Postfix plus causant mais cela m'apprend rien.
Dans main.cf
, je suis déjà en smtp_tls_loglevel = 1
. En changer la valeur pour « 2 » et recharger Postfix ne m'en apprendra pas d'avantage.
Rien permet de comprendre l'origine du problème, pas un seul indice. Un message d'erreur explicite serait le bienvenu avant une généralisation de DANE TLSA.
Je connais les compétences des salariés de l'hébergeur emails de mon destinataire, donc je choisis de remettre en cause mon installation plutôt que la leur.
Comme m'y incite le premier résultat d'une recherche du message d'erreur « Server certificate not verified » dans un moteur de recherche, je commence à creuser la politique de validation d'un certificat x509 appliquée par Postfix (paramètres smtp_tls_(verify|secure)_cert_match
) : avec quoi compare-t-on le Common Name / SubjectAltName ? Avec le nom du serveur ? Avec le nom de domaine du destinataire ? Avec celui de l'hébergeur emails ? Ma recherche en ce sens donnera rien.
Je réfléchis (enfin). Comme l'écrasante majorité des serveurs emails, le mien est configuré pour tenter un envoi en clair si l'envoi chiffré a été impossible (on nomme ça TLS / chiffrement opportuniste). Pourquoi mon serveur n'a pas agit comme ça cette fois-ci ?
Il est configuré pour prendre en compte les enregistrements DNS TLSA : smtp_dns_support_level=dnssec
+ smtp_tls_security_level=dane
(attention : les versions de TLS et les suites de chiffrement autorisées se définissent désormais dans smtp_tls_mandatory_protocols
et smtp_tls_mandatory_ciphers
!). Si l'hébergeur emails du destinataire a positionné un enregistrement TLSA, cela signifie qu'il veut qu'on échange avec lui de manière chiffrée, donc on n'essaye pas de communiquer en clair. DANE TLSA pallie à la principale limite du chiffrement opportuniste : sans TLSA, si le message d'initialisation du chiffrement, STARTTLS, est perdu ou volontairement stoppé par un méchant, alors la communication s'effectue sans chiffrement.
Je vérifie la présence d'un enregistrement TLSA avec dig TLSA _25._tcp.<nom_du_smtp_distant_qui_est_mentionné_dans_relay_dans_le_journal_Postfix>
. Il y en a bien un.
J'utilise tlsa
, un petit script de la collection hash-slinger (qui permet, également et entre autres, la manipulation des enregistrements DNS SSHFP et des enregistrements DNS DANE OpenPGP) pour vérifier la validité de cet enregistrement.
Attention si tu utilises Debian GNU/Linux Buster : hash-slinger n'est pas empaqueté dans cette version à cause d'une dépendance à python3-m2crypto non satisfaite. La version de hash-slinger qui utilise python2 que t'as pu installer avant de mettre à jour ton système pourrait ne pas fonctionner dans certains cas à cause de l'obsolescence de la bibliothèque TLS (« M2Crypto.SSL.SSLError: wrong version number », c'est du vécu). Bref : sudo apt-get install swig && pip3 install m2crypto
+ installer hash-slinger depuis le dépôt git officiel (git clone
+ sudo make install
).
Je vérifie donc la validité de l'enregistrement TLSA positionné par l'hebergeur emails :
$ tlsa --verify --port 25 <nom_du_smtp_distant_qui_est_mentionné_dans_relay_dans_le_journal_Postfix>
FAIL (Usage 3 [DANE-EE]): Certificate offered by the server does not match the TLSA record ([CENSURE])
Oups… Tout s'explique… Le certificat x509 présenté par le serveur emails ne correspond pas à l'enregistrement TLSA.
Afin d'être sûr de moi, je calcule moi-même le RDATA de l'enregistrement DNS en fonction du certificat actuellement utilisé avec $ openssl s_client -connect [CENSURE]:25 -starttls smtp -showcerts < /dev/null 2> /dev/null | openssl x509 -pubkey | openssl rsa -pubin | head -n -1 | tail -n +2 | base64 -d | sha256sum
et, oui, il ne correspond pas à celui mis en service. Pour les détails : l'enregistrement présent est un condensat SHA-256 (mtype = 1) de la clé publique (selector = 1) du seul certificat du serveur (usage = 3), d'où cet enchaînement de commandes publié sur le blog de Stéphane Bortzmeyer pour le synthétiser.
Je contacte l'hébergeur emails. Comment ? whois -B <IP_du_serveur_emails>
. D'une manière générale, ne pas oublier « -B » : cela permet d'obtenir des adresses emails autres que celle qui permet de signaler les abus. J'ai mis de côté d'autres paramètres bien utiles de la commande whois
dans mon article Découvrons la RIPE database.
En fin de matinée du premier jour ouvré suivant mon email, l'enregistrement DANE TLSA a été retiré. Fin du problème, mais c'est dommage d'avoir laissé tomber… Peut-être est-ce un repli stratégique pour réfléchir à un meilleur déploiement, avec supervision et tout et tout ?