J’ai monté un serveur de mail basé sur postfix et dovecot (quelle originalité). À la fin je tombe sur un os au niveau de la configuration tls.
Sur cryptcheck j’ai une note « M » (https://tls.imirhil.fr/smtp/imap.katzei.fr) ce qui d’après le documentation indique un que le certificat ne correspond pas au domaine.
Si je fais le test sur le serveur dovecot (même machine/domain, port 995) j’ai une note B.
Quand je récupère le certificat avec openssl (openssl s_client -showcerts -starttls smtp -crlf -connect imap.katzei.fr:587 | openssl x509 -noout -text) le certificat récupéré est le bon.
Le problème est que les deux services utilisent le même certificat, et sont sur le même domaine.
Quelqu’un a-t-il une idée de quel pourrait être la source du problème ?
J’ai joué un peu aussi avec cryptcheck ce soir (où as-tu trouvé la doc d’ailleurs ? Je n’ai rien trouvé de tel). Est-il possible que ce soit juste un problème de cache ? Le site semble conserver le résultat au moins plusieurs heures, est-ce que tu as fixé le problème entretemps et le site montre donc juste un résultat trop ancien ?
Pour le cache non. J’ai ce problème depuis plusieurs jours et j’utilise différents domaines (présents dans le certificat) pour les tests. Imap.katzei.fr n’est q’un des alt name du certificat X509 mais j’ai exactement le même problème avec le name (imap.meewan.fr).
Vu les symptômes c’est clairement un problème de configuration de postfix mais pour l’instant j’ai pas trouvé d’où ça vient.
Concernant SMTP, vouloir obtenir une note correcte est à double tranchant, ça veut dire que tu prends le risque qu’à défaut de chiffrement même faible, les serveurs mal configurés vont fallbacker sur du clair.
Dans ton cas, d’après ce que je vois sur le nouveau résultat de cryptcheck tu dois désactiver tlsv1 et tlsv1_1 si tu veux une « bonne » note (smtpd_tls_protocols)
Concernant le host mismatch j’ai une petite piste :
Lorsque je contacte ton serveur sur le port 25 (et non pas 587, mais ça change rien ici), j’obtiens une liste de certificats, qui contient effectivement imap.katzei.fr et plein d’autres trucs, mais pas katzei.fr . Or (attention raisonnement circulaire), quand je vais sur le récap cryptcheck, on voit imap.katzei tout en haut mais katzei.fr en sous-section. « katzei.fr » n’est pas dans la liste des certificats, et le rapport de mismatch de cryptcheck vient de là.
D’où sort ce katzei.fr ? Quand tu fais dig imap.katzei.fr in mx, tu obtiens
imap.katzei.fr. 60 IN CNAME katzei.fr.
katzei.fr. 60 IN MX 100 katzei.fr.
Donc tu dis que le serveur qui gère les mails pour le domaine @imap.katzei.fr est katzei.fr, et c’est ce dernier que cryptcheck interroge (sur le port 25 donc), et là paf mismatch.
Je crois ue tu as un problème de CNAME à régler par ailleurs du coup
Dernière chose. Si tu ne veux pas être catalogué comme un spammeur (mais là c’est en envoi, cryptcheck ne te dira rien là dessus), tu vas devoir déclarer correctement ton reverse DNS. Actuellement, il y a:
$ dig -x 82.248.32.170
170.32.248.82.in-addr.arpa. 7882 IN PTR lns-bzn-27-82-248-32-170.adsl.proxad.net.
Tu dois le remplacer (dans la config de ta freebox) par ce que postfix déclare dans le EHLO initial (c’est le contenu de myhostname dans la conf postfix)
Ok si tu passes par le relai smtp et que tu ne contactes jamais toi-même les hotes alors pas besoin du reverse. Le CNAME c’est dangereux (surtout parce qu’en général on présente ça comme « un alias » alors ça vient avec des contraintes) et ton erreur est en réalité une erreur assez commune.
De mon côté après avoir fait plusieurs bourdes avec les CNAME j’ai fini par ne plus les utiliser du tout.
La section restriction de https://en.wikipedia.org/wiki/CNAME_record peut t’aider (tu es dans le cas du dernier point )
Après quelque test c’est pas un problème de cname mais un problème de compréhension du champ MX et du protocol SMTP. J’ai eu un F \o/ (j’ai revert la conf DNS, je ferais un truc propre ce soir, le certificat que j’utilise est pas bon, il faut que j’en génère un autre)
Bref lire la doc des logiciel c’est bien, lire celle des protocols c’est bien aussi
Merci beaucoup pour ton aide (je regarderai les autres points que tu as soulevé ce soir)
En théorie TLSv1.0 et TLSv1.1 sont deprecated, mais certains mail providers / clients continuent à l’utiliser, il n’est donc pas absurde d’assurer cette rétrocompatibilité pour un temps.