TFS 2017 |TFS 2015 |TFS 2013
背景
对于许多版本，Azure DevOps Server 的默认网站设置（以前命名为 Team Foundation Server （TFS）已为：
- 端口 8080 上 Azure DevOps Server 网站的单个 HTTP 绑定，未指定主机名或 IP 地址。
- 格式为
http://machine-name:8080/tfs的公共 URL（以前称为通知 URL）。
这些设置的主要优点是，它们在大多数情况下配置非常简单，对最终用户来说也很方便。 特别是：
- 使用 HTTP 而不是 HTTPS 可避免获取和安装证书。
- 使用 8080 而不是 80 可避免与同一计算机上的其他站点发生潜在冲突。
- 使用“tfs”作为站点的虚拟目录，可以更轻松地在同一服务器上的同一端口上托管 Azure DevOps Server 和其他网站。
- 使用计算机名称而不是完全限定域名（FQDN）在公共 URL 中，可节省大量键入操作。
- 在未指定的绑定中保留主机名可以灵活地进行连接 - 当用户尝试连接到其服务器时，计算机名称、FQDN 或 IP 地址都将正常工作。
但是，默认情况下，这些设置并不安全。 特别是，如果不使用 HTTPS 绑定，除非使用其他解决方案（如 IPSec），否则传输中不会加密与 Azure DevOps Server 之间的通信。 因此，它们可能容易受到恶意参与者监视，甚至可能修改通信的内容。 当 Azure DevOps Server 部署在企业防火墙后面的 Intranet 上时，这些问题在一定程度上得到缓解，因为绝大多数 Azure DevOps Server 实例都是这样。 但是，即使在这些情况下，与 Azure DevOps Server 之间传输的数据也包括源代码、工作项数据和其他信息，而这些信息通常可以通过增加安全措施来获益。
此外，在 TFS 2017 中存在新的身份验证场景（构建/发布代理服务帐户身份验证、个人访问令牌），这些场景会通过网络传输承载令牌。 如果这些令牌由恶意用户获取，则可以使用这些令牌模拟他们所属的用户。
鉴于这一切，我们决定是时候更强烈地倡导在 Azure DevOps Server 部署中使用 HTTPS 绑定了。
设置组
TFS 2017 在所有服务器配置方案中都提供了网站设置配置选项。 提供了多个设置组，这些组捆绑了网站绑定、虚拟目录和公共 URL 的组合，我们建议和相信这些组合将最常使用。 对于这些设置组都不适用的情况，可以使用“编辑网站设置”对话框完全自定义设置。
默认设置组包括以前版本的 Azure DevOps Server 中使用的相同设置。 出于上述所有原因，这些设置仍然是新的 Azure DevOps Server 部署的默认设置。 对于现有部署，我们将尝试保留现有设置，这通常会导致选择“默认设置”组。
HTTPS 和 HTTP（带有重定向）设置组预配两个绑定：
- 在端口 443 上的一个 HTTPS 绑定，其中主机名使用了计算机的完全限定域名 (FQDN)。
- 端口 80 上的一个 HTTP 绑定，再次将计算机的 FQDN 用作主机名。
端口 80 上的 HTTP 绑定仅作为最终用户的便利添加 - 已配置重定向，以便所有流量最终都使用端口 443 上的 HTTPS 绑定。 此设置组的公共 URL 格式为 https://fully-qualified-domain-name. 默认情况下，此设置组将预配新的自签名证书，并将其用于 HTTPS 绑定。 我们通常不建议对生产 TFS 部署使用自签名证书。 有关何时使用自签名证书以及可用的其他选项的详细信息，请参阅下面的证书选项。
HTTPS 仅设置组在端口 443 上预配单个 HTTPS 绑定，并将计算机的 FQDN 用作主机名。 同样，此设置组的公共 URL 的格式为 https://fully-qualified-domain-name，默认情况下会生成自签名证书。
仅 HTTP 设置组在端口 80 上预配单个 HTTP 绑定，且未指定主机名。 此设置组的公共 URL 的格式为 http://machine-name.
使用 HTTPS 和 HTTP（通过重定向）设置组时，不建议使用 HTTP 公共 URL。 大多数新式浏览器默认会考虑混合 HTTP 和 HTTPS 内容不安全，并且可能会显示空页面。 尽管通常可以替代默认浏览器设置并允许不安全的内容，但这将导致类似于使用过期 SSL 证书浏览站点的体验。
证书选项
使用 HTTPS 绑定和 SSL/TLS 加密部署网站与公钥基础结构（PKI）更广泛的主题密切相关，这是一个丰富而有趣的主题，其中已存在各种文档。 我们不会尝试涵盖此处的所有复杂性，而是重点介绍为 Azure DevOps Server 部署配置 HTTPS 绑定的高级选项。 许多组织都有有关部署证书的特定策略，因此决定用于 Azure DevOps Server 部署的证书的第一步通常是与组织级信息技术组交谈。
选项包括：
- 允许 TFS 配置向导生成自签名证书供部署使用。
- 从内部证书颁发机构获取证书。
- 从外部证书颁发机构获取证书。
自签名证书
自签名证书对于 Azure DevOps Server 的试用部署非常有用，因为它们易于预配和使用。 它们不太适用于 Azure DevOps Server 的生产部署，不建议将其用于公开到公共 Internet 的 Azure DevOps Server 部署。 通常，自签名证书容易受到中间人攻击。 它们还会导致用户出现问题，因为它们将导致证书警告和错误，直到其根证书安装在每台客户端计算机上。 例如，Edge 浏览器将显示以下错误。
当 TFS 配置向导为部署生成自签名证书时，它将创建两个证书：一个放在服务器的受信任的根证书颁发机构存储区，另一个由第一个证书签名，放在服务器的个人存储区，并由 Azure DevOps Server 使用。 以这种方式进行设置有助于缓解中间人攻击的可能性，并启用 HTTPS 绑定中使用的证书轮换，而无需向所有客户端分发新证书，以避免证书错误，如上面所示的证书错误。
若要避免这些证书警告和错误，可以导出根证书并将其安装在客户端计算机上。 可通过多种方式来实现此目的，包括：
- 使用证书 MMC 管理单元在服务器上手动 导出证书 ，然后在每个客户端上导入该证书。
- 使用 Windows 8/Windows Server 2012 及更高版本中提供的 Export-Certificate powershell cmdlet 导出证书。 然后，可以在每个客户端上使用Import-Certificate来导入它。
- 使用 组策略 自动分发到客户端。
内部和外部证书颁发机构
许多大型组织都有自己的公钥基础结构，并且能够从自己的证书颁发机构颁发证书。 通常情况下，在这种情况下，这些颁发机构的受信任根证书已分发到客户端计算机，从而避免需要为 Azure DevOps Server 分发其他证书。 如果组织具有自己的公钥基础结构，则对于 Azure DevOps Server 部署来说，这是一个不错的选择。
当其他选项不适用或不可用时，可能会从外部证书颁发机构（CA）获取证书（通常成本）。 有关此过程的说明（从创建 证书签名请求开始）可在大多数 CA 网站上找到。 一些重要说明：
- 确保证书请求中提供的公用名与公共 URL 中所需的主机名匹配，例如，tfs.contoso.com。
- 在加密服务提供程序属性页面，我们建议选择Microsoft RSA SChannel加密提供程序，并将密钥长度设置为至少2048位或更大。
更改公共 URL
还应注意，升级现有 Azure DevOps Server 部署时，更改公共 URL 将影响最终用户。 尽管我们仍建议从 HTTP 转换为 HTTPS 绑定，但需要重新建立 Visual Studio 客户端连接，旧书签将不再正确解析，依此类推。 因此，与 Azure DevOps Server 部署的用户协调这种更改非常重要，以避免重大中断。