修復 starttls verify=fail, verifymsg=unable to get local issuer certificate
在 EC2 實例上執行 Amazon Linux，使用
sendmail. 我有一個網路解決方案的電子郵件帳戶，並在我的配置中將該帳戶用作SMART_HOST中繼。sendmail除了一個小細節外，它運作良好。在我的
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) (info@example.com@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我認為這意味著驗證失敗的至少一個原因是 sendmail 找不到執行它的本地電腦的證書？由於我只是將傳出的郵件中繼到 netsol 伺服器，從不接受來自 Internet 的傳入郵件，我認為我不需要為該伺服器提供證書。如果我需要一個，我在哪裡/如何安裝它？它可以是我用於我的網路伺服器的同一個證書，還是我需要一個不同的證書？使用自簽名證書是否足以讓
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 行之後#，我的大腦將它們記錄為沒有被註釋掉！實際上，我經歷了一系列從 Firefox 下載證書並將 sendmail 指向我用於我們網站的 Digicert 證書的過程，但由於該主機只發送，從不接收電子郵件，因此沒有其他必要。我把 and 的定義放回去了，
dnl一切都很好，在適當的行上顯示了and 。confSERVER_CERT``confSERVER_KEY``maillog``verify=OK``verifymsg=ok``STARTTLS=client但即使沒有關於 TLS 的診斷，
Received與 netsol 連接的標頭仍然顯示with ESMTPA而不是with ESMTPSA. 哦，好吧，@MadHatter 對此也有興趣。對不起，這太長了，有點像一場瘋狂的追逐。但是我學到了很多東西，並且我確實改進了我的配置（以一種非重要的方式）。我希望那些絕望地經歷過這一切的人也能學到一些東西。
這在很大程度上是一個問題，我會這樣認為。幾十年來，我一直將
sendmail其用作我的首選 MTA，但我不能聲稱自己是這方面的專家（即，我不是 Eric Allman）。
verifymsg=unable to get local issuer certificate我認為這意味著驗證失敗的至少一個原因是 sendmail 找不到執行它的本地電腦的證書？
這似乎是一條 OpenSSL 消息，而不是 MTA 消息，據我了解，這意味著驗證應用程序無法獲取頒發者證書的本地副本。換句話說，sendmail 無權訪問包含頒發遠端伺服器證書的人的根證書的證書包。請記住，Linux 不提供集中式證書管理服務，因此每個應用程序都必須推出自己的捆綁包。就我而言，我使用以下 m4 程式碼授予 sendmail 對證書包的訪問權限：
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.with.intermediate.crt')dnl我希望看到 ESMPTSA，但我猜證書驗證失敗導致“S”被壓制。
我認為這個猜測是錯誤的。RFC2821 和 2822 對 Received: 標頭的格式非常靈活，我在其中找不到任何區分
ESMTPA和ESMPTSA（原文如此）的內容。我的標題都顯示如下行：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要了解接收者的 MTA 的含義
ESMTPA，您必須找出 MTA 是什麼，並閱讀文件。在你做到這一點之前，我認為你不能對那套信件讀得太多。
verify=fail當伺服器主機名與證書不匹配時，我可以避免 starttls我不認為你可以。SSL 背後的基本思想是**(a)您連接的主機名(b)提供由受信任的第三方(c)**在 CN 或 SAN 欄位中使用該主機名簽名的證書。如果不滿足這些屬性中的任何一個，則 SSL 指出它無法驗證對等方的身份是正確的。
你不應該讀太多。自簽名證書在電子郵件處理中仍然很常見。在我最近發送/接收的 1919 封 TLS 安全電子郵件中，有 1764 封涉及到一個由於某種原因無法驗證身份的對等方，而只有 155 封可以。您自己正在使用自簽名證書執行；因此，您應該很高興大多數人並不真正關心 SMTP TLS 對等點上的信任鏈！