Can an HTTPS server accidentally leak its private key?
Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?
Yes - the Heartbleed bug involved memory leaks out of the HTTP server such that:
We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, ...
Aside from bugs like that,
Is it even technically possible for a bad website admin to misconfigure a site to send the private key as part of the certificate chain?
Sure. If you specify the wrong file in, for example, SSLCertificateChainFile then Boom! There goes the private key.
As @duskwuff points out in the comments, there are protections against this. Neither Apache nor NGINX will send a key PEM that's included in a certificate file; they will silently strip it out (which, I'm willing to bet, is a protection put in place after some number of events where people did what I suggested might work).
Other misconfigurations, such as incorrect web root combined with loose permissions or excessive web server privileges, will also leak the key, but those misconfigurations are both mundane and extreme (e.g., you really have to be trying to break things that badly).
Doing so is not recommended.
Yes, via either misconfiguration or as-yet unknown misconfigurations. I won't repeat the content of @gowenfawr 's answer.
It is worth mentioning as an aside that there are a number of possible misconfigurations that do not directly leak the key but could allow an attacker to decipher parts of the communication. Part of the work towards TLS 1.3 aims to mitigate this via removing support for certain ciphers and other potentially insecure configurations (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/).
Likewise there are other things that can cause loss of confidentiality; such as the SSL v2 vulnerability known as DROWN (https://drownattack.com/) where previously SSL v2 was known to be insecure but many installations left it enabled for compatibility reasons.
While not ideal, this led to the possibility of extracting the session key from a server that used the same keys or certificate but happened to be running SSL v2 via a padding oracle, even exposing the contents of TLS 1.2 services using the same certificate (after observing a number of connections between the victim and the server).
DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.
In terms of directly leaking the key, you can also serve up your private key on a misconfigured web server, or via a directory traversal (or similar) issue
I discovered a flaw in Traefik not too long ago where an API endpoint was leaking the private key for their SSL certificate (CVE-2018-15598).
https://twitter.com/edoverflow/status/1031267058615508994
