标签：情况下 检查 checktls 两种方法 star 本地服务器 方法 无法运行 解密
默认情况下，SMTP流量是不被加密的，这就导致在公网上进行邮件沟通就像是在广播一样，任何人拦截到该邮件都可以轻而易举的读取其内容。但是现实场景中有许多敏感信息是通过邮件来进行发送的，所以其中一种保护邮件安全的方法就是使用传输层安全协议（Transport Layer Security）来提供SMTP流量在传输中的加密，受TLS保护的SMTP流量可以让拦截/窃听者无法读取到SMTP流量的内容，但是它只提供传输过程中的保护，对于已经到达目标服务器，或者是在发件方本地服务器的邮件则没法提供保护。
有两种方法可以让Exchange使用TLS，第一种也是最简单的一种，叫做机会型TLS，意思是Exchange一有机会（对端服务器主动使用TLS）就会启用TLS，默认情况下机会型TLS功能会一直开着，而且会使用Exchange安装时候生成的自签名证书（如果你没指定证书的话）。Exchange 2013 还对所有远程连接主动尝试实现 TLS。
另一种是相互TLS，尽管TLS是一种传输层的加密，但是如果每台服务器通过验证另一台服务器提供的证书来验证这台服务器的身份的话，TLS也可以作为一种验证方法。Lync就基于相互TLS，当然Exchange也可以配置成这样。
机会型TLS不进行证书的有效性检查，有个自签名的证书它就认为是OK的，甚至是过期的证书也行。而相互TLS的应用要求则比较严格，因为Exchange会进行完整的证书检查，包括证书的时效性，查看发行者的证书吊销列表等等。
值得一提的是，Exchange 2013采用的是TLS V1.2，也是最新的TLS，其他的邮件服务器可能无法支持该版本，所以TLS的协商过程中，双方会声明自己的支持版本。在Microsoft Exchange上提供和接受的TLS版本、TLS会话中使用的加密算法，这些都是受Windows 安全通道子系统控制(即Schannel)，关于如何查看或者修改Windows使用了那种加密算法，可以参考这篇Technet文章：https://technet.microsoft.com/en-us/library/cc784149(v=ws.10).aspx 虽然这篇文章标明for windows 2003，但是在现在的版本里依旧适用。
基本TLS
TLS实际上在所有的MBX的传输服务之间已经被启用了（Technet描述是强制启用的）；向启用TLS的服务器发出SMTP EHLO得到的回应里会包含一条STARTTLS命令，发送方收到这个响应后，就知道可以开始进行TLS协商，这是一个非常简单的测试远程服务器是否接受TLS流量的方法，即telnet连接到对方的smtp侦听端口，发送一个EHLO，看看对方会不会返回STARTTLS。
配置发送连接器/接收连接器使用TLS非常简单，使用Set-SendConnector 或者 Set-ReceiveConnector 带上一个-RequireTls $True就可以打开该连接器的TLS选项，还有一个参数是-TlsCertificateName ，即为这个连接器的TLS指定一张作用证书，如果你不指定这个选项的话，默认Exchange采用你之前分配给SMTP服务的证书来进行TLS验证。如果为SMTP应用了多张证书，那么Exchange会进行一个最优证书的选择，首先会选择一张使用者备用名称里有本服务器FQDN的证书，如果没选出来，有多张证书符合这个条件，那么就按照证书的有效日期排序，选择最近的一张使用。
如果需要某个发送连接器避免使用TLS，那么只需要Set-SendConnector带上一个-IgnoreSTARTTLS参数，打开这个选项后，该发送连接器不会宣告自己支持TLS，也不会发送STARTTLS给对方服务器。如果需要某个接收连接器不宣传或是不接受TLS的话，就用Set-ReceiveConnector后面带上SuppressXAnonymousTls的参数。注意如果你针对默认的接收连接器开启了这个选项，会导致组织内的邮件流中断，因为Exchange 2013设计在组织内部是必须使用TLS的。
还可以指定连接器上应用的TLS的保护等级，默认的TLS保护等级为只加密传输（EncryptionOnly）。可以通过TlsAuthLevel参数来控制，一共是一下三个等级：
EncryptionOnly：默认的，意思是连接器应该使用TLS加密传输，而不试图验证证书。
CertificateValidation：证书验证，包括传输加密和基本证书检查。双方都互相拥有对方的证书，并且会验证证书链和有效日期、吊销列表等等。
DomainValidation：域验证，最安全的等级。包括传输加密和证书检查，并且验证证书里包含的FQDN是否符合Set-SendConnector中带的TlsDomain参数（没有使用这个参数的话，则会去匹配发送者的SMTP域。）
比方说你需要确认在与微软Outlook.com进行邮件交换时使用域验证的TLS：
如果是接收连接器的话，参数就不是-TlsAuthLevel，而是-TlsDomainCapabilities。
使用域安全性
域安全性是使相互 TLS 成为有用并且容易管理的技术的功能集，例如证书管理、连接器功能和 Outlook 客户端行为。
一台被配置使用TLS的服务器有两种方法可以应用相互TLS验证，默认是使用X.509证书验证算法来验证远端证书的有效性。另一种就是Exchange会直接去检查AD或者ADLDS里（边缘角色与邮箱角色之间）是否确实存在这台服务器的证书，这种方法也被叫做（Direct Trust）直接信任，如果存在该证书，则证书有效。这个过程中，AD被作为是受信任的证书存储。
Exchange在内部自动使用Direct Trust来支持X-ANONYMOUSTLS和相关联的连接，然而域安全性无法运行在前端传输服务上，所以通过 Exchange 2013 客户端访问服务器路由出站电子邮件时，不支持域安全性。
如何查看一个站点是否支持TLS
使用CheckTLS.com这个网站可以很方便的查询某个站点是否支持TLS，如下图：
WAN优化设备和TLS
目前在复杂网络环境下，存在一种设备叫WAN优化控制器，即侦听和优化（压缩）一些跨广域网的站到站流量，这些设备大多数都支持MAPI和SMTP流量，但是如果碰上了TLS加密的流量，他们就得先解密才能进行流量优化。Technet上有这样一篇文章告诉咱们如何将Exchange 配置为支持WAN优化控制器，如果在真实环境里碰到了，可以参考一下：https://technet.microsoft.com/zh-CN/library/ee633456%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396
TLS咱们就聊到这里。下一章我们就讲讲队列……最近Exchange 2016发布，再加上手头有两个项目在同时进行，更新速度减缓了不少啊……
标签：情况下 检查 checktls 两种方法 star 本地服务器 方法 无法运行 解密
原文地址：https://www.cnblogs.com/reachos/p/9674198.html
