在向Google帐户发送电子邮件之前，我的脚本会查找Google电子邮件服务器的MX记录。结果是：
gmail-smtp-in.l.google.com
alt1.gmail-smtp-in.l.google.com
alt2.gmail-smtp-in.l.google.com
alt3.gmail-smtp-in.l.google.com
alt4.gmail-smtp-in.l.google.com
然后我成功连接到gmail-smtp-in.l.google.com并在EHLO之后我开始STARTTLS请求切换到SSL。但是，我设置脚本以检查并确保我连接的证书match the domain中列出的主机。
stream_context_set_option($fh, 'ssl', 'CN_match', 'gmail-smtp-in.l.google.com`);
但是，这是事情的发生。我收到以下错误：
stream_socket_enable_crypto(): Peer certificate CN='mx.google.com' did not match expected CN='gmail-smtp-in.l.google.com'
我检查了nslookup mx.google.com所在的位置，发现它不存在。
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find mx.google.com: NXDOMAIN
为什么SSL证书与使用它的域不匹配？我错过了什么吗？
以下是我的脚本从他们那里收到的证书。
Array
(
[name] => /C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
[subject] => Array
(
[C] => US
[ST] => California
[L] => Mountain View
[O] => Google Inc
[CN] => mx.google.com
)
[hash] => fbf7dda6
[issuer] => Array
(
[C] => US
[O] => Google Inc
[CN] => Google Internet Authority
)
[version] => 2
[serialNumber] => 280762463620984597407910
[validFrom] => 120912115656Z
[validTo] => 130607194327Z
[validFrom_time_t] => 1347451016
[validTo_time_t] => 1370634207
[purposes] => Array
(
[1] => Array
(
[0] => 1
[1] =>
[2] => sslclient
)
[2] => Array
(
[0] => 1
[1] =>
[2] => sslserver
)
[3] => Array
(
[0] => 1
[1] =>
[2] => nssslserver
)
[4] => Array
(
[0] =>
[1] =>
[2] => smimesign
)
[5] => Array
(
[0] =>
[1] =>
[2] => smimeencrypt
)
[6] => Array
(
[0] => 1
[1] =>
[2] => crlsign
)
[7] => Array
(
[0] => 1
[1] => 1
[2] => any
)
[8] => Array
(
[0] => 1
[1] =>
[2] => ocsphelper
)
)
[extensions] => Array
(
[extendedKeyUsage] => TLS Web Server Authentication, TLS Web Client Authentication
[subjectKeyIdentifier] => 69:B3:67:5C:04:7F:16:EF:C1:85:FB:E8:2D:E4:FC:21:E9:7D:93:AF
[authorityKeyIdentifier] => keyid:BF:C0:30:EB:F5:43:11:3E:67:BA:9E:91:FB:FC:6A:DA:E3:6B:12:24
[crlDistributionPoints] => URI:http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crl
[authorityInfoAccess] => CA Issuers - URI:http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crt
[basicConstraints] => CA:FALSE
[subjectAltName] => DNS:mx.google.com
)
)
答案 0 :(得分：4)
这有两个可能的原因。
首先，传统上对SMTP主机名匹配的定义非常模糊。您可以在RFC 6125（最近关于主机名验证的最佳实践的RFC，尚未广泛实施）中查看有关此内容的历史记录。 RFC 3207（基于传输层安全的安全SMTP）没有详细说明主机名在证书中的位置。 RFC 4954（用于身份验证的SMTP服务扩展）提供了有关主题备用名称的更多详细信息和说明，但它位于SASL的上下文中。不幸的是，模糊或模糊的主机名匹配规范通常是没有正确尝试匹配主机名的原因。
其次，Mail Transfer Agents (MTA)之间很少使用SSL / TLS。您通过获取MX DNS记录并尝试直接向其发送电子邮件所做的工作通常是通过我的MTA完成的，而不是Mail Submission Agent。
SMTP的SSL / TLS的典型用法是在邮件用户代理（电子邮件客户端）和邮件提交代理（ISP的电子邮件服务器，您必须在其中进行身份验证）之间。
MTA之间的SSL / TLS很难设置，因为不是每个服务器都支持它，并且很难知道哪些MTA会支持它。有些人提倡“乐观TLS”支持，您可以尝试查看您正在通话的服务器是否支持TLS，如果不支持则返回普通SMTP。不幸的是，这样做几乎没有什么好处，因为一旦你愿意降级，你很明显很容易受到MITM攻击。
此外，您获得的MX条目本身可能已被破坏（至少没有DNSSEC）。
总的来说，这实际上使得很难依赖MUA / MSA连接之外的任何形式的传输安全性来发送电子邮件。这可能解释了为什么很少强调为SSL / TLS正确配置MX服务器。