☰

TLS：读取文件时出错

tag-icon • tag-icon exim gnutls
TLS：读取文件时出错

我正在使用 Debian 8 设置新服务器。Exim4 已预先安装，我正在尝试让 TLS 正常运行。

我已将 snakeoil 密钥和证书复制到 /etc/exim4 文件夹中，并设置了正确的权限和所有权：

-r--r-----  1 root Debian-exim  1704 Sep 28 20:01 ssl-cert-snakeoil.key
-r--r-----  1 root Debian-exim  1257 Sep 28 20:01 ssl-cert-snakeoil.pem

我已经在 Exim4 中配置了这些

然后，我尝试从第二台服务器连接到 SMTP 并启动 TLS，如下所示：

root@second: ~# telnet mynewserver.net.au 25
Trying xxx.xxx.xxx.xxx...
Connected to mynewserver.net.au.
Escape character is '^]'.
220 mynewserver.net.au ESMTP Exim 4.84_2 Wed, 28 Sep 2016 20:12:12 +1000
ehlo second
250-mynewserver.net.au Hello second [xxx.xxx.xxx.xxx]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-STARTTLS
250 HELP
STARTTLS
454 TLS currently unavailable

来自 mynewserver 的调试日志如下所示：

  665 SMTP>> 250-mynewserver.net.au Hello second [xxx.xxx.xxx.xxx]
  665 250-SIZE 52428800
  665 250-8BITMIME
  665 250-PIPELINING
  665 250-STARTTLS
  665 250 HELP
  665 SMTP<< STARTTLS
  665 initialising GnuTLS as a server
  665 GnuTLS global init required.
  665 initialising GnuTLS server session
  665 Expanding various TLS configuration options for session credentials.
  665 certificate file = '/etc/exim4/ssl-cert-snakeoil.pem'
  665 key file = '/etc/exim4/ssl-cert-snakeoil.key'
  665 LOG: MAIN
  665   TLS error on connection from second (second) [xxx.xxx.xxx.xxx] (cert/key setup: cert='/etc/exim4/ssl-cert-snakeoil.pem' key='/etc/exim4/ssl-cert-snakeoil.key'): Error while reading file.
  665 SMTP>> 454 TLS currently unavailable

我已经检查了证书，密钥和证书匹配，如下面的测试中模数相同：

root@mynewserver: exim4# openssl x509 -noout -modulus -in ssl-cert-snakeoil.pem | openssl md5
(stdin)= 4d56fe03bcdc3103788344d0d7a2eb8d
root@mynewserver: exim4# openssl x509 -noopenssl rsa -noout -modulus -in ssl-cert-snakeoil.key | openssl md5
(stdin)= 4d56fe03bcdc3103788344d0d7a2eb8d

我还配置了新服务器以允许 Debian-exim 登录，登录后能够毫无问题地查看证书文件。

我的所有研究都发现证书存在问题，包括证书不可读、内容正确、匹配、权限正确，或者在 exim4 配置中指定正确。我已经涵盖了所有这些方面，但仍然失败。

您知道我下一步应该检查哪里吗？

答案1

它的字面意思是 - 它确实无法读取 [证书] 文件。我尝试在配置文件中添加各种条目，例如：

tls_certificate=xxx.crt
tls_privatekey=xxx.key

和

MAIN_TLS_CERTIFICATE=xxx.crt
MAIN_TLS_PRIVATEKEY=xxx.key

但这些似乎都不起作用。默认情况下，exim4 会查找 CONFIGDIR/exim.crt 和 CONFIGDIR/exim.key（CONFIGDIR 适用于我的 /etc/exim4）

因此，将您的证书和密钥复制到这两个文件名中。删除您之前添加的所有配置条目，以便 exim4 可以毫无干扰地查找默认条目。确保您的证书和密钥可被 exim4 读取：

  1. 将组设置为 Debian-exim (chrgrp Debian-exim exim.*)
  2. 设置组读取权限（chmod g+r exim.*）
  3. 重新启动 exim4
  4. 然后我使用 checktls.com 来确保 TLS 和证书正常工作。

高血压

答案2

我认为一般规则是，任何守护进程在启动时运行的用户都将需要同一个用户来访问该文件 - 包括其父目录：

在 Debian 上：

Debian-exim 28104  0.0  0.1 109736  2752  Ss   Jan24   0:09 /usr/sbin/exim4 -bd -q30m

在 /etc/letsencrypt/ 文件和目录中将组设置为 Debian-exim

chgrp Debian-exim /etc/letsencrypt/ -R

我以为是证书格式或文件损坏，但设置群组所有者解决了这个问题

答案3

升级 Let's Encrypt 证书后，我遇到了同样的问题。据记录，Thunderbird 抱怨

无法使用 STARTTLS 与外发服务器 (SMTP) smtp.example.org 建立安全链接，因为它未宣传此功能。请关闭该服务器的 STARTTLS 或联系您的服务提供商。

事实证明，新证书私钥没有足够的读取权限。虽然在chmod私钥a+r及其a+x目录（无需exim4重启）后它可以工作，但正如 user56452 所强调的那样，这会导致私钥不可读的安全问题。我测试了user56452 建议的解决方案并取得成功。

相关内容