What could Let’s Encrypt do to make client dev easier?

It's great for many situations and integrated testing, but it's not a good option for TDD, unit tests and CI.

I think overall code quality of clients would be GREATLY improved if testing were made easier. So much can even be done for free with a basic github account.

5 Likes

I am working on two things right now, some of which I already knew I wanted to do before making this thread, but this has helped me

  1. A common integration test suite that runs through the basics (all common challenges, some error conditions) against any given ACME CA. The goal here is so that as ACME CA authors, we can test many of the most popular clients. I hope it would be easy for client developers to use it to test their own clients as well. The test harness will support running Pebble and Boulder locally, as well as using any ACMe CA by directory url, like Let’s Encrypt Staging or production.

  2. A “warm welcome” document intended to teach ACME in much more approachable language than the RFCs do. It will have sample request:responses that could be used to unit test an implementation, and will call out pitfalls and things that could be security issues. I hope this to be useful to acme client developers writing a client, as well as anyone who wants to understand the protocol in some depth.

10 Likes

It would likely be greatly beneficial for client developers to have a walk through the ACME cert acquisition process step-by-step with explicit states/errors outlined and transition conditions specified (think execution flow chart in text format much like a numbered algorithm). The "input" and "output" at each step/state would be nice.

6 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.