Fixing starttls verify = fail, verifymsg = impossible d'get un certificate d'émetteur local

Exécution d'Amazon Linux sur l'instance EC2 avec sendmail . J'ai un count de messagerie avec Network Solutions et j'utilise ce count comme un relais SMART_HOST dans ma configuration de sendmail . Il fonctionne bien sauf un petit détail.

Dans mon file maillog , je vois des inputs comme ceci:

 sendmail[28450]: STARTTLS=client, relay=mail.example.com.netsolmail.net., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256 

Après un peu de search, je suis arrivé à la conclusion que la verify=FAIL est essentiellement inoffensive: la connection a effectivement été chiffrée, c'est juste que le certificate de l'hôte n'a pas pu être vérifié.

Puisque personne, sauf moi, lit le file journal, je m'en fous. Mais lorsque le message arrive, l'en-tête Received s'affiche

 Received: from unknown (HELO example.com) (info@example.com@12.34.56.78) by 0 with ESMTPA; 15 Aug 2016 07:10:15 -0000 

J'espérais voir with ESMPTSA mais j'imagine que l'échec de la vérification des certificates a provoqué la sursistance du «S».

Comment puis-je get plus de détails sur ce qui ne va pas avec le certificate et comment éviter l'échec de la vérification? Je suppose que les sous-domaines multiples de mail.example.com.netsolmail.net ne correspondent pas assez étroitement avec le nom sur le certificate. Mais comment puis-je vérifier cela, et comment puis-je éviter la plainte – ou plus exactement comment puis-je get l'en-tête Received pour reconnaître la connection sécurisée avec ESMTPSA .

EDIT: J'ai édité sendmail.mc pour append

 define(`confLOG_LEVEL', `15')dnl 

Maintenant, maillog donne plus de détails. Juste après la ligne verify=FAIL , je vois maintenant:

 sendmail[30706]: STARTTLS=client, cert-subject=/OU=GT39680792/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.hostingplatform.com, cert-issuer=/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3, verifymsg=unable to get local issuer certificatee 

Je suppose que cela signifie qu'au less une des causes de l'échec de la vérification est que sendmail ne peut pas find un certificate pour la machine locale sur laquelle il fonctionne? Puisque je ne transmet que le courrier sortant à un server netsol, n'accepte jamais le courrier entrant d'Internet, je ne pense pas avoir besoin d'un certificate pour ce server. Si j'ai besoin d'un, où / comment puis-je l'installer? Et peut-il être le même certificate que j'utilise pour mon server web ou ai-je besoin d'un autre? L'utilisation d'un certificate auto-signé serait-elle suffisante pour get l'en-tête Received pour dire with ESMTPSA ou devrait-il être un certificate commercial d'une autorité de certificateion?

EDIT # 2:

J'accepte la réponse par @MadHatter. La key a été définie par confCACERT . Je suis embarrassé, ma seule excuse est l'ancienne source sénelle du cerveau qui n'est pas la source de m4. Le file sendmail.mc par défaut sur Amazon Linux a déjà eu

 define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl 

en elle, et j'ai vérifié que le file existait. Mais je n'ai pas remarqué le petit dnl sournois qui était en fait au début de ces lignes! Je sais ce que cela signifie, mais comme je regarde très rarement la source M4, et c'est juste après quelques autres lignes qui ont été marquées comme des commentaires avec # , mon cerveau les a inscrit comme n'étant pas commenté!

J'ai réellement passé par un tas de gyrations en téléchargeant des certs de Firefox et en envoyant sendmail au certificate Digicert que j'utilise pour notre site Web, mais puisque cet hôte ne l'envoie jamais, ne reçoit jamais, le courrier électronique, rien d'autre n'était nécessaire. Je remets le dnl sur les définitions pour confSERVER_CERT et confSERVER_KEY , et tout était bien, avec maillog montrant verify=OK et verifymsg=ok sur les STARTTLS=client lignes STARTTLS=client appropriées.

Mais même s'il n'y avait pas de diagnostic sur TLS, l'en-tête Received pour la connection à Netsol s'affiche toujours with ESMTPA et non with ESMTPSA . Oh bien, @MadHatter avait le dope sur celui-là aussi. Désolé, c'était si longtime et une sorte de chasse sauvage. Mais j'ai beaucoup appris, et j'ai amélioré ma configuration (de manière non vitale). J'espère que quelqu'un assez désespéré pour traverser cela pourrait apprendre quelque chose aussi.

C'est très une question en partie, et je vais le prendre en tant que tel. J'ai utilisé sendmail comme mon MTA préféré depuis quelques décennies, mais je ne peux pas prétendre être un expert (c'est-à-dire, je ne suis pas Eric Allman).

verifymsg=unable to get local issuer certificatee

Je suppose que cela signifie qu'au less une des causes de l'échec de la vérification est que sendmail ne peut pas find un certificate pour la machine locale sur laquelle il fonctionne?

Cela semble être un message OpenSSL, plutôt qu'un MTA , et, si je comprends bien, cela signifie que l'application vérifiant ne peut pas get une copy locale du certificate de l'émetteur. En d'autres termes, sendmail n'a pas access à un lot de certificates qui inclut le certificate racine pour celui qui a délivré le certificate du server distant. N'oubliez pas que Linux ne fournit pas de service centralisé de gestion des certificates, donc chaque application doit générer son propre lot. Dans mon cas, j'ai donné un access sendmail à un lot de certificates avec le code m4 suivant:

 define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.with.intermediate.crt')dnl 

J'espérais voir avec ESMPTSA mais j'imagine que l'échec de la vérification des certificates a provoqué la sursistance du «S».

Je pense que la conjecture est fausse. RFC2821 et 2822 sont assez élastiques sur le format d'un reçu: en-tête, et je ne trouve rien qui distingue entre ESMTPA et ESMPTSA (sic). Mes en-têtes montrent toutes les lignes telles que:

 Received: from example.com (example.com [80.70.90.61]) by lory.teaparty.net (8.14.4/8.14.4) with ESMTP id u6G25OXi006577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <me@example.net>; Sat, 16 Jul 2016 03:05:24 +0100 

Pour comprendre ce que veut dire le MTA de votre destinataire par ESMTPA , il faudrait savoir ce qu'est ce MTA et lire la documentation. Jusqu'à ce que vous l'ayez fait, je ne pense pas que vous pouvez lire beaucoup dans cette collection de lettres.

Puis-je éviter les startups verify=fail lorsque le nom d'hôte du server ne correspond pas au certificate

Je ne pense pas que vous le pouvez. L'idée fondamental derrière SSL est que (a) le nom d'hôte auquel vous vous connectez (b) offre un certificate signé par un tiers de confiance (c) avec ce nom d'hôte dans le champ CN ou SAN. Si l'une de ces propriétés n'est pas remplie, il est juste que SSL constate qu'il ne peut pas vérifier l'identité du pair.

Vous ne devriez pas lire trop dedans; les certificates auto-signés sont encore très courants dans la gestion des courriels. De mes derniers emails sécurisés TLS de 1919 envoyés / reçus, 1764 impliquaient un pair dont l'identité ne pouvait être vérifiée pour une raison quelconque, alors que seulement 155 pouvaient. Vous utilisez vous-même un certificate auto-signé; vous devriez donc être heureux que la plupart des gens ne se soucient pas vraiment de la string de confiance sur les pairs SMTP TLS!