The ever-continuing push for digitalisation has increased our reliance on trust services of various kinds, filling various needs relating to document signing, code signing, authorization tokens, and so forth. Many of these trust services rely on public-key infrastructure (PKI) and X.509 certificates.
The sensitive nature of these tools makes them difficult to use in a testing environment. On the one hand, exposing access to production keys in your CI is obviously a terrible idea. But on the other hand, setting up and maintaining a fully functional "mock" PKI environment is also pretty tricky. What can you do about that?
Using PKI tools in test workflows involves many challenges. Here are a few examples:
Even a (supposedly) basic task like validating an X.509 certificate involves quite a bit of complexity. Apart from "local" validation logic, you might also have to check the revocation status of your certificate, which could entail talking to an OCSP responder service or looking up a CRL.
If you're using secure timestamps (RFC 3161) in your code, your tests might also require access to a time stamping service.
Maybe you're using a remote signing service vendor that doesn't offer any sort of "sandbox" for testing purposes.
In all of these scenarios, both test data generation and mock service integration can be quite cumbersome. Both in my own time and on the job, I write a lot of code that relates to digital signing in various ways, and this is a kind of problem that I run into all the time. After trying out a variety of methods, I grew dissatisfied with the "traditional" options, and rolled my own PKI testing framework: Certomancer. Certomancer helps with both test data generation, performs trust service mocking, comes with a plugin API, and most importantly, it's FOSS (MIT licence).
In my talk, I'll take you through some of the "how"s and "why"s of Certomancer's feature set, and talk about some of the mileage that I've gotten out of it.
Speakers: Matthias Valvekens