是否有任何已知的 HTTPS 网站泄露其 SSL 证书的私钥的案例？

是的 - Heartbleed错误涉及 HTTP 服务器的内存泄漏，例如：

我们从外面攻击自己，不留痕迹。在不使用任何特权信息或凭证的情况下，我们能够从自己那里窃取用于 X.509 证书的密钥，...

除了这样的错误，

一个糟糕的网站管理员是否有可能在技术上错误地配置网站以将私钥作为证书链的一部分发送？

当然。例如，如果您在其中指定了错误的文件，SSLCertificateChainFile那么 Boom！那里有私钥。

正如@duskwuff 在评论中指出的那样，有针对这种情况的保护措施。Apache 和 NGINX 都不会发送包含在证书文件中的密钥 PEM；他们会默默地把它去掉（我敢打赌，这是在人们做了我建议的可能有效的一些事件之后实施的一种保护）。

其他错误配置，例如不正确的 web root 加上宽松的权限或过多的 web 服务器权限，也会泄漏密钥，但这些错误配置既平凡又极端（例如，你真的必须尝试破坏那么糟糕的东西）。

不建议这样做。

是的，通过错误配置或未知的错误配置。我不会重复@gowenfawr 回答的内容。

值得一提的是，有许多可能的错误配置不会直接泄露密钥，但可能允许攻击者破译部分通信。TLS 1.3 的部分工作旨在通过删除对某些密码和其他潜在不安全配置的支持来缓解这种情况 ( https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/ )。

同样，还有其他可能导致机密性丢失的事情；例如称为 DROWN ( https://drownattack.com/ ) 的 SSL v2 漏洞，以前已知 SSL v2 是不安全的，但许多安装出于兼容性原因将其启用。

虽然并不理想，但这导致从使用相同密钥或证书但碰巧通过填充 oracle 运行 SSL v2 的服务器中提取会话密钥的可能性，甚至使用相同证书公开 TLS 1.2 服务的内容（之后观察受害者和服务器之间的许多连接）。

DROWN 表明仅支持 SSLv2 对现代服务器和客户端是一种威胁。它允许攻击者通过向支持 SSLv2 并使用相同私钥的服务器发送探测来解密最新客户端和服务器之间的现代 TLS 连接。

在直接泄露密钥方面，您还可以在配置错误的 Web 服务器上提供您的私钥，或通过目录遍历（或类似）问题

不久前，我在 Traefik 中发现了一个缺陷，即 API 端点泄露了其 SSL 证书的私钥 (CVE-2018-15598)。

https://twitter.com/edoverflow/status/1031267058615508994

是否有任何已知的 HTTPS 网站泄露其 SSL 证书的私钥的案例？

严格来说，私钥应该有权限dr--------，带有root:root. 因此，只有 root 用户可以读取证书。如果配置错误并且 Web 服务器可以访问私钥，那么在某些情况下，例如 Web 服务器会受到威胁。然后在这里我们可以看到私钥在不知不觉中被网络服务器“泄露”了。当然，这适用于任何对私钥具有读取权限的程序。

一个糟糕的网站管理员是否有可能在技术上错误地配置网站以将私钥作为证书链的一部分发送？

通过配置，我用 Apache 2 做了，不！因此，我的 Web 服务器配置之一涉及：

    SSLCertificateFile /etc/apache2/ssl/safesploit.com.cert.pem
    SSLCertificateKeyFile /etc/apache2/ssl/safesploit.com.key.pem
    SSLCertificateChainFile /etc/apache2/ssl/fullchain.pem

因此，虽然我理解您对将私钥放置在全链中的“坏管理员”的担忧，但在 Apache 2 vanilla 中根本不可能，除非 Apache 被修改为接受这种类型的配置。

对于上下文：

• 公钥 -r--r--r-- root root
• 私钥 -r-------- root root