Certbot 的 TLS 密码套件策略默认加密配置、自动更新机制与 Mozilla 参考标准全解析【免费下载链接】certbotCertbot is EFFs tool to obtain certs from Lets Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.项目地址: https://gitcode.com/gh_mirrors/ce/certbotCertbot 作为 EFF 推出的 ACME 协议客户端不仅负责从 Lets Encrypt 等 CA 获取证书还能在启用 TLS 时同步调整 Web 服务器的加密参数。本文基于 ciphers.rst 全面讲解 Certbot 的密码套件Ciphersuites设计思路默认值从何而来、如何随版本自动演进、何时不会干预你的服务器并结合仓库内 nginx / Apache 的实际配置文件与源码帮助读者理解并掌控自己服务器上的 TLS 加密策略。为什么需要讨论密码套件加密选择影响安全、兼容性与性能当客户端连接到 TLS 服务器时服务器软件可以在一定范围内决定使用哪种密码学机制。这些选择会以复杂的方式影响安全性、兼容性和性能而且绝大多数选项与某张具体的证书无关。Certbot 的立场是为用户提供我们认为最有用的默认值同时尊重每个站点按自身策略调整的权利。证书与服务器 TLS 配置是两回事需要特别区分两个层面证书本身以当前仓库版本为例证书由 Lets Encrypt 使用其 2048 位 RSA 密钥进行 RSA 签名描述订阅者不小于 2048 位的 RSA 公钥subject public key该公钥用于密钥建立key establishment。服务器 TLS 配置证书并不指定其他加密细节——例如是否使用 3DES 之类的对称算法、采用哪种密码模式、协商哪条密码套件这些都在客户端与服务器之间独立协商与证书内容无关。值得强调的是订阅者的 RSA 公钥可以被用于多种密钥建立方法其中大部分并不直接用 RSA 做密钥交换而只是用于服务器身份认证。例如在 DHE 和 ECDHE 密钥交换中subject public key 仅用于对其它参数签名以完成认证。也就是说仅仅因为使用 RSA 密钥做认证并不意味着你必须为其它目的使用 RSA。Lets Encrypt 希望提供反映公开已知最佳实践的默认值但CA 并不替终端用户决定安全策略——任何站点都可以按自身策略或管理员偏好使用与 Certbot 默认值不同的加密机制、参数或优先级顺序。Certbot 的自动更新机制Autoupdates原文档明确指出在新版本 Certbot 安装时例如通过操作系统包管理器升级Certbot默认会修改服务器软件的加密设置使其跟上我们认为合适的默认值。这一特性在仓库代码中有清晰的落地nginx 插件在prepare()阶段调用install_ssl_options_conf与install_ssl_dhparams见 nginx/configurator.py把随发行版附带的 TLS 参数文件复制到配置目录。Apache 插件在prepare()阶段同样调用install_ssl_options_conf见 apache/configurator.py。版本受控的配置文件更新自动更新不是简单地覆盖文件而是通过版本受控方式完成nginx 侧写入options-ssl-nginx.conf及其摘要文件.updated-options-ssl-nginx-conf-digest.txt见 nginx/constants.pyDH 参数文件写入ssl-dhparams.pem摘要为.updated-ssl-dhparams-pem-digest.txt见 constants.py。仓库通过维护ALL_SSL_DHPARAMS_HASHES当前收录一个 SHA-256 值来识别历史上所有版本的参数文件见 constants.py。如果用户手工修改了这些文件Certbot 将无法再自动提供未来的安全更新此时它会打印并记录一条错误信息给出最新文件的路径供用户手动参考更新——这一行为在 options-ssl-nginx.conf 等文件头部的注释中有明确说明。当该特性后续进一步实现时文档会补充如何禁用这些自动更改的说明。默认值来源Mozilla 的 Modern / Intermediate / Old 三档配置默认跟随 Mozilla 的 Intermediate 配置Certbot 初始版本将用户服务器配置为Mozilla 项目推荐的加密默认值。Mozilla 提供三套安全性与兼容性取舍不同的配置按安全性从高到低、向后兼容性从低到高排列配置档位安全性向后兼容性适用场景Modern最高最低只服务最新客户端IntermediateCertbot 默认中中兼顾安全与兼容的通用站点Old最低最高必须兼容极老客户端至少在密码套件与 TLS 版本方面Certbot 默认遵循Intermediate档位。Mozilla 官网会说明每种配置兼容哪些客户端软件你也可以用 Qualys SSL Labs 的扫描服务检查自己的服务器与特定软件版本的兼容性。跟随建议的演进节奏Lets Encrypt 项目预期在未来持续跟进 Mozilla 建议的更新。原文档中举了一个具体例子密码套件0xcc13TLS 1.2 中结合 ChaCha 与 Poly1305 算法的套件Chrome 浏览器当时已实现。Mozilla 出于兼容性与标准化方面的顾虑推迟推荐它但一旦顾虑解决、Mozilla 开始推荐Certbot 也会随之跟进优先使用该套件。同时Lets Encrypt 项目可能在充分理由下偏离 Mozilla 建议但流程上要求任何改变优先级的提案应首先提交给 Mozilla 安全团队他们有更充足的资源和专业能力评估建议是否应更新之后才向 Certbot 开发者提出。此外相比直接修改既有配置项目更倾向于创建极少数额外的备选配置除 Modern、Intermediate、Old 之外例如为大量系统管理员希望跟踪其它专家建议的场景增加一个选项。仓库中的实际落地nginx 与 Apache 配置文件nginx 的四套配置文件与版本探测逻辑仓库在 nginx/tls_configs/ 目录下提供了四份 TLS 参数文件其选择逻辑见 nginx/configurator.pyoptions-ssl-nginx.conf——当前版本启用 TLSv1.2/TLSv1.3 且关闭 session ticketsoptions-ssl-nginx-tls13-session-tix-on.conf——支持 TLS 1.3 但 OpenSSL 版本过旧、无法关闭 session ticketsoptions-ssl-nginx-tls12-only.conf——仅 TLSv1.2、可关闭 session ticketsoptions-ssl-nginx-old.conf——仅 TLSv1.2、无法关闭 session ticketsnginx 1.13.0 或 OpenSSL 1.0.2l已停止更新。选择依据是两项运行时探测use_tls13 nginx 版本 (1, 13, 0)以及session_tix_off nginx 版本 (1, 5, 9) 且 OpenSSL 版本 1.0.2l。之所以如此复杂是因为 Mozilla 的 Intermediate 建议与不同 nginx/OpenSSL 组合的能力存在错配TLS 1.3 只有较新的 nginx 支持session tickets 的关闭需要足够新的 nginx 与 OpenSSL旧版 OpenSSL 存在导致浏览器报错的 bug。项目偏好宁可开放也不报错——即优先保证可用性因此出现上述四种组合。若命中废弃配置插件会记录警告提示更新 nginx 以获得最新配置。当前版本options-ssl-nginx.conf的核心内容内容基于 Mozilla 的 ssl-config 生成器ssl_session_cache shared:le_nginx_SSL:10m; ssl_session_timeout 1440m; ssl_session_tickets off; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;要点解读TLS 版本仅启用 TLSv1.2 与 TLSv1.3彻底排除 SSLv2/SSLv3/TLSv1.0/TLSv1.1。ssl_prefer_server_ciphers off不强制服务器优先选择密码套件与 Mozilla Intermediate 建议一致现代客户端已能正确选择。套件清单优先 ECDHE 系列ECDSA 与 RSA 证书均覆盖AES-GCM 与 CHACHA20-POLY1305 兼顾硬件加速与移动端性能DHE-RSA 作为向后兼容的备选全部套件均支持前向保密forward secrecy。nginx 部署时会在 vhost 中加入ssl_dhparam指令指向 Certbot 安装的 DH 参数文件见 nginx/configurator.py。Apache 的两套配置文件Apache 插件在 apache/tls_configs/ 目录下提供两份文件current-options-ssl-apache.conf——当前版本old-options-ssl-apache.conf——用于 Apache 2.4.11 或 OpenSSL 1.0.2l 的废弃版本已停止更新。当前版本的核心内容SSLEngine on # Intermediate configuration, tweak to your needs SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLOpenSSLConfCmd Curves X25519:prime256v1:secp384r1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305 SSLHonorCipherOrder off SSLSessionTickets off SSLOptions StrictRequire与 nginx 版本相比Apache 配置还通过SSLOpenSSLConfCmd Curves显式指定椭圆曲线优先级X25519 优先其次 prime256v1 与 secp384r1并额外包含DHE-RSA-CHACHA20-POLY1305。Apache 插件会把该文件以Include指令挂入虚拟主机见 apache/configurator.py。前向保密与标准化的 DH 参数为了让 DHE 套件具备前向保密Certbot 随发行版附带了 DH 参数文件 ssl-dhparams.pem。该文件内容为 2048 位的标准 DH 组参数其理念与 IETF 的RFC 7919《Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS》一致RFC 7919 主张在所有情况下使用标准化 DH 组而不是各自挑选的组——主要原因之一是 Triple Handshake 攻击可能涉及恶意选择无效 DH 组RFC 提供推荐组列表素数从 2048 位起步同时提供用于协商这些组的新协议机制并保留对不了解该机制的旧客户端/服务器的向后兼容允许使用较弱 DH 组。Certbot 的SSL_DHPARAMS_SRC通过importlib.resources从发行版内取出该文件见 constants.py并保存到配置目录下的ssl-dhparams.pemnginx 插件即通过ssl_dhparam指令引用它。什么情况下 Certbot 不会修改加密配置并非所有获取证书的路径都会改写服务器加密参数不使用集成时如果你没有让 Certbot 直接配置服务器——因为客户端不集成你的服务器软件或你主动选择不使用该集成——那么加密默认值不会被修改服务器仍使用其软件自带的默认加密策略。standalone 模式例如你用standalone模式获取证书后手动安装到 IMAP 或 LDAP 服务器客户端不会以任何方式改动你的加密设置。也就是说启用 TLS 并改写其加密配置与获取证书是两个独立步骤前者仅在 Certbot 与 Web 服务器集成时才发生。资源、反馈与兼容性注意事项密码套件选择的参考资料Certbot 团队在制定默认值过程中参考了大量专家建议以下是原文档收录的主要权威资源供读者自行评估参数取舍注意不同建议可能反映不同的优先级尤其是兼容性考量RFC 7525BCPIETF 发布的《Recommendations for Secure Use of TLS and DTLS》。BetterCrypto.org欧洲 IT 安全专家协作发布的《Applied Crypto Hardening》草案论文。RFC 7919前述关于标准化离散对数 DH 参数的 RFC。Mozilla通用服务器配置指南及其配置生成器Certbot 默认值即源自此处。荷兰国家网络安全中心Dutch NCSC发布《ICT-beveiligingsrichtlijnen voor TLS》TLS 的 IT 安全准则仅荷兰语。Keylength.com汇总学术界与标准组织对特定加密周期、年份或安全级别的密钥长度建议。NISTSP 800-52 Rev.2《TLS 实现的选择、配置与使用指南》与 SP 800-57《密钥管理建议》。ENISA《Algorithms, Key Sizes and Parameters Report - 2013》。WeakDH/Logjam 研究质疑了使用素数 ≤ 1024 位的标准化 DH 组的既有实践作者提供了含密码套件清单的详细建议其立场支持 ECDHE也支持上述 FF-DHE 草案中的标准化组。具体站点的配置案例原文档还收录了一些站点或项目的实际配置可作参考U.S. Government 18F站点使用ssl_ciphers kEECDHECDSAAES128 kEECDHECDSAAES256 kEECDHAES128 kEECDHAES256 kEDHAES128 kEDHAES256 DES-CBC3-SHA SHA !aNULL !eNULL !LOW !MD5 !EXP !DSS !PSK !SRP !kECDH !CAMELLIA !RC4 !SEED这类 OpenSSL 风格表达式。Duraconf 项目收集具体配置文件明显侧重于避免过时的对称密码与哈希函数并偏好但不强制前向保密。Amazon ELB在文档中解释其当前的密码套件选择。站点扫描与评级工具Qualys SSL Labs最知名的 TLS 安全扫描器可检验服务器与特定软件版本的兼容性。荷兰 NCSC 的 en.internet.nl指示站点对 NCSC 建议的符合程度。Java 兼容性问题DHE 素数 1024 位限制大量向后兼容性顾虑与 Java 的行为有关部分 Java 版本将 DHE 素数硬编码限制为 1024 位——它们在协商中接受 DHE 套件但当服务器呈现素数大于 1024 位的 DH 组时会直接中断整个连接。简单总结如果服务器把与 Java 兼容的 DHE 套件排在其它 Java 兼容套件之前却又提供素数大于 1024 位的 DH 组那么与运行某些 Java 版本的客户端将完全不兼容极老的 MSIE 版本也可能存在类似问题。这对希望服务 Java 客户端的站点是一个需要权衡的部署要点。反馈的收集方式由于部分讨论适用查塔姆宫规则Chatham House Rule反馈提供者不会逐个署名。反馈中常见的诉求与兼容性相关例如某些用户代理不支持 ECC或不支持大于 1024 位的 DH 组。为此部分配置方案会在保持新客户端协商更强加密的同时提高对旧用户代理的兼容性——比如完全放弃为旧 UA 连接提供前向保密仅提供 ECDHE 与 RSA 密钥交换而不提供任何 DHE存在这样的 UA如果服务器提供了素数大于 1024 位的 DHE 套件它们会直接协商失败。小结如何理解并掌控你的 TLS 默认值从本文可以总结出 Certbot 在密码套件问题上的完整立场与机制默认值来自 Mozilla Intermediate 档位随 Certbot 新版本发布而更新并通过版本受控的摘要机制写入options-ssl-nginx.confnginx或options-ssl-apache.confApache以及标准化的 2048 位ssl-dhparams.pem自动更新覆盖范围只针对与 Certbot 集成的 Web 服务器standalone 模式或手工安装证书的服务器不会被改动手工修改即放弃自动更新——配置文件头部明确提示自定义后将由 Certbot 打印错误信息并指向最新文件供手动参照证书与密码套件相互独立——证书只描述密钥与签名套件协商完全由服务器与客户端完成仓库源码nginx/configurator.py、apache/configurator.py、constants.py展示了这一策略在真实发行版中的精确实现任何管理员都可以对照这些文件核对自己服务器上的实际生效参数。想进一步研究可阅读仓库中的 ciphers.rst 原文或直接查看 nginx 的 TLS 配置目录 与 Apache 的 TLS 配置目录 中的完整文件内容。【免费下载链接】certbotCertbot is EFFs tool to obtain certs from Lets Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.项目地址: https://gitcode.com/gh_mirrors/ce/certbot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Certbot 的 TLS 密码套件策略：默认加密配置、自动更新机制与 Mozilla 参考标准全解析
Certbot 的 TLS 密码套件策略默认加密配置、自动更新机制与 Mozilla 参考标准全解析【免费下载链接】certbotCertbot is EFFs tool to obtain certs from Lets Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.项目地址: https://gitcode.com/gh_mirrors/ce/certbotCertbot 作为 EFF 推出的 ACME 协议客户端不仅负责从 Lets Encrypt 等 CA 获取证书还能在启用 TLS 时同步调整 Web 服务器的加密参数。本文基于 ciphers.rst 全面讲解 Certbot 的密码套件Ciphersuites设计思路默认值从何而来、如何随版本自动演进、何时不会干预你的服务器并结合仓库内 nginx / Apache 的实际配置文件与源码帮助读者理解并掌控自己服务器上的 TLS 加密策略。为什么需要讨论密码套件加密选择影响安全、兼容性与性能当客户端连接到 TLS 服务器时服务器软件可以在一定范围内决定使用哪种密码学机制。这些选择会以复杂的方式影响安全性、兼容性和性能而且绝大多数选项与某张具体的证书无关。Certbot 的立场是为用户提供我们认为最有用的默认值同时尊重每个站点按自身策略调整的权利。证书与服务器 TLS 配置是两回事需要特别区分两个层面证书本身以当前仓库版本为例证书由 Lets Encrypt 使用其 2048 位 RSA 密钥进行 RSA 签名描述订阅者不小于 2048 位的 RSA 公钥subject public key该公钥用于密钥建立key establishment。服务器 TLS 配置证书并不指定其他加密细节——例如是否使用 3DES 之类的对称算法、采用哪种密码模式、协商哪条密码套件这些都在客户端与服务器之间独立协商与证书内容无关。值得强调的是订阅者的 RSA 公钥可以被用于多种密钥建立方法其中大部分并不直接用 RSA 做密钥交换而只是用于服务器身份认证。例如在 DHE 和 ECDHE 密钥交换中subject public key 仅用于对其它参数签名以完成认证。也就是说仅仅因为使用 RSA 密钥做认证并不意味着你必须为其它目的使用 RSA。Lets Encrypt 希望提供反映公开已知最佳实践的默认值但CA 并不替终端用户决定安全策略——任何站点都可以按自身策略或管理员偏好使用与 Certbot 默认值不同的加密机制、参数或优先级顺序。Certbot 的自动更新机制Autoupdates原文档明确指出在新版本 Certbot 安装时例如通过操作系统包管理器升级Certbot默认会修改服务器软件的加密设置使其跟上我们认为合适的默认值。这一特性在仓库代码中有清晰的落地nginx 插件在prepare()阶段调用install_ssl_options_conf与install_ssl_dhparams见 nginx/configurator.py把随发行版附带的 TLS 参数文件复制到配置目录。Apache 插件在prepare()阶段同样调用install_ssl_options_conf见 apache/configurator.py。版本受控的配置文件更新自动更新不是简单地覆盖文件而是通过版本受控方式完成nginx 侧写入options-ssl-nginx.conf及其摘要文件.updated-options-ssl-nginx-conf-digest.txt见 nginx/constants.pyDH 参数文件写入ssl-dhparams.pem摘要为.updated-ssl-dhparams-pem-digest.txt见 constants.py。仓库通过维护ALL_SSL_DHPARAMS_HASHES当前收录一个 SHA-256 值来识别历史上所有版本的参数文件见 constants.py。如果用户手工修改了这些文件Certbot 将无法再自动提供未来的安全更新此时它会打印并记录一条错误信息给出最新文件的路径供用户手动参考更新——这一行为在 options-ssl-nginx.conf 等文件头部的注释中有明确说明。当该特性后续进一步实现时文档会补充如何禁用这些自动更改的说明。默认值来源Mozilla 的 Modern / Intermediate / Old 三档配置默认跟随 Mozilla 的 Intermediate 配置Certbot 初始版本将用户服务器配置为Mozilla 项目推荐的加密默认值。Mozilla 提供三套安全性与兼容性取舍不同的配置按安全性从高到低、向后兼容性从低到高排列配置档位安全性向后兼容性适用场景Modern最高最低只服务最新客户端IntermediateCertbot 默认中中兼顾安全与兼容的通用站点Old最低最高必须兼容极老客户端至少在密码套件与 TLS 版本方面Certbot 默认遵循Intermediate档位。Mozilla 官网会说明每种配置兼容哪些客户端软件你也可以用 Qualys SSL Labs 的扫描服务检查自己的服务器与特定软件版本的兼容性。跟随建议的演进节奏Lets Encrypt 项目预期在未来持续跟进 Mozilla 建议的更新。原文档中举了一个具体例子密码套件0xcc13TLS 1.2 中结合 ChaCha 与 Poly1305 算法的套件Chrome 浏览器当时已实现。Mozilla 出于兼容性与标准化方面的顾虑推迟推荐它但一旦顾虑解决、Mozilla 开始推荐Certbot 也会随之跟进优先使用该套件。同时Lets Encrypt 项目可能在充分理由下偏离 Mozilla 建议但流程上要求任何改变优先级的提案应首先提交给 Mozilla 安全团队他们有更充足的资源和专业能力评估建议是否应更新之后才向 Certbot 开发者提出。此外相比直接修改既有配置项目更倾向于创建极少数额外的备选配置除 Modern、Intermediate、Old 之外例如为大量系统管理员希望跟踪其它专家建议的场景增加一个选项。仓库中的实际落地nginx 与 Apache 配置文件nginx 的四套配置文件与版本探测逻辑仓库在 nginx/tls_configs/ 目录下提供了四份 TLS 参数文件其选择逻辑见 nginx/configurator.pyoptions-ssl-nginx.conf——当前版本启用 TLSv1.2/TLSv1.3 且关闭 session ticketsoptions-ssl-nginx-tls13-session-tix-on.conf——支持 TLS 1.3 但 OpenSSL 版本过旧、无法关闭 session ticketsoptions-ssl-nginx-tls12-only.conf——仅 TLSv1.2、可关闭 session ticketsoptions-ssl-nginx-old.conf——仅 TLSv1.2、无法关闭 session ticketsnginx 1.13.0 或 OpenSSL 1.0.2l已停止更新。选择依据是两项运行时探测use_tls13 nginx 版本 (1, 13, 0)以及session_tix_off nginx 版本 (1, 5, 9) 且 OpenSSL 版本 1.0.2l。之所以如此复杂是因为 Mozilla 的 Intermediate 建议与不同 nginx/OpenSSL 组合的能力存在错配TLS 1.3 只有较新的 nginx 支持session tickets 的关闭需要足够新的 nginx 与 OpenSSL旧版 OpenSSL 存在导致浏览器报错的 bug。项目偏好宁可开放也不报错——即优先保证可用性因此出现上述四种组合。若命中废弃配置插件会记录警告提示更新 nginx 以获得最新配置。当前版本options-ssl-nginx.conf的核心内容内容基于 Mozilla 的 ssl-config 生成器ssl_session_cache shared:le_nginx_SSL:10m; ssl_session_timeout 1440m; ssl_session_tickets off; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;要点解读TLS 版本仅启用 TLSv1.2 与 TLSv1.3彻底排除 SSLv2/SSLv3/TLSv1.0/TLSv1.1。ssl_prefer_server_ciphers off不强制服务器优先选择密码套件与 Mozilla Intermediate 建议一致现代客户端已能正确选择。套件清单优先 ECDHE 系列ECDSA 与 RSA 证书均覆盖AES-GCM 与 CHACHA20-POLY1305 兼顾硬件加速与移动端性能DHE-RSA 作为向后兼容的备选全部套件均支持前向保密forward secrecy。nginx 部署时会在 vhost 中加入ssl_dhparam指令指向 Certbot 安装的 DH 参数文件见 nginx/configurator.py。Apache 的两套配置文件Apache 插件在 apache/tls_configs/ 目录下提供两份文件current-options-ssl-apache.conf——当前版本old-options-ssl-apache.conf——用于 Apache 2.4.11 或 OpenSSL 1.0.2l 的废弃版本已停止更新。当前版本的核心内容SSLEngine on # Intermediate configuration, tweak to your needs SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLOpenSSLConfCmd Curves X25519:prime256v1:secp384r1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305 SSLHonorCipherOrder off SSLSessionTickets off SSLOptions StrictRequire与 nginx 版本相比Apache 配置还通过SSLOpenSSLConfCmd Curves显式指定椭圆曲线优先级X25519 优先其次 prime256v1 与 secp384r1并额外包含DHE-RSA-CHACHA20-POLY1305。Apache 插件会把该文件以Include指令挂入虚拟主机见 apache/configurator.py。前向保密与标准化的 DH 参数为了让 DHE 套件具备前向保密Certbot 随发行版附带了 DH 参数文件 ssl-dhparams.pem。该文件内容为 2048 位的标准 DH 组参数其理念与 IETF 的RFC 7919《Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS》一致RFC 7919 主张在所有情况下使用标准化 DH 组而不是各自挑选的组——主要原因之一是 Triple Handshake 攻击可能涉及恶意选择无效 DH 组RFC 提供推荐组列表素数从 2048 位起步同时提供用于协商这些组的新协议机制并保留对不了解该机制的旧客户端/服务器的向后兼容允许使用较弱 DH 组。Certbot 的SSL_DHPARAMS_SRC通过importlib.resources从发行版内取出该文件见 constants.py并保存到配置目录下的ssl-dhparams.pemnginx 插件即通过ssl_dhparam指令引用它。什么情况下 Certbot 不会修改加密配置并非所有获取证书的路径都会改写服务器加密参数不使用集成时如果你没有让 Certbot 直接配置服务器——因为客户端不集成你的服务器软件或你主动选择不使用该集成——那么加密默认值不会被修改服务器仍使用其软件自带的默认加密策略。standalone 模式例如你用standalone模式获取证书后手动安装到 IMAP 或 LDAP 服务器客户端不会以任何方式改动你的加密设置。也就是说启用 TLS 并改写其加密配置与获取证书是两个独立步骤前者仅在 Certbot 与 Web 服务器集成时才发生。资源、反馈与兼容性注意事项密码套件选择的参考资料Certbot 团队在制定默认值过程中参考了大量专家建议以下是原文档收录的主要权威资源供读者自行评估参数取舍注意不同建议可能反映不同的优先级尤其是兼容性考量RFC 7525BCPIETF 发布的《Recommendations for Secure Use of TLS and DTLS》。BetterCrypto.org欧洲 IT 安全专家协作发布的《Applied Crypto Hardening》草案论文。RFC 7919前述关于标准化离散对数 DH 参数的 RFC。Mozilla通用服务器配置指南及其配置生成器Certbot 默认值即源自此处。荷兰国家网络安全中心Dutch NCSC发布《ICT-beveiligingsrichtlijnen voor TLS》TLS 的 IT 安全准则仅荷兰语。Keylength.com汇总学术界与标准组织对特定加密周期、年份或安全级别的密钥长度建议。NISTSP 800-52 Rev.2《TLS 实现的选择、配置与使用指南》与 SP 800-57《密钥管理建议》。ENISA《Algorithms, Key Sizes and Parameters Report - 2013》。WeakDH/Logjam 研究质疑了使用素数 ≤ 1024 位的标准化 DH 组的既有实践作者提供了含密码套件清单的详细建议其立场支持 ECDHE也支持上述 FF-DHE 草案中的标准化组。具体站点的配置案例原文档还收录了一些站点或项目的实际配置可作参考U.S. Government 18F站点使用ssl_ciphers kEECDHECDSAAES128 kEECDHECDSAAES256 kEECDHAES128 kEECDHAES256 kEDHAES128 kEDHAES256 DES-CBC3-SHA SHA !aNULL !eNULL !LOW !MD5 !EXP !DSS !PSK !SRP !kECDH !CAMELLIA !RC4 !SEED这类 OpenSSL 风格表达式。Duraconf 项目收集具体配置文件明显侧重于避免过时的对称密码与哈希函数并偏好但不强制前向保密。Amazon ELB在文档中解释其当前的密码套件选择。站点扫描与评级工具Qualys SSL Labs最知名的 TLS 安全扫描器可检验服务器与特定软件版本的兼容性。荷兰 NCSC 的 en.internet.nl指示站点对 NCSC 建议的符合程度。Java 兼容性问题DHE 素数 1024 位限制大量向后兼容性顾虑与 Java 的行为有关部分 Java 版本将 DHE 素数硬编码限制为 1024 位——它们在协商中接受 DHE 套件但当服务器呈现素数大于 1024 位的 DH 组时会直接中断整个连接。简单总结如果服务器把与 Java 兼容的 DHE 套件排在其它 Java 兼容套件之前却又提供素数大于 1024 位的 DH 组那么与运行某些 Java 版本的客户端将完全不兼容极老的 MSIE 版本也可能存在类似问题。这对希望服务 Java 客户端的站点是一个需要权衡的部署要点。反馈的收集方式由于部分讨论适用查塔姆宫规则Chatham House Rule反馈提供者不会逐个署名。反馈中常见的诉求与兼容性相关例如某些用户代理不支持 ECC或不支持大于 1024 位的 DH 组。为此部分配置方案会在保持新客户端协商更强加密的同时提高对旧用户代理的兼容性——比如完全放弃为旧 UA 连接提供前向保密仅提供 ECDHE 与 RSA 密钥交换而不提供任何 DHE存在这样的 UA如果服务器提供了素数大于 1024 位的 DHE 套件它们会直接协商失败。小结如何理解并掌控你的 TLS 默认值从本文可以总结出 Certbot 在密码套件问题上的完整立场与机制默认值来自 Mozilla Intermediate 档位随 Certbot 新版本发布而更新并通过版本受控的摘要机制写入options-ssl-nginx.confnginx或options-ssl-apache.confApache以及标准化的 2048 位ssl-dhparams.pem自动更新覆盖范围只针对与 Certbot 集成的 Web 服务器standalone 模式或手工安装证书的服务器不会被改动手工修改即放弃自动更新——配置文件头部明确提示自定义后将由 Certbot 打印错误信息并指向最新文件供手动参照证书与密码套件相互独立——证书只描述密钥与签名套件协商完全由服务器与客户端完成仓库源码nginx/configurator.py、apache/configurator.py、constants.py展示了这一策略在真实发行版中的精确实现任何管理员都可以对照这些文件核对自己服务器上的实际生效参数。想进一步研究可阅读仓库中的 ciphers.rst 原文或直接查看 nginx 的 TLS 配置目录 与 Apache 的 TLS 配置目录 中的完整文件内容。【免费下载链接】certbotCertbot is EFFs tool to obtain certs from Lets Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.项目地址: https://gitcode.com/gh_mirrors/ce/certbot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考