It would be useful if a Github Repo of example private keys usable for testing existed. It would feature:
Keys for every type accepted by Boulder/Pebble
100+ Samples of every accepted RSA bit
100+ Samples of every accepted EC curve
Keys for one or more types not-accepted by Boulder/Pebble:
10+ RSA with too many or too few bits;
10+ EC on an unsupported curve;
10+ DSA as unsupported technology;
Examples of "debian weak keys" and other blocked keys not-accepted by Boulder/Pebble, sorted by type
The reason for a doing this in a separate repo, is that other projects and clients need example keys for unit/CI tests. If maintainers could leverage "already known and blocklisted" private keys, there would not be a need to generate them - or as much work for LetsEncrypt to datamine and block publicly disclosed keys.
Ideally, projects could just check out the repo and use it as-is for testing.
Any given key can serve multiple purposes in an ACME system: Account Key, Certificate Key, Server's Key. It's possible to recycle one into multiple contexts, but to test account key rollovers and certificate renewals you need a few. I prefer to generate ad-hoc whenever possible and keep everything in memory - but when debugging an edge case I want something repeatable. Given that, I feel like 10 is a safe margin for unit and most integrated tests.
When it comes to integrated tests though, I've found that some edge cases on my projects (and others) don't surface until there is a decent amount of test data in it. I don't think I have ever needed more than 10 yet (and might never), but I'd like to avoid generating new certs as much as possible so I would like a big-bag to pull from if needed.
For an example of larger test data: Register, Order, Renew and Rollover only need 1-2 keys each for a unit test, but if you test a real-life potential flow of "Register, Order, Rollover, Renew, Rollover w/Key Compromised" - the number of required keys jumps up quite a bit.
Given recent events in the USA that highlight a departure from basic computing security norms, I have also been focused on developing backup certificates from alternate CAs.
Other useful data would include some example chains going up to a root.
These could serve both as tests for validation, but also to bootstrap test environments.
For example, the Pebble repo has a single (minica) root and leaf cert. this is perfect for a single CA test system - but a multi-ca system would ideally use unique alternates. Being able to leverage sample data would be much easier than generating and storing my own. The instructions are all there, but it’s an extra 15+ minutes if work, as compared to reusing an existing set. And then the ISRG team eventually needs to blocklist these keys.
Using Python as an example, SSL verification of custom certs is typically handled by passing in a custom ca bundle file. Using multiple different roots (instead of a single shared one) in tests helps ensure the bundle is created correctly and works as intended.
To be clear, this is not necessarily true. We only need to blocklist them if they are compromised. As long as the test keys you generate remain safely in systems you control, we don't need to do anything.
there are about a 100k keys per type (ecdsa included) in Debian-weak-keys/le64 at main · cabforum/Debian-weak-keys · GitHub you could pick few for private keys: and probably already blocklisted on any production CA but test setup unlikely have them because its just big list