What you are seeing is (90% confidence) the server's certificate's chain of trust, which only contains public keys. At the very least (99% confidence if what you've told us is true), it certainly doesn't contain the server's TLS private key; it might contain something like the ephemeral Diffie-Hellman key exchange parameters or the TLS session key that your browser uses when talking to that specific server, but neither of those will help you compromise anybody else's connection or are any cause for concern to the site admins.
There is no way to make a server send you its private key, short of an extremely severe security hole in either its TLS stack (think Heartbleed) or an arbitrary local file include in a web application (which is somewhat more common but will be idiosyncratic to each application, or at worst common to some applications that share a vulnerable framework component). There is as close to a 0% chance as anything in the real world gets that a server for a major company like Facebook would do it without you even deliberately exploiting the server in some way.
If you think you are seeing private keys in error messages on your client for arbitrary HTTPS servers, you are either unaware of what a private key is and how to recognize one, or you need to talking to Microsoft, Google, Mozilla, OpenSSL, and every other developer of a TLS implementation right now. I'd comfortably take very long odds that it's the first one, and I'm not generally one for taking monetary bets.
If you're actually seeing private keys, go ahead and post a screenshot with most of the key redacted; that won't be enough for anybody who isn't a sysadmin of the site in question to verify that it's the private key but will be more than enough for us to verify that it's probably a private key, and will also be enough to scare the sysadmins in question quite badly and get them to reach out to you.