HTTP Management Interface about pebble HOT 6 OPEN

Another potential use case (from #177): checking which certificates have been revoked as a light-weight alternative to OCSP or trying to revoke the certificate again.

from pebble.

As discussed in #242, I would like to propose some basic spec around this feature.

I propose to expose every admin/test related stuff endpoint at the root context /, listening to a port defined in a new adminPort field in the Pebble JSON configuration file. The one proposed in the GIT repo will have the default value of 4000. Not specifying this field in a given configuration will disable the interface. The protocol will be HTTPS, using the same certificate than on port 14000 for the ACME protocol, and so consumes the existing configuration fields on that matter.

What do you think of that @cpu @jsha?

from pebble.

@adferrand That sounds great 👍 I like the idea of putting it on a separate port and disabling the administrative interface outright if it isn't configured. Thanks for volunteering to spec this out/implement it!

The one proposed in the GIT repo will have the default value of 4000

This is totally a bike-shed comment but I think I'd prefer 15000 as the default port. We use :4000 for HTTP access to the legacy ACME v1 API in Boulder and I'd prefer to avoid confusing someone into thinking any part of this management interface relates to ACME v1.

from pebble.

I'm going to re-open this issue since while there is a separate HTTP(s) management interface thanks to @adferrand (:tada:) it doesn't yet let you inject test data, query expiration data, or otherwise affect validation. There is probably an argument to be made for splitting those into separate issues but for now we can use this one.

from pebble.

I guess it is a good idea to list all PRs here which add functionality to the new management interface.

#252 (recently merged) allows to retrieve certificate revocation status (and also the certificate itself) by the certificate's serial number.

from pebble.

I would appreciate the ability to trigger/untrigger pebble's responses so that:

• the next order(s) will be considered:
  [x] pending (current behavior)
  [] invalid
  [] ready
  [] processing
  [] valid

• the next authorizations(s) will be considered:
  [x] pending (current behavior)
  [] valid
  [] invalid
  [] deactivated
  [] expired
  [] revoked

• authorization challenges start as:
  [x] pending (current behavior)
  [] processing
  [] valid
  [] invalid

A use-case is that I would be able to use hooks in an ACME-client's test script to ensure the client is dealing with every situation/response appropriately. Most clients I have seen will only consider pending/valid in their logic, then bubble up exceptions for other situations; I'd like my client to run tests against pebble on every possible permutation of responses.

from pebble.