Boring Proxy trying to obtain SSL cert even with -behind-proxy -allow-http

I’m running Boring Proxy behind another reverse proxy, Caddy. Since Caddy isn’t able to pass through raw TCP traffic, I can’t let BP handle all of the SSL, so I’m terminating on Caddy and running BP over HTTP. However, when I try to open a new tunnel, even with -behind-proxy -allow-http on server, BP tries to obtain an SSL cert and fails with

obtaining certificate: [] Obtain: [] solving challenges: : no solvers available for remaining challenges (configured=[tls-alpn-01] offered=[http-01 dns-01 tls-alpn-01] remaining=[http-01 dns-01])

Is there a way to tell BP client not to try to get an SSL cert? I tried all TLS Termination options in the Web UI, nothing helped.

Hey @jirian, thanks for the report. Can you try running boringproxy on a different port than 80/443? It shouldn’t be trying to get any certs unless you’re using the default ports, otherwise that’s definitely a bug.

We might want to consider making this a more explicit option rather than inferring from port, but let’s make sure that’s the problem first.

I’m running it on different ports already, I’m running the server with server -http-port 8001 -https-port 8002 -admin-domain bp.test.com -behind-proxy -allow-http and the client with client -server bp.test.com -token xyz -client-name test

I’m also running both on version v0.9.1

I found a likely culprit. Can you double check that TLS Termination Server HTTPS does not work?

Also, can you verify that the following error message is printed out when you run the server?

WARNING: LetsEncrypt only supports HTTP/HTTPS ports 80/443. You are using 8001/8002. Disabling automatic certificate management

The message (warning) does get printed out on the server side. Even with Server TLS termination, upon loading the tunneled URL, I get obtaining certificate: [] Obtain: [] solving challenges: : no solvers available for remaining challenges (configured=[tls-alpn-01] offered=[http-01 dns-01 tls-alpn-01] remaining=[http-01 dns-01]) (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/123/456) (ca=https://acme-staging-v02.api.letsencrypt.org/directory) on the client side console.

Ok so I’m pretty sure I’ve identified the problem. I’m able to reproduce the behavior even without changing the ports or running behind another reverse proxy.

However, I don’t think that error message itself is too much of a problem unless it triggers Let’s Encrypt rate limiting. Ideally it shouldn’t be trying to get the cert in the first place, but it doesn’t need the cert anyway since Caddy is handling that.

I think the tunnel should still work without the cert. If it doesn’t, there’s probably another issue. Did you try all the TLS Terminations, ignoring the error message?

I see, ignoring the message, the tunnel eventually does get connected and I can use it. Yay! It works for me with Server HTTPS for sure, and I suspect it would work with Passthrough also. Thanks for the help!

1 Like

Awesome, that means the bug is probably in the spot I identified. I’ll open an issue to fix it. Thanks for the report!

For reference, issue is here: https://github.com/boringproxy/boringproxy/issues/178.