← RFC Reference

RFC 7817 : Vérification d'identité du serveur TLS mise à jour pour le courrier électronique

Pourquoi cela existe

Lorsqu'un client SMTP démarre une connexion TLS vers un serveur de messagerie distant (via STARTTLS selon la RFC 3207 ou TLS implicite selon la RFC 8314), il reçoit un certificat. Mais quel nom d'hôte doit apparaître dans ce certificat ?

Dans le courrier électronique, vous ne vous connectez pas directement au domaine du destinataire. Vous recherchez l'enregistrement MX pour example.com, qui peut pointer vers mail.hosting-provider.net. Le certificat doit-il indiquer example.com ou mail.hosting-provider.net ? La réponse a de l'importance car :

• Vérifier le mauvais nom signifie que les certificats légitimes sont rejetés
• Ne pas vérifier du tout signifie que TLS fournit le chiffrement mais pas l'authentification — un attaquant man-in-the-middle peut présenter n'importe quel certificat
• Les fournisseurs d'hébergement de messagerie servent des milliers de domaines depuis les mêmes serveurs et ne peuvent pas obtenir des certificats pour chaque domaine client

Comment cela fonctionne

RFC 7817 définit une hiérarchie claire pour les identifiants de référence qu'un client doit vérifier par rapport au certificat du serveur, en fonction de la façon dont le serveur a été découvert :

Ordre de vérification d'identité

1. Nom d'hôte MX — si le serveur a été trouvé via une recherche MX, vérifiez le certificat par rapport au nom d'hôte MX (par exemple, mail.hosting-provider.net), et non le domaine destinataire.
2. Domaine destinataire — s'il n'y a pas d'enregistrement MX et que le client revient à un enregistrement A/AAAA pour le domaine lui-même, vérifiez par rapport au domaine destinataire.
3. Configuration explicite — si le serveur a été configuré manuellement (par exemple, un serveur de soumission), vérifiez par rapport au nom d'hôte configuré.

Flux de connexion TLS

; Étape 1 : Résoudre MX pour le domaine destinataire
dig example.com MX
example.com.  IN  MX  10 mail.provider.net.

; Étape 2 : Connectez-vous à l'hôte MX, démarrez SMTP
220 mail.provider.net ESMTP ready
EHLO sender.example.org
250-mail.provider.net
250-STARTTLS
STARTTLS
220 Go ahead

; Étape 3 : Établissement TLS — vérifiez le certificat par rapport à « mail.provider.net »
; Certificate SAN: DNS:mail.provider.net, DNS:*.provider.net
; Match found → identity verified

Détails techniques clés

Règles de correspondance de certificat

Identifiant de référence selon la méthode de découverte

Interaction avec DANE

Lorsque DANE (RFC 7672) est déployé, l'enregistrement TLSA dans DNS épingle le certificat ou la clé publique pour le nom d'hôte MX. DANE fournit une garantie d'identité plus forte que la vérification basée sur l'autorité de certification traditionnelle, car elle ne dépend pas de la confiance envers une autorité de certification — le propriétaire du domaine publie les données de certificat attendues directement dans le DNS signé par DNSSEC.

Erreurs courantes

• Vérifier le certificat par rapport au domaine destinataire. Si MX pour example.com pointe vers mail.google.com, le certificat indiquera mail.google.com, et non example.com. Vérifier le mauvais nom provoque des défaillances TLS ou vous force à ignorer complètement la vérification.
• Passer silencieusement à TLS non authentifié. De nombreux MTA utilisent « TLS opportuniste » — ils chiffrent si possible mais ne vérifient pas les certificats. Cela protège contre l'écoute passive mais pas contre les attaques actives. Utilisez MTA-STS ou DANE pour exiger des connexions authentifiées.
• Mal configurer les certificats sur les hôtes MX. Si votre enregistrement MX pointe vers mx.yourdomain.com mais votre certificat ne couvre que yourdomain.com, les expéditeurs qui vérifient les certificats échoueront. Assurez-vous que le SAN de votre certificat inclut votre nom d'hôte MX.
• Ignorer la validation de la chaîne de certificats. Vérifier le nom d'hôte est nécessaire mais pas suffisant. La chaîne de certificats complète doit être validée vers une autorité de certification de confiance. Les certificats expirés ou auto-signés échoueront toujours même si le nom correspond.
• Ne pas renouveler les certificats avant expiration. Les certificats expirés sur vos serveurs MX provoquent des défaillances d'établissement TLS. Les expéditeurs appliquant MTA-STS refuseront de livrer du courrier à un serveur avec un certificat expiré.

Impact sur la délivrabilité

• L'application de MTA-STS dépend de cela. Lorsqu'un domaine destinataire publie une politique MTA-STS, les serveurs d'envoi doivent vérifier le certificat MX selon RFC 7817. Si votre certificat MX est mal configuré, les expéditeurs appliquant MTA-STS (y compris Gmail) ne vous livreront pas de courrier.
• Google et Microsoft vérifient les certificats. Les grands fournisseurs vérifient de plus en plus les certificats pour le courrier sortant. Les certificats mal configurés sur votre infrastructure de réception peuvent causer des défaillances de livraison de la part de ces expéditeurs.
• DANE/TLSA fournit la garantie la plus forte. DANE lie le certificat à DNSSEC, éliminant complètement la dépendance envers la confiance de l'autorité de certification. Combiné avec les vérifications d'identité RFC 7817, il fournit un transport de courrier authentifié et chiffré.
• Le signalement TLS révèle les problèmes. Rapport SMTP TLS (RFC 8460) vous envoie des rapports lorsque les expéditeurs rencontrent des défaillances TLS en se connectant à vos serveurs, y compris les défaillances de vérification de certificat. Publiez un enregistrement TLSRPT et surveillez ces rapports.

Related RFCs