通配符ssl证书怎么使用（通配符ssl证书使用方法）

ssl/tls是一种看似简单的技术。它易于部署，正常部署后就可以运行了。但想要部署地安全可靠却并非易事。这就使得系统管理员和开发者不得不花费额外时间和精力了解ssl/tls相关技术，以便能配置一个高安全的服务器或应用。

为了让系统管理员轻松部署安全站点或应用，本篇将讲解ssl/tls部署最佳实践。

一、私钥和证书

在ssl/tls中，所有安全都始于服务器的密码标识。因此需要一个强大的私钥来防止攻击。另外，拥有一张有效且强大的证书也是至关重要的，它能授予私钥代表特定主机名的权利。没有这两个基本构建块，任何东西都无法得到安全保障。

1.1使用2048位私钥

对于大多数网站来说，2048位rsa密钥足以保障其安全性了。rsa加密算法的普遍应用使得这种类型的密钥成为默认的安全选择。如果是2048位，这类密钥提供了相当于112位的安全性。如果您想要比这更高的安全性，如128位的安全性，您需要3072位的rsa密钥，但是rsa加密算法的扩展性不太好，3072位的rsa密钥将会影响性能。ecdsa密钥提供了一种替代方案，可以给予更高的安全性和更好的性能。ecdsa密钥为256位，提供128位的安全性。少数老旧的客户端不支持ecdsa，但现代客户端能支持。如果您不介意管理此类设置的开销，则可以同时部署支持rsa和ecdsa加密算法的ssl证书。

1.2保护私钥

私钥是非常重要的资产之一，需限制访问私钥人数，同时建议您采取以下策略保护私钥：

• 在可信的计算机上生成私钥，建议拒绝ca为您生成私钥。
• 从一开始就对密钥进行安全保护，防止密钥存储在备份系统中时遭到破坏。
• 证书被破坏后，撤销旧证书并生成新的私钥。
• 每年更新ssl证书。如果您采用自动化管理证书，更新频率应更高。有效期较短的证书在实践中更安全。
• 保持证书的公钥与私钥相匹配，否则每当您获得新证书时，还应该生成新的私钥。

1.3确保覆盖所有域名

确保您的ssl证书覆盖您希望用于所有站点域名，否则无效证书警告会降低用户对该站点的信任度。经验法则是，安全的web服务器应该具备这样一个证书，该证书对于指向它的每个dns名称都有效。

通配符证书有其用途而且能满足更广泛的需求，但在跨团队或部门情况下，使用通配符证书时容易将密钥暴露给很多人。为控制访问私钥人数防止私钥被滥用，这种情况下请避免使用通配符证书。

请确保将所有必要的域名添加到使用者可选名称(san)，因为所有最新的浏览器都不会通过检查通用名称进行验证。

1.4从可信ca获取证书

选择认真对待其证书业务和安全性的可信证书颁发机构 ，即ca。选择 ca 时，请参考以下标准：

• 对待安全的态度。所有 ca 都会接受定期审计，但有些ca比其他ca更重视安全。找出在这方面哪个ca做的更好并不容易，但您可以做的一项是检查他们的安全历史记录，查看ca面对漏洞的反应是怎样，是否从错误中吸取了教训。
• 提供的服务。您选择的ca应支持证书吊销列表 (crl) 和在线证书状态协议 (ocsp) 吊销方法，并具有稳定的网络可用性和高性能。许多站点喜欢使用域名验证型dv证书，但您还应该考站点是否需要扩展验证型ev证书。但无论哪种情况，您都应该选择公钥算法。目前大多数网站都使用rsa算法，但ecdsa可能会因为其性能优势在未来变得重要。
• 证书管理。如果您需要大量ssl证书并在复杂的环境中运行，请选择一个可以为您提供良好的管理工具的ca。

注意：为获得最佳效果，请提前至少一周获取证书，以便部署并正常运行。这样做有助于避免因计算机时间不准确而导致出现证书不安全警告。另外，由于ca需要额外的时间才能有效的将新证书发送给ocsp响应，所以最好先提前获取证书避免证书撤销检查的失败。因此，千万不要等到您的证书到期时才替换它们。

1.5使用强签名算法

证书安全性取决于私钥的强度和签名中使用的散列函数强度。如今sha1散列函数的证书被普遍认为是不安全的，所以最好安装使用sha256散列函数的证书。

1.6使用dns caa

dns caa是一项防止https证书错误颁发的安全措施，caa标准可以允许域名所有者限制能为其域名颁发证书的ca。如果没有caa记录，那么任何人都能为该域名生成csr并获取任何ca签发的证书。使用dns caa记录，可以减少欺诈证书的出现，从而使站点更加安全。如果ca启用自动签发证书的流程，那么就应该检查dns caa记录，这样可以减少错误颁发证书的风险。

建议通过为您的证书添加caa记录将ca列入白名单。添加您信任的ca为您颁发证书。

二、配置

正确的ssl服务器配置可以让您的网站身份能正常向用户展示以增强信任，并能使用安全的加密原语以缓解所有已知的缺陷。

2.1使用完整的证书链

在部署ssl证书时，仅靠服务器证书是不够的，这就需要两个或多个证书来建立完整的信任链。如果您部署了一个有效证书，但却缺少必要的中间证书，那么就会出现常见的配置问题。为避免这种情况的发生，您需要按相应顺序部署ca提供给您的所有证书。

2.2使用安全的协议

ssl/tls 系列中有六种协议：ssl 2.0、ssl 3.0、tls1.0、tls 1.1、tls 1.2 和 tls 1.3：

• ssl 2.0不安全，不能使用。
• ssl 3.0与http一起使用时不安全。它也已过时，建议不使用。
• tls 1.0和tls 1.1已于2020年1月弃用。
• tls 1.2 和tls 1.3都没有已知的安全问题。tls 1.2或tls 1.3是目前主要使用的安全协议，因为这些版本提供现代认证加密（也称为aead）。如果您的服务器不支持 tls 1.2或tls 1.3，那您的网站可能缺乏安全性。
• tls 1.3相对来说更加安全，性能更强大。

2.3使用安全的密码套件

要确保安全通信，必须首先确定您是直接与所需方通信（而不是通过窃听的其他人）并安全地交换数据。在 ssl 和 tls 中，密码套件定义了安全通信的发生方式。 它们由不同的构建块组成，其理念是通过多样性实现安全。如果发现其中一个构建块薄弱或不安全，您应该能够切换到另一个构建块。

目前主要依赖提供强身份验证和密钥交换、前向保密和至少128位加密的aead套件。可能仍然有支持其他一些较弱的套件，前提是它们仅与不支持任何更好的旧客户端协商。下面是一些过时的密码原语，建议不要使用：

• adh套件不提供身份验证。
• null密码套件不提供加密。
• 导出密码套件在连接中协商时不安全，但也可以针对更喜欢更强大的套件（freak攻击）的服务器使用。
• 弱密码（112 位或更少位数）的套件很容易被破解，是不安全的。
• rc4不安全。
• 64 位分组密码（3des / des / rc2 / idea）很弱。
• rsa密钥交换密码套件较弱。

建议使用aead或pfs密码套件：

• aead密码套件-包括chacha20_poly1305, gcm and ccm。
• pfs密码套件-包括ecdhe_rsa, ecdhe_ecdsa, dhe_rsa, dhe_dss, cecpq1和所有的tls 1.3密码。

以下是专为rsa和ecdsa密钥设计的套件配置：

注意：建议先在临时环境中测试tls配置，只有在确定一切按预期工作时才转移到生成环境。请注意，以上是一个通用列表，并非所有系统（尤其是旧系统）都支持所有套件，所以建议参考《ssl服务器配置评级指南》进行检测。

以上示例配置使用标准的tls套件名称。一些平台使用非标准名称；有关更多详细信息，请参阅您平台的文档。例如，以下套件名称将与openssl一起使用：

2.4选择最佳密码套件

在 ssl 3.0 及更高版本的协议中，客户端需提交他们支持的密码套件列表，服务器从列表中选择一个用于连接的套件。然而，并非所有服务器都能做出最佳选择。有些服务器会从客户端列表中选择第一个支持的套件。因此，让服务器主动选择最佳可用密码套件才能使ssl部署安全达到最佳化。

2.5使用前向保密

前向保密（也称完美前向保密，简称pfs），它是一种协议功能，可不依赖于服务器私钥实现安全对话。如果不使用前向保密的密码套件，他人就能恢复服务器私钥，进而解密所有先前记录下来加密对话。使用ecdhe套件就能在web浏览器中启用前向保密。为了支持更广泛的客户端，您还应该使用 dhe套件作为ecdhe后备。除非绝对必要，请避免rsa密钥交换。

2.6使用强密钥交换

对于密钥交换，公共站点通常可以选择常用的diffie-hellman密钥交换(dhe)或椭圆曲线变体ecdhe。rsa密钥交换应用非常广泛，但它不提供前向保密。当然还有其他密钥交换算法，但它们通常不安全。

2015年，一组研究人员发表了针对dhe的新攻击，他们的工作被称为logjam攻击。 研究人员发现，较低强度的dh密钥交换（例如768位）很容易被破解。为了安全起见，如果部署 dhe，请至少配置2048位。一些老版本的客户端（例如java 6）可能不支持这种强度级别。ecdhe相比之下性能更高、更快速。secp256r1命名曲线（也称为p-256）是一个不错的选择。

小结

近年来发生了几次针对ssl和tls的严重攻击，但如果您运行的是最新软件并遵循本指南中的ssl部署最佳实践建议，那就不必太过担心这些问题。但是，没有什么是绝对安全的，最好的做法是密切关注网络安全，及时解决安全漏洞问题。

关于更多ssl部署相关问题，请上
https://www.racent.com/ssl了解详情！