I am currently determining the topic of my bachelor thesis and my team analyzed the need of an ACME based system, since the PKI we currently have, does not support ACME.
I thought about, setting up a cfssl server and extending cfssl so that it can communicate with our PKI via REST API. While doing some researches on this topic, I found that the bare cfssl implementation does not speak ACME either, am I correct?
I now found out about bolder, and wonder if boulder is the way to go for me.
Does it make sense to concentrate on boulder to make our internal CA/PKI able to speak ACME?
Are there already similar projects that I can investigate? Or are there some guides / docs to getting started working and developing boulder
I haven't used it, but step-ca might be a good choice:
Edit:
To expand, there are some past threads discussing using Boulder for an internal CA. For example, this one:
The Boulder developers don't recommend it, since it's not designed to be easy to install, or easy to use in an environment less complicated than a full-on publicly-trusted CA.
It might be a worthwhile project, depending on your goals, but it's not the easiest way to run an internal CA.
Also, I forgot to mention it, but EJBCA Enterprise also supports ACME.
I believe they support a specific older pre-RFC ACME draft. I'm not sure if it is RFC 8555 compatible. I'd love to be corrected about this if I'm wrong!
RFC 8555 isn't very large. It would probably be easier to add another interface to your existing codebase from scratch that translates ACME to its existing API than to add a fully-formed ACME based CA like Boulder alongside the existing CA codebase.