Boulder deployment help


I’m looking for deploy a Boulder server on my organization. We have services with clients and requires authorization/authentication in both hosts through certificates. I looked for a CFSSL server, but unfortunately doesn’t have HSM support. Boulder its a very good option, but I don’t know if Boulder can (out of the box) generate client certificates, and if there is some plugin for token authentication/challenge.

Some of the requirements are:

  • Support for HSM
  • ACME-like system
  • Client certs generation
  • Authorization or challenge by tokens
  • Revocation

Thank you for your help.


Hi @adbias,

I’m probably not the best person to answer this because I don’t work on the Boulder code base, but I think the answers that I can offer are

No, but it’s probably a relatively easy change (but see below for my concern about the suitability of ACME for this application).

Boulder is designed to allow you to easily change the authentication methods that it uses and the policies for issuing certificates, but there isn’t existing code to authenticate using methods other than the existing ACME domain validation challenge methods. You would have to write this code yourself.

One other concern: what are the subject identifiers for your client certificate? Are they DNS domain names, or some other kind of identifier?

I’m concerned that ACME itself might not be very suitable for this because it might not have a convenient way to represent the principal that is the subject of a client certificate (as ACME has been created mainly with domain-validated server certificates in mind).

To summarize this point, Boulder and existing ACME clients are definitely not an out-of-the-box solution for issuing client certificates, but in theory they could be customized for that application.


Hi @schoen, thank you for your response.

About the clients, they get an local domain but that is not enough for proving their authenticity. That’s why we’re looking for an authenticated solution through tokens. We chose ACME because it’s a good standard for our systems, and we need both, client and server certificates. With Boulder we can (out of the box) deploy automatic generations of certificates for our servers, and if possible, clients with some code.

Another question: there is a guide for production deployment?


@jsha, do you have any suggestions on this?


Can you describe a little more about how you are using client certificates to authenticate? So far what you’ve said makes sense, but doesn’t match the ways I am familiar with client certificates being used. Like @schoen, I think Boulder (and ACME) are generally not a good match for generating client certificates, but they could be useful under some very narrow circumstances.


Sure. Basically, we have an application with a client and server side. Both need certificates for HTTPS and authentication/authorization to other applications. I want to use Boulder to provide these certificates.

I’m currently using the SSLVerifyClient option on the application’s httpd server. We want to publish the client side of this application, but without a certificate anyone could connect to the protected server. With client certificates, we could prove the authenticity of this host running the application, check their details for monitoring, and also revoke permissions easily in case of host compromise.

We have analyzed other options, but Boulder seems to be the best option so far because it has the majority of the tools we need for our self-signed CA.

Thank you for your response.


Are the clients servers in your production infrastructure, or are they end-user laptop and desktop computers?

Do you manage those clients with any sort of centralized management software, like Chef, Puppet or Salt (for servers), or Munki or Jamf (for clients)? I ask because in a centralized management environment, it’s often much cleaner to simply generate the client certificates as part of your management environment and push them out to the clients, rather than having the clients self-enroll. Where ACME really comes into play is when you don’t directly control the clients. I wrote as a lightweight solution in that centralized management use case.

That said, if you still think Boulder is the best fit, you’ll probably want to check out our deployment guide: