Dépannage

Pourquoi des erreurs TLS surviennent-elles lors de la connexion SMTP ?

Corrigez les erreurs de négociation SSL et TLS avec smtp.emailit.com, comme « wrong version number », les noms de certificat qui ne correspondent pas et les échecs de STARTTLS.

Mis à jour le 1 oct. 2026

Cet article traite des erreurs qui surviennent pendant que votre client et le relais SMTP d’Emailit mettent en place le chiffrement. Elles proviennent presque toujours d’une incohérence entre le port et le mode TLS configuré dans votre client.

Symptômes

SSL routines:ssl3_get_record:wrong version number ou ERR_SSL_WRONG_VERSION_NUMBER
Hostname/IP does not match certificate's altnames ou certificate verify failed
STARTTLS failed, Greeting never received ou une connexion qui reste bloquée une fois établie
unsupported protocol ou no protocols available

Cause

Emailit utilise deux modes TLS, et chaque port attend l’un d’eux :

Port	Mode	Réglage habituel du client
587, 2525, 2587, 25	STARTTLS : la session démarre en clair, puis passe en chiffré	Nodemailer `secure: false`, PHPMailer `ENCRYPTION_STARTTLS`, « TLS » dans la plupart des interfaces
465	TLS implicite : chiffré dès le premier octet	Nodemailer `secure: true`, PHPMailer `ENCRYPTION_SMTPS`, « SSL » dans la plupart des interfaces

Les causes fréquentes sont les suivantes :

TLS implicite sur un port STARTTLS, par exemple secure: true avec le port 587. Le client attend une négociation TLS mais reçoit un message d’accueil en clair, ce qui produit « wrong version number ».
STARTTLS sur le port 465. Le client attend un message d’accueil que le serveur n’envoie jamais en clair : la connexion reste donc bloquée.
Connexion par adresse IP ou via votre propre CNAME. Le certificat est émis pour smtp.emailit.com : tout autre nom d’hôte échoue à la vérification.
Une pile TLS ancienne. Le relais négocie TLS 1.2 ou TLS 1.3. Les clients limités à TLS 1.0 ou 1.1, ou dont le magasin de certificats d’autorité est obsolète, ne peuvent pas terminer la négociation.
Inspection du trafic. Certains antivirus et proxys d’entreprise interceptent le SMTP et présentent leur propre certificat.

Solution

Faites correspondre le port et le mode. Utilisez le port 587 avec STARTTLS, ou le port 465 avec TLS implicite. Ne les mélangez pas.

mailer.js

const transporter = nodemailer.createTransport({
  host: 'smtp.emailit.com',
  port: 587,
  secure: false,     // STARTTLS on 587; set true only for port 465
  requireTLS: true,  // refuse to send if the upgrade fails
  auth: { user: 'emailit', pass: process.env.EMAILIT_API_KEY },
});

Utilisez le nom d’hôte exact. Définissez l’hôte sur smtp.emailit.com. N’utilisez ni adresse IP ni alias.
Exigez le chiffrement dans votre client. STARTTLS est proposé sur chaque port non chiffré, mais le relais ne l’impose pas. Activez l’option « require TLS » de votre client pour que les identifiants ne soient jamais envoyés en clair.
Testez la négociation depuis la machine qui envoie.
Terminal
```
openssl s_client -starttls smtp -connect smtp.emailit.com:587 -servername smtp.emailit.com
openssl s_client -connect smtp.emailit.com:465 -servername smtp.emailit.com
```
Un résultat correct affiche subject=CN=smtp.emailit.com et Verify return code: 0 (ok). Un autre sujet signifie qu’un élément de votre réseau intercepte la connexion.
Mettez à jour les environnements anciens. Mettez à niveau l’environnement d’exécution du langage ou OpenSSL, ainsi que les certificats d’autorité du système, si votre client ne parvient pas à négocier TLS 1.2.

Si la négociation réussit mais que l’authentification échoue, consultez Pourquoi SMTP renvoie-t-il l’erreur 535 Authentication failed ?. Si vous ne parvenez pas du tout à vous connecter, consultez Pourquoi ma connexion SMTP expire-t-elle ?.

Le problème persiste ?

Contactez le support ou posez votre question sur Discord. Indiquez le port, votre bibliothèque cliente et sa version, ainsi que le résultat de la commande openssl s_client.

Symptômes

Cause

Solution

Le problème persiste ?

Le problème persiste ?