For example, back in March 2020, somebody on m.d.s.policy wondered why seemingly unrelated Web PKI certs had the same private key. So I stared at the certs and I came to the following conclusion:
This company Paessler makes a Windows tool called PRTG with a web interface. It is supplied with a demo certificate. So you set up the tool on a Windows server and it basically works, but the certificate isn't trustworthy.
Some people will click "Ignore" and press on. This is horribly insecure but what's new?
However, some people will decide they need to get a Certificate. Getting a certificate requires a Private Key. Fortunately, PRTG is supplied with a Private Key so no need to go learn how to make one yourself.
So, the people who made PRTG didn't screw up here in the sense that they really did make a test or demo key, and from their point of view obviously it isn't sensitive since everybody has the same key.
Unfortunately their users may not realise and come to depend on this key as "their" private key, and so in this sense it is sensitive, just not for the people who made it.
--
Regardless of who minted the key you have, and whether they understood its importance, in the Web PKI the correct thing to do is always the same and should be pretty easy:
Revoke the certificates for these public keys. Email contacts or Instructions are here: https://ccadb-public.secure.force.com/ccadb/AllProblemReport...
For Let's Encrypt you can actually do this mechanically, their API will accept proof you know the private key as grounds to revoke the certificate even though that's not listed above.
If the CA refuses to revoke a certificate you've genuinely proved you have the key for (follow any instructions carefully) or just goes silent with no action for a prolonged period, report this problem to m.d.s.policy yourself. You should not need to send the private key itself to anybody as "proof" you have it, the whole point of private keys is that you can prove you know this key without revealing it.
Or you generate them on the fly at deployment so that they only exist ephemerally outside the deployment site.
Which is a shame, thanks for resubmitting
Please be more spesific.
Many are for tests and don't go to anything. Some go to really important things though, even among the test keys, and this tool tells you that instantly for billions of keys.
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn NhAAAAAwEAAQAAAYEA2PwvBhXWsPN59WKtqJvXmpbYXQ50zQ1X1MAhrXAOA2UVGxFr4cNz AAWv8cef4/vLDglZu2vBHJtSdijmKBomK5g7rsdgavzuA2nWpLsscL7MeSAZNtvX1DzJzj vBaV1zPuPTaOC/hvrbmr7ZqwaM+UQbUfzRg34rPhDFAfscdlrNCi8w3EuVgFEA6txvjD03 Jqf/STGKU3SC9KIP0ah9BELuBURivf+IsuH7bx9COcWEp6hWjNQhOoTly1AgpTaMQfF8wP bxmJn5Mu5CUzMdhmjuizZwpJH2dtEfWrYet8CIWooHPqXjB1Vo1UJN4MPsv35XmtAW668R pC09J4W+uPC5AblJ/Uv+pbWyuGXY6lzvXrHVXVWedBMLa7gYcGbcdq8XgAOBW0dO7NGHc8 lM7Wz+sl8wehtwusG1sPDEwQbDv9sXHphZI5N9guqGod1sE4p6ryB+LKDl7C3ghXfof+0E INPADPjd4tBDDv/gEbQ3+XXEp9KCZBTAiJwIaDIfAAAFmLGPMguxjzILAAAAB3NzaC1yc2 EAAAGBANj8LwYV1rDzefViraib15qW2F0OdM0NV9TAIa1wDgNlFRsRa+HDcwAFr/HHn+P7 yw4JWbtrwRybUnYo5igaJiuYO67HYGr87gNp1qS7LHC+zHkgGTbb19Q8yc47wWldcz7j02 jgv4b625q+2asGjPlEG1H80YN+Kz4QxQH7HHZazQovMNxLlYBRAOrcb4w9Nyan/0kxilN0 gvSiD9GofQRC7gVEYr3/iLLh+28fQjnFhKeoVozUITqE5ctQIKU2jEHxfMD28ZiZ+TLuQl MzHYZo7os2cKSR9nbRH1q2HrfAiFqKBz6l4wdVaNVCTeDD7L9+V5rQFuuvEaQtPSeFvrjw uQG5Sf1L/qW1srhl2Opc716x1V1VnnQTC2u4GHBm3HavF4ADgVtHTuzRh3PJTO1s/rJfMH obcLrBtbDwxMEGw7/bFx6YWSOTfYLqhqHdbBOKeq8gfiyg5ewt4IV36H/tBCDTwAz43eLQ Qw7/4BG0N/l1xKfSgmQUwIicCGgyHwAAAAMBAAEAAAGAR5q4/d4ZEh3W4kZlHl4HQUmELv lFTCGaGWgp9O0kgrRJybvvCPqRqbE2xafluLtv37rwNKwzdvg+tyV6BkPS0tIS5/N9evDq ro+vuH7YBIDCQzp3d6YGzFAfHIKVqeqfzGIsctCwA6Am9iMC+7BWty9lgKHYlfb92CZ6jN PMKbZ/MVwvWJNMy6JvlhGWcgYFfCk2UnYZur6ZNJeCduKOFujrWSufFioMd1OhwKLlHOF0 jEs9/I1IReJzXqubikm8VbsLia8mfZEfox98SM1nbmVRoTYy00s283be6T0b834iCMOIid 18j7t1lMPcZAi4ZsWfA5YJ2HaWD/vnfzLjcYsnP1/uleNoAmzkSY7LncQaDo6rHfvJZRBe tqYr8rVE3AiWq/OSxoSLw78Bbw1BNbXcdtMIbsAg2AoxYjzHcigS0Swk1lHTVdwq1dEDv2 7nIdjSwoNQdVG9UAr4+C6ASYUd1+l8Idfrg1bBr8gJOOYb1fo/3Km182cOeqyKk46BAAAA wEnCOseDS5nB6Vikw+w830+bhby68cEicNoQm5AljMz/jdc8sIedItZhzrQdyWLrdtwSES 8JIBFI3JYpLZlz3s0y0f4iTNgtUruQIND3J+Msh+vYVbpb6hPVqboV7DK7dgb7gsZCAFSu gdgQk+e/bsCzrJiqp4BSBNbuzqUt5M5/81CD9+UG3nSXEHqmOXzPvF/wmIqeR2P7v1dXpK vsP4vRo7Vy/7odWFz36rgwcFGsx6xmbSP8zXAVxg7bTwa+2wAAAMEA7eFjevAsGSZLQF/x rYvhwkGdC4RSUJh6jPOI8vmM3kcvnduiHTHNQOdD1UkJbU3GjCRf/14yPWFf5K54auqoXP b9Ip0NKAAVqw4kJhdViDTSJQ0XLmL+a5S2jxvPzp3TLg/d/iAMVviliQCd1ybzyIGwNj4t PPJ5outWwXqWq6BynsSqTpR15r+LNaLDrBc5MqnCi4nA56CeQK6nAOXS1xx8bxnFpGKwYj YXAt3gHRMHdxoMj24xoTZejIhulxpBAAAAwQDpg1dTm3RkyZ00++jVK78c0Otcx0tl0AEM d6d5E+CqU3Y5b+RNpBFDOmOjkYOFJQ9rlsndyn0QsCAD6ex17xxqLETL3HK9w7nYkKHHGV bPbYpj+eD9CzraDztFEuhZzTVBN/AfggF/d9DW3/2mvCBQnuh9GwUiqXwjvrormpIkmqki hTU7arJRm5sQHrpHN6Bl2A8pO/YXfDrpggeoibLLzNUkzW0I4ifUT4oD8eHUv6At0SgNGr ecrqg6nIpwdF8AAAAgZmxvd2VyQGZsb3dlcnMtTWFjQm9vay1Qcm8ubG9jYWwBAgM= -----END OPENSSH PRIVATE KEY-----
They then check both certificate transparency to see if the public key matches any certificates that have been generated, and to see if it's used by a github user (will this public key let me in to a github repo)
If neither, then it's not sensitive (well it might be, but only like finding a key on the floor in the street is -- won't do you much good without knowing where you can use it)
In the first case, if you have the private key, you can spoof the website
In the second case, if you have the private key, you not only have push access to the repos that user has (which could be quite wide ranging), but also you're likely able to get into many servers via SSH, as developers tend to use the same ssh key for github and for server access
What their latest software does is take your key and check it against these sources,
Now private keys have a further layer of protection - the passphrase. Turns out the majority of passphrases belonging to the leaked private keys are trivial ones.
Many leaked keys will unlikely to be used anywhere, but it turns out many more are.
