Postfix : corriger “Untrusted TLS connection established”

Si vous possédez votre propre serveur email avec Postfix, vous pouvez parfois voir passer cet avertissement dans les logs lorsque Postfix établit une connexion TLS vers un serveur distant :

postfix/smtp[13461]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.166.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)Code language: JavaScript (javascript)

À première vue, le message peut inquiéter. Pourtant, il ne signifie pas forcément que la connexion n’est pas chiffrée. Il signifie plutôt que Postfix a bien établi une connexion TLS, mais qu’il ne considère pas le certificat du serveur distant comme vérifié ou digne de confiance.

En clair : la session est chiffrée, mais la chaîne de confiance du certificat n’a pas été validée comme Postfix l’attendait.

Comprendre le message “Untrusted TLS connection established”

Le log contient deux informations importantes :

• TLS connection established : la connexion TLS a bien été établie ;
• Untrusted : Postfix n’a pas pu valider la confiance du certificat présenté.

Donc le problème ne vient pas forcément du chiffrement lui-même. Il vient souvent de la vérification du certificat : bundle CA absent, chemin CA non déclaré, certificats racines non installés, certificat distant incomplet, ou niveau de sécurité TLS qui ne force pas la validation.

Postfix distingue la configuration TLS côté client SMTP, utilisée quand votre serveur envoie un mail vers un autre serveur, et la configuration TLS côté serveur SMTPD, utilisée quand un autre serveur ou client se connecte au vôtre. Dans les noms de paramètres, smtp_ concerne le client sortant, tandis que smtpd_ concerne le serveur entrant. La documentation TLS de Postfix sépare d’ailleurs clairement les deux rôles.

Vérifier les certificats racines du système

Sur Debian ou Ubuntu, commencez par vérifier que le paquet ca-certificates est installé. C’est lui qui fournit les certificats racines utilisés pour valider les chaînes TLS.

sudo apt update
sudo apt install ca-certificates
sudo update-ca-certificates

Ensuite, vérifiez que le répertoire des certificats existe :

ls -ld /etc/ssl/certs
ls -l /etc/ssl/certs/ca-certificates.crt

Sur Debian et Ubuntu, les deux chemins les plus fréquents sont :

/etc/ssl/certs
/etc/ssl/certs/ca-certificates.crt

Le premier est un répertoire de certificats hachés. Le second est un fichier bundle contenant les certificats racines.

Solution simple : déclarer le CApath dans Postfix

La correction la plus simple consiste à indiquer à Postfix où trouver les certificats d’autorités de certification.

Éditez le fichier main.cf :

sudo nano /etc/postfix/main.cf

Ajoutez ou adaptez ces directives :

smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certsCode language: JavaScript (javascript)

On peut aussi appliquer ces valeurs avec postconf -e :

sudo postconf -e 'smtp_tls_CApath = /etc/ssl/certs'
sudo postconf -e 'smtpd_tls_CApath = /etc/ssl/certs'Code language: JavaScript (javascript)

La documentation Postfix indique que des autorités de certification supplémentaires peuvent être indiquées avec smtp_tls_CApath, et que le répertoire doit être accessible si le service fonctionne dans un environnement chroot.

Testez ensuite la configuration :

sudo postfix check

Puis rechargez Postfix :

sudo systemctl reload postfix

Ou, sur une ancienne distribution :

sudo service postfix reload

Un rechargement suffit généralement pour ce type de changement. Un redémarrage complet fonctionne aussi, mais il est rarement nécessaire.

Alternative : utiliser CAfile au lieu de CApath

On peut aussi pointer Postfix vers le fichier bundle CA du système :

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crtCode language: JavaScript (javascript)

Ou avec postconf :

sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'Code language: JavaScript (javascript)

Le choix entre CAfile et CApath dépend du système et de votre préférence. La documentation Postfix décrit ce choix comme un compromis entre préchargement d’un fichier CA et lecture des certificats depuis un répertoire lorsqu’ils sont nécessaires.

Sur Debian/Ubuntu, j’utilise souvent CApath, car /etc/ssl/certs est maintenu par ca-certificates. Mais CAfile avec /etc/ssl/certs/ca-certificates.crt fonctionne aussi très bien.

Faut-il configurer smtp ou smtpd ?

Il y a une confusion fréquente entre smtp_ et smtpd_.

Pour les connexions sortantes, c’est-à-dire quand votre serveur Postfix envoie un email vers Gmail, Outlook, Yahoo ou un autre MX, les paramètres importants commencent par smtp_.

smtp_tls_CApath = /etc/ssl/certsCode language: JavaScript (javascript)

Pour les connexions entrantes, c’est-à-dire quand un autre serveur ou un client SMTP se connecte à votre serveur, les paramètres commencent par smtpd_.

smtpd_tls_CApath = /etc/ssl/certsCode language: JavaScript (javascript)

Dans le message de log suivant, le processus est postfix/smtp, sans d :

postfix/smtp[13461]: Untrusted TLS connection established to gmail-smtp-in.l.google.com...Code language: HTTP (http)

Il s’agit donc du client SMTP sortant de Postfix. La directive prioritaire est ici smtp_tls_CApath ou smtp_tls_CAfile.

Configurer aussi smtpd_tls_CApath peut être utile pour les connexions entrantes ou l’authentification de certificats clients, mais ce n’est pas forcément ce qui corrige un log postfix/smtp.

Vérifier la configuration active avec postconf

Après modification, vérifiez les valeurs réellement prises en compte par Postfix :

postconf -n | grep -E '^(smtp|smtpd)_tls_CA|smtp_tls_security_level|smtp_tls_loglevel'Code language: JavaScript (javascript)

Vous pouvez aussi vérifier les valeurs par défaut avec :

postconf -d | grep -E '^(smtp|smtpd)_tls_CA'Code language: JavaScript (javascript)

La commande postconf -n affiche uniquement les paramètres dont la valeur diffère de la valeur par défaut. C’est très pratique pour auditer une configuration Postfix sans se noyer dans tout le manuel.

Tester une connexion TLS sortante

Pour tester le comportement TLS vers un serveur distant, Postfix fournit l’outil posttls-finger. Il permet de sonder un serveur SMTP et d’afficher les informations TLS utiles. La documentation de posttls-finger précise qu’il peut utiliser les mêmes niveaux de sécurité TLS que le client SMTP Postfix, notamment may, encrypt, verify, secure ou dane.

posttls-finger -c -L summary gmail-smtp-in.l.google.comCode language: CSS (css)

Pour un test plus verbeux :

posttls-finger -c -L verbose gmail-smtp-in.l.google.comCode language: CSS (css)

Vous pouvez aussi tester avec openssl s_client :

openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com -CApath /etc/ssl/certs

Si le certificat est vérifié, vous devriez voir une ligne de ce type :

Verify return code: 0 (ok)Code language: JavaScript (javascript)

Si la vérification échoue, le problème peut venir du bundle CA local, d’un certificat distant incomplet, d’un nom d’hôte qui ne correspond pas, ou d’un proxy qui intercepte TLS.

Vérifier les logs après correction

Sur Debian ou Ubuntu, les logs Postfix se trouvent souvent dans /var/log/mail.log :

sudo tail -f /var/log/mail.logCode language: JavaScript (javascript)

Sur certaines distributions ou configurations systemd :

sudo journalctl -u postfix -f

Après correction, vous devriez voir un message du type :

postfix/smtp[7243]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c08::1a]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)Code language: JavaScript (javascript)

Selon le serveur distant, la version TLS et le chiffrement peuvent varier. Aujourd’hui, vous verrez souvent du TLS 1.3, mais TLS 1.2 reste encore très courant dans les échanges SMTP.

Activer un niveau de log TLS utile

Si vos logs ne montrent pas assez d’informations TLS, vous pouvez augmenter temporairement le niveau de log :

sudo postconf -e 'smtp_tls_loglevel = 1'
sudo systemctl reload postfixCode language: JavaScript (javascript)

Le niveau 1 suffit généralement pour voir les connexions TLS établies. Évitez de laisser un niveau trop bavard en production, car les logs peuvent grossir vite.

Pour revenir à une configuration plus silencieuse :

sudo postconf -e 'smtp_tls_loglevel = 0'
sudo systemctl reload postfixCode language: JavaScript (javascript)

Attention au niveau smtp_tls_security_level

Le niveau TLS du client SMTP Postfix change beaucoup l’interprétation du message.

Configuration courante pour le SMTP sortant :

smtp_tls_security_level = may

Avec may, Postfix utilise TLS si le serveur distant le propose, mais il peut continuer sans TLS si nécessaire. C’est le mode opportuniste classique pour l’envoi de mail sur Internet. Il améliore la confidentialité quand c’est possible, sans casser la délivrabilité.

Si vous passez à :

smtp_tls_security_level = verify

Postfix exige une connexion TLS avec un certificat vérifiable. C’est plus strict, mais cela peut casser l’envoi vers des serveurs mal configurés.

Pour un serveur mail généraliste, je garderais souvent :

smtp_tls_security_level = may
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_loglevel = 1Code language: JavaScript (javascript)

Pour des destinations spécifiques que vous contrôlez, vous pouvez être plus strict avec une policy TLS dédiée. Mais forcer verify partout sur Internet peut produire des échecs de livraison. Le mail mondial reste un vieux bazar diplomatique, pas un datacenter homogène.

Et DANE/TLSA dans tout ça ?

Si votre domaine utilise DNSSEC et que vous publiez des enregistrements TLSA, vous pouvez aller plus loin avec DANE. DANE permet à Postfix de valider les certificats TLS des serveurs SMTP via le DNS sécurisé, plutôt que de dépendre uniquement des autorités de certification classiques.

Postfix prend en charge le niveau de sécurité dane côté client SMTP. Ce mode utilise DNSSEC et les enregistrements TLSA lorsqu’ils sont disponibles. La documentation de posttls-finger renvoie aussi à la sémantique de smtp_tls_security_level, dont dane.

Exemple :

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

C’est très intéressant pour améliorer la sécurité du transport SMTP, mais cela demande une vraie configuration DNSSEC côté résolveur et une bonne compréhension des enregistrements TLSA. Ce n’est pas une simple option à activer au hasard un vendredi à 18 h 12. Enfin, sauf passion pour les week-ends ruinés.

Ne pas confondre le certificat de votre serveur et les CA distantes

Autre point important : smtpd_tls_cert_file et smtpd_tls_key_file désignent le certificat et la clé privée de votre serveur Postfix. Ces paramètres servent quand votre serveur présente son propre certificat aux clients ou serveurs entrants.

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pemCode language: JavaScript (javascript)

À l’inverse, smtp_tls_CApath ou smtp_tls_CAfile servent à vérifier les certificats des serveurs distants lorsque votre Postfix envoie des mails.

Ce sont deux directions différentes :

• smtpd_tls_cert_file : votre certificat présenté en entrant ;
• smtp_tls_CApath : certificats racines utilisés pour vérifier les serveurs distants en sortant.

Mélanger les deux mène souvent à des corrections qui “semblent TLS”, mais ne changent rien au log concerné.

Configuration complète raisonnable

Voici une base raisonnable pour un serveur Debian/Ubuntu classique qui envoie du mail vers Internet :

# TLS sortant : Postfix comme client SMTP.
smtp_tls_security_level = may
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_loglevel = 1

# TLS entrant : Postfix comme serveur SMTP.
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_CApath = /etc/ssl/certsCode language: PHP (php)

Adaptez évidemment le chemin du certificat à votre domaine et à votre méthode d’émission : Let’s Encrypt, acme.sh, Certbot, certificat commercial, ou certificat interne.

Après modification :

sudo postfix check
sudo systemctl reload postfix

Dépannage rapide

Si le message reste en Untrusted, vérifiez d’abord que les CA sont installées :

dpkg -l ca-certificates
ls -l /etc/ssl/certs
ls -l /etc/ssl/certs/ca-certificates.crt

Vérifiez ensuite la configuration active :

postconf -n | grep -E 'smtp_tls_CA|smtpd_tls_CA|smtp_tls_security_level'Code language: JavaScript (javascript)

Testez une destination précise :

posttls-finger -c -L verbose gmail-smtp-in.l.google.comCode language: CSS (css)

Vérifiez aussi si Postfix tourne en chroot. Si c’est le cas, le chemin CA doit être accessible depuis l’environnement chroot, ce que la documentation Postfix signale explicitement pour smtp_tls_CApath.

Enfin, n’oubliez pas qu’un serveur distant peut lui-même être mal configuré. Si le problème ne concerne qu’une seule destination obscure, il est possible que le certificat distant soit incomplet, expiré, ou incohérent avec le nom du serveur MX.

Mémo rapide

# Installer les certificats racines.
sudo apt update
sudo apt install ca-certificates
sudo update-ca-certificates

# Déclarer le CApath pour le SMTP sortant.
sudo postconf -e 'smtp_tls_CApath = /etc/ssl/certs'

# Déclarer le CApath pour le SMTP entrant.
sudo postconf -e 'smtpd_tls_CApath = /etc/ssl/certs'

# Option alternative avec CAfile.
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'

# Vérifier la configuration.
postconf -n | grep -E 'smtp_tls_CA|smtpd_tls_CA|smtp_tls_security_level'

# Tester Postfix.
sudo postfix check

# Recharger Postfix.
sudo systemctl reload postfix

# Suivre les logs.
sudo tail -f /var/log/mail.log

# Tester une destination SMTP.
posttls-finger -c -L verbose gmail-smtp-in.l.google.com

# Tester avec OpenSSL.
openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com -CApath /etc/ssl/certsCode language: PHP (php)

Conclusion

L’avertissement Untrusted TLS connection established indique généralement que Postfix a bien établi une connexion TLS, mais qu’il ne parvient pas à valider la chaîne de confiance du certificat distant.

Dans la majorité des cas, la correction consiste à installer les certificats racines du système, puis à déclarer le bon chemin CA dans /etc/postfix/main.cf :

smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certsCode language: JavaScript (javascript)

Pour un log postfix/smtp, la directive la plus importante est smtp_tls_CApath, car elle concerne les connexions sortantes. smtpd_tls_CApath concerne les connexions entrantes.

Après correction, les logs devraient afficher plutôt :

Trusted TLS connection established

Ce n’est pas seulement plus joli dans les logs. C’est aussi le signe que Postfix chiffre la session et reconnaît la chaîne de confiance du certificat distant. Le genre de petit message qui fait plaisir quand on aime que les serveurs arrêtent de râler pour de bonnes raisons.

Report a typo