Specifying alternate CA

Is it possible with boringproxy to specify an alternate CA (for example, my own step-ca server) that supports ACME running on an internal network? Boringproxy would be useful on an internal network for many of the same reasons it’s so useful on the internet.

As an example, the equivalent functionality in Traefik can be accomplished with --certificatesresolvers.myresolver.acme.caserver=https://step.local.lan:9000/acme/acme/directory to point to your local CA, or of course it uses LetsEncrypt if unspecified.

Sorry for the late response. I went ahead and added this functionality, but it’s untested. You can use the -acme-certificate-authority argument when running the server to set a custom ACME URL.

You can get the build here if you wouldn’t mind testing it out:


Here’s the branch if you prefer to build yourself:


1 Like

Thank you! I will test it (probably tomorrow) and report back here. For anybody else who wants to try this out locally, here is how I’ve set up step-ca in my home network.

1 Like

Okay, I tested it out. It kind of worked. Like, 90% worked. I ran the server, it started up and I logged into it. I proceded to make a tunnel and set the TLS Termination to Server HTTPS. Upon adding the tunnel, I was watching my CA server’s output and I could see that it (successfully, from what I could tell) assigned it a certificate. Note that as this is an internal network, the suffix (TLD) is .lan (it could be anything, since it’s not a public-facing domain).

I then started the client up. I got an error from the client that looked something like this:

2022/05/11 15:17:25 CertMagic error at startup
2022/05/11 15:17:25 foobar.testing.local.lan: obtaining certificate: [foobar.testing.local.lan] Obtain: [foobar.testing.local.lan] creating new order: attempt 1: https://acme-v02.api.letsencrypt.org/acme/new-order: HTTP 400 urn:ietf:params:acme:error:rejectedIdentifier - Error creating new order :: Cannot issue for "foobar.testing.local.lan": Domain name does not end with a valid public suffix (TLD) (ca=https://acme-v02.api.letsencrypt.org/directory)
2022/05/11 15:17:35 http: TLS handshake error from no certificate available for 'foobar.testing.local.lan'

However, I was still able to connect to the tunnel and it worked as it should have, assuming because it’s Server HTTPS terminated. Checking the certificate details in firefox I can see the certificate was issued by my CA as I expected.

However, if I go through the whole process again but set it to Client HTTPS terminated, it does not work. I get the same (or a similar) error on the client side. So I think what you’ve done is working for server-terminated tunnels, but client-terminated tunnels are still trying to go to letsencrypt.

By the way, once this is working this is going to be amazing for my home network. Right now I’m using traefik but it’s very docker-centric, which is slightly problematic because 1) I’m trying to migrate a lot of stuff to rootless podman and the docker socket isn’t an option there and 2) some of my services are non-containerized anyway. I’ve been doing it with manually writing rules but it’s going to be so much easier to manage with boringproxy.

Ah of course. This is due to some duplication between the server and client code and I forgot to update the client as well. It’s done now, can you try again?

1 Like

Yeah, it worked! I tried it successfully with both client- and server-terminated configurations. I did not see any problems!

Nice! Thanks for testing. I’ve merged it into the master branch and it will go into the next release. Unfortunately that might be a while so you’ll need to use the master builds until then:


1 Like

Any idea when that next release will be?

Hey @mmguero, haven’t made much time for boringproxy this summer, but I’m planning to make a new release soon.

No problem! It’s easy enough to build from source anyway, just curious.