web-dev-qa-db-fra.com

Fixation StartTls Verify = Échec, VerifyMsg = Impossible d'obtenir un certificat d'émetteur local

Exécution d'Amazon Linux sur l'instance EC2 avec sendmail. J'ai un compte de messagerie avec des solutions réseau et utilisez ce compte comme un SMART_Host Relais dans ma configuration sendmail. Cela fonctionne bien sauf un petit détail.

Dans mon fichier maillog fichier je vois des entrées 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 une petite recherche, je suis arrivé à la conclusion que le verify=FAIL est essentiellement inoffensif: la connexion a été cryptée, c'est juste que le certificat de l'hôte n'a pas pu être vérifié.

Depuis personne, mais moi lit le fichier journal, je ne me soucierais pas. Mais lorsque le message arrive, l'en-tête Received montre

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

J'espérais voir with ESMPTSA Mais je devinerais que la défaillance de la vérification du certificat a entraîné le surpression de la "S".

Comment puis-je obtenir plus de détails sur ce qui n'allait pas avec le certificat et comment éviter l'échec de la vérification? Je suppose que les multiples sous-domaines de mail.example.com.netsolmail.net Ne correspondez pas assez étroitement avec le nom sur le certificat. Mais comment puis-je vérifier cela, et comment puis-je éviter la plainte - ou plus exactement comment puis-je obtenir l'en-tête Received pour accuser réception de la connexion sécurisée avec ESMTPSA.

EDIT: J'ai édité sendmail.mc ajouter

define(`confLOG_LEVEL', `15')dnl

Maintenant, Maillog donne plus de détails. Juste après le verify=FAIL ligne 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 certificate

Je suppose que cela signifie que au moins une cause de la défaillance de la vérification est que Sendmail ne peut pas trouver de certificat pour la machine locale qu'il fonctionne? Puisque je ne fais que relayer le courrier sortant à un serveur Netsol, n'acceptez jamais le courrier entrant sur Internet, je ne pensais pas avoir besoin d'un certificat pour ce serveur. Si j'en ai besoin d'un, où/comment puis-je l'installer? Et peut-il être le même certificat que j'utilise pour mon serveur Web ou ai-je besoin d'un autre? L'utiliser d'un certificat auto-signé soit suffisamment bon pour obtenir le Received en-tête pour dire with ESMTPSA, ou serait-il nécessaire d'être un certificat commercial d'une ca?

Edit n ° 2:

J'accepte la réponse de @madhatter. La clé obtenait confCACERT défini. Je suis gêné, ma seule excuse est le vieil cerveau sénile ne répond pas à la source M4. Le fichier sendmail.mc par défaut sur Amazon Linux avait déjà eu

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

en cela, et j'avais vérifié que le fichier existait. mais J'ai omis de remarquer le petit _ sournois dnl qui était en fait au début de ces lignes! Je sais ce que cela signifie, mais depuis que je regarde très rarement la source M4, et c'était juste après d'autres lignes dnl- ed marquées comme des commentaires avec #, mon cerveau les a enregistrés comme non être commenté!

En fait, j'ai parcouru des gyrations en téléchargeant des certs de Firefox et pointant Sendmail au certificat Digicert que j'utilise pour notre site Web, mais que cet hôte n'envoie jamais, ne reçoit jamais, e-mail, rien d'autre n'était nécessaire. J'ai remis le dnl sur les définitions pour confSERVER_CERT et confSERVER_KEY, et tout allait bien, avec maillog montrant verify=OK et verifymsg=ok sur le document approprié STARTTLS=client lignes.

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

smtpsendmailsmarthost
6
sootsnoot

C'est beaucoup une question dans les parties et je le prendrai comme 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 en informatique (c'est-à-dire que je ne suis pas Eric Allman).

verifymsg=unable to get local issuer certificate

Je suppose que cela signifie que au moins une cause de la défaillance de la vérification est que Sendmail ne peut pas trouver de certificat pour la machine locale qu'il fonctionne?

Cela semble être n message OpenSSL, plutôt qu'un MTA One , et comme je le comprends, cela signifie que l'application de vérification est incapable d'obtenir une copie locale du certificat de l'émetteur. En d'autres termes, Sendmail n'a pas accès à un ensemble de certificats qui inclut le certificat racine de celui qui a émis le certificat du serveur distant. N'oubliez pas que Linux ne fournit pas de service de gestion de certificat centralisé, chaque application doit donc rouler son propre paquet. Dans mon cas, j'ai donné un accès Sendmail à un forfait de certificat avec le code M4 suivant:

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

J'espérais voir avec Esmpsa, mais j'imagine que l'échec de la vérification du certificat a entraîné le surpression du "S".

Je pense que cette hypothèse est fausse. RFC2821 et 2822 sont assez élastiques sur le format d'une en-tête reçue et je ne sais rien qui distingue entre ESMTPA et ESMPTSA (sic). Mes en-têtes montrent toutes des 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 <[email protected]>; Sat, 16 Jul 2016 03:05:24 +0100

Pour comprendre ce que signifie MTA de votre récepteur par ESMTPA, vous devrez découvrir ce que le MTA est et lisez la documentation. Jusqu'à ce que vous ayez fait cela, je ne pense pas que vous puissiez lire beaucoup dans cette collection de lettres.

Puis-je éviter les starttls verify=fail Lorsque le nom d'hôte de serveur ne correspond pas au certificat

Je ne pense pas que tu puisses. L'idée de fondement derrière SSL est celle (a) Le nom d'hôte que vous connectez à (B) offre un certificat signé par une tierce partie fiduciée (c) avec ce nom d'hôte dans le CN ou an SAN champ. Si l'une de ces propriétés n'est pas remplie, il est correct que SSL note qu'il ne peut pas vérifier l'identité de la pair.

Vous ne devriez pas en lire trop; Les certificats auto-signés sont toujours très courants dans la manipulation par courrier électronique. De mes derniers courriels de 1919 TLS-sécurisés envoyés/reçus, 1764 ont impliqué une paite dont l'identité n'a pas pu être vérifiée pour une raison quelconque, tandis que seulement 155 pourraient. Vous courez vous-même avec un certificat auto-signé; Il faut donc être heureux que la plupart des gens ne se soucient pas vraiment de la chaîne de confiance sur les pairs SMTP TLS!

5
MadHatter