web-dev-qa-db-ja.com

starttls verify = fail、verifymsg =ローカル発行者証明書を取得できませんの修正

sendmailを使用してEC2インスタンスでAmazon Linuxを実行します。 Network Solutionsのメールアカウントを持っています。そのアカウントをsendmail構成でSMART_Hostリレーとして使用しています。細かい点を除けばうまく機能します。

私のmaillogファイルには、次のようなエントリがあります。

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

少し調べた結果、verify=FAILは基本的に無害であるという結論に達しました。接続は実際には暗号化されていますが、ホストの証明書を検証できなかっただけです。

私以外は誰もログファイルを読み取らないので、気にしません。しかし、メッセージが到着すると、Receivedヘッダーは

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

with ESMPTSAを見たいと思っていましたが、証明書の検証に失敗したため、「S」が抑制されたと思います。

証明書のどこに問題があるのか​​、また検証の失敗をどのように回避できるのか。私の推測では、mail.example.com.netsolmail.netの複数のサブドメインは証明書の名前と十分に一致していません。しかし、どのようにしてそれを確認し、どのようにして苦情を回避できますか?より正確には、Receivedヘッダーを取得してESMTPSAとの安全な接続を確認する方法を教えてください。

編集:私はsendmail.mcを編集して追加しました

define(`confLOG_LEVEL', `15')dnl

メールログに詳細が表示されるようになりました。 verify=FAIL行の直後に次のように表示されます。

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

これは、検証エラーの少なくとも1つの原因は、sendmailが実行されているローカルマシンの証明書を見つけられないことであると考えていますか?私は送信メールをnetsolサーバーに中継するだけで、インターネットからの受信メールは決して受け入れないため、このサーバーの証明書が必要だとは思いませんでした。必要な場合は、どこにどのようにインストールしますか?そして、それは私のウェブサーバーに使用するのと同じ証明書にすることができますか、それとも別のものが必要ですか?自己署名証明書の使用は、Receivedヘッダーにwith ESMTPSAを示すのに十分でしょうか、それともCAからの商用証明書である必要がありますか?

編集#2:

@MadHatterによる回答を受け入れます。キーはconfCACERTを定義していました。私は恥ずかしいですが、私の唯一の言い訳は、古い老年期の脳がm4ソースをグロッキー化しないことです。 Amazon Linuxのデフォルトのsendmail.mcファイルにはすでに

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

その中に、ファイルが存在することを確認しました。 しかし実際にはこれらの行の先頭にある卑劣な小さなdnlに気付かなかった!私はそれが何を意味するかを知っていますが、m4ソースをめったに見ないので、dnl- ed行が#でコメントとしてマークされた直後だったので、私の脳はそれらを-として登録しましたnotコメントアウトされています!

私は実際に、Firefoxから証明書をダウンロードし、ウェブサイトで使用するDigicert証明書をsendmailに向ける一連の旋回を行いましたが、このホストは、送信、受信、電子メール送信のみを行うため、他に必要なものはありません。私はdnlconfSERVER_CERTconfSERVER_KEYの定義に戻しましたが、すべて順調で、maillogverify=OKverifymsg=okを示しています適切なSTARTTLS=client行。

ただし、TLSに関する診断がなかったとしても、netsolへの接続のReceivedヘッダーにはwith ESMTPAが表示され、with ESMTPSAは表示されません。まあ、@ MadHatterもその上にドープを持っていました。申し訳ありませんが、これはとても長く、野生のガチョウの追跡でした。しかし、私は多くのことを学びました、そして私は私の構成を改善しました(重要でない方法で)。これを乗り切るのに十分な必死の誰かが何かを学ぶかもしれないと思います。

6
sootsnoot

これは非常に多くの点で問題であり、私はそのように受け止めます。私は数十年にわたってsendmailを私の優先MTAとして使用してきましたが、その専門家であるとは言えません(つまり、私はEric Allmanではありません)。

verifymsg=unable to get local issuer certificate

これは、検証エラーの少なくとも1つの原因は、sendmailが実行されているローカルマシンの証明書を見つけられないことであると考えていますか?

これは MTAのメッセージではなく、OpenSSLメッセージ のようであり、私が理解しているように、確認アプリが発行者の証明書のローカルコピーを取得できないことを意味します。つまり、sendmailは、リモートサーバーの証明書を発行した人のルート証明書を含む証明書バンドルにアクセスできません。 Linuxは一元化された証明書管理サービスを提供していないため、各アプリは独自のバンドルをロールバックする必要があることに注意してください。私の場合、sendmailに次のm4コードを含む証明書バンドルへのアクセスを許可しました。

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

ESMPTSAで確認することを望んでいましたが、証明書の検証の失敗により「S」が抑制されたと思います。

推測は間違っていると思います。 RFC2821と2822は、Received:ヘッダーの形式についてかなり柔軟であり、ESMTPAESMPTSA(sic)を区別するものは何も見つかりません。私のヘッダーはすべて次のような行を示しています:

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

レシーバーのMTAがESMTPAで何を意味するかを理解するには、そのMTAが何であるかを調べ、ドキュメントを読む必要があります。あなたがそれをするまで、私はあなたがその手紙の集まりに多くを読むことができるとは思いません。

Starttlsを回避できますかverify=failサーバーのホスト名が証明書と一致しない場合

できないと思います。 SSLの背後にある根本的な考えは、(a)接続するホスト名(b)信頼できるサードパーティ(c)が署名した証明書を、CNまたはSANフィールドこれらのプロパティのいずれかが満たされない場合、SSLはピアのIDを検証できないことを通知するのは当然です。

読みすぎないようにしてください。自己署名証明書は、依然として電子メール処理で非常に一般的です。私が最後に送受信した1919のTLSで保護された電子メールのうち、1764には、なんらかの理由でIDを検証できなかったピアが含まれていました。あなた自身が自己署名証明書で実行しています。したがって、ほとんどの人がSMTP TLSピアの信頼チェーンを気にしないことを嬉しく思うはずです。

5
MadHatter