I have the option to work on a freelance project with the aim to integrate Boulder in an existing customer PKI infrastructure. The expected advantage is to get rid of all manual processes around RA/CA. In the planned scenario Boulder acts somewhere in the middle: acme-client -> Boulder -> customer PKI
I’m currently unsure if this concept is viable and advantageous. My task would be to implement the
interface between Boulder and the customer PKI. In the referenced thread, probably a similar scenario (see link above), @cpu recommends to use cfssl instead of Boulder, but @jsha sees it different: “Go ahead and try it out”.
Questions:
What is your recommendation for the described scenario (acme-tool/something_else -> Boulder/something_else -> customer PKI)?
What about cfssl or Pebble?
In case of a Boulder integration: Could someone give an (rough) indication concerning the expected effort and complexity?
Has someone done something similar? And what were the lessons learned?
When you say "existing PKI" do you refer to just your existing private keys and certificates or do you refer also to the infrastructure, software, and policies surrounding your existing private keys and certificates?
If you want to continue to maintain the private keys in your current PKI software, your work is mostly going to be adding code to Boulder to securely interface with your PKI. At present it is designed to interface solely with a hardware security module (HSM) or a software-emulated one.
One easy way out of this would be to issue an intermediate certificate from your existing PKI for use with the Boulder one (unless you're using X.509 in some weird non-SSL/TLS application that doesn't support chains). You may not be used to dealing with intermediate certificates in your manual processes but with Boulder your ACME client already knows all about them.
In fact, if you did end up issuing directly from a root you would probably find that some ACME clients will crash without a chain because they've just never seen that before. This would be a valid bug in those clients but nonetheless an example of what can happen when you stray off the beaten path...
cfssl is great for private PKIs but doesn't provide an ACME service so doesn't seem to be what you want.
I haven't looked closely at Pebble. It could indeed make a better foundation for an ACME-based easy-rsa than Boulder. But it probably doesn't separate functions like registration and validations as well as Boulder does (or even at all) so its security may be inadequate at a larger scale.
I looked at it a year ago but I needed it to work for more things than just Server Authentication certificates. Some things in the ACME protocol have gotten a lot better since then: there are new validation methods in the works for other kinds of certificates so you don't have to dream them up yourself, and things like external account binding and the new Order flow simplify the common "I trust this user" and "it's impossible to validate this domain normally" cases a lot better than some of the ideas I had. But even today there would still need to be a lot of work done in Boulder to get it to work for other types of certificates effectively.
Thanks for the detailed answer. The certificate has be generated by the existing Inhouse PKI. So the current plan looks something like this:
ACME-Client <-> ACME-Gateway <-> Inhouse-PKI
I have looked into Boulder and Pebble. Boulder, 57.576 lines of code, seems to be very complex. Peeble, 2.868 lines of code, is much simpler and reduced to handle (nearly) only the ACME (v2) protocol. So I think Pebble could be a good starting point for the planned scenario.
PS: The client must send additional administration data to the Inhouse PKI. To transport them, code must be added to client and server (gateway).
Wern’t repeated warnings in the Pebble README against production use sufficient to scare you off ?
I am not convinced its design is even suitable for building off of.
I would probably agree that cfssl may be a safer bet. No ACME support is unfortunate but the trade-off is pretty expensive just to be able to satisfy that desire.
?