When using boringproxy on non standard ports (anything other than 80 & 443), the Let’s Encrypt service is not working, that’s understandable since “LetsEncrypt only supports HTTP/HTTPS ports 80/443”, but how do I install my own certificate to be used by the admin-domain?
I assume the path to the certificate file needs to be set somewhere, or the file needs to be placed in the correct sub folder of the cert-dir, but I am unable to figure out the correct path.
Can someone please assist
Similar issues have come up before.
I think the simplest way to solve your problem is to use a small tool I made for this situation:
Basically it lets you manually get certs, and stores them in the same format certmagic (the underlying ACME library used by boringproxy) uses.
I am curious though, why do you need to run boringproxy on non-standard ports? If you’re running behind another reverse proxy, can’t you let that server terminate HTTPS for you? Or did you try that and that’s where you hit the HTTP issues mentioned here?
I think the simplest way to solve your problem is to use a small tool I made for this situation
I will have a look at the tool thanks
I am curious though, why do you need to run boringproxy on non-standard ports? If you’re running behind another reverse proxy, can’t you let that server terminate HTTPS for you?
I ran into this issue while trying to set up a development/testing environment. I want to set up two local VM’s, one as a server and the other as a client, so that I can test new builds without having to deploy them on my cloud servers. I also wanted to set these up without the server being accessible from the internet. The problem however is that the server needs to be accessible from the internet to set up the certificate using Let’s Encrypt. Since Let’s Encrypt is automatically disabled when using non standard ports, I decided to use non standard ports with a self signed certificate, hoping that this would allow me to set up a boringproxy server with no open ports to the internet.
Or did you try that and that’s where you hit the HTTP issues mentioned here?
I ran into the issue when trying to access the admin server without any certificate. It might be useful to retain HTTP access to the admin domain to allow access to it from behind another proxy that handles SSL, but that sounds like an overcomplicated setup, might be useful in a load balancer setup, regardless, its outside of what I am currently trying to do.
For my application I wanted to do internal routing for testing purposes. But there could be some production applications for internal routing. Lets say I have two networks LAN & OPT, I don’t want to allow users on OPT to access devices on LAN, but LAN can access devices on OPT. If there is a single service running on a device in LAN that users from OPT needs to connect to.
I can open a port to allow traffic from OPT to LAN or I can use boringproxy create a tunnel from LAN to a device in OPT. Devices on OPT can then connect to the tunnel server and access the service hosted on LAN.
This might be far from the original idea, but should be possible
Gotcha. Let me know if
certgrabber ends up working for you.
One thing to keep in mind is boringproxy is definitely targeted towards making self-hosting easier and more accessible. There are already lots of tools out there for developers and power users. It’s why I hesitate adding features like load balancing. If someone is trying to run an app that requires load balancing, boringproxy probably isn’t the right tool for the job.
None of that may apply to your situation, just wanted to mention it.
I agree that boringproxy should be focused on making self-hosting easier. Since the non-standard ports feature is included, I wanted to test it and see how it can be implemented. But I agree that this is an advanced feature with limited uses for simple self-hosting.
I did manage to get my own certificates working on boringproxy. I managed to do this by creating my own ACME CA. This requires some changes to the boringproxy code; if you want to have a look at the code, check out the branch WGrobler:custom-ca. The setting up of a private CA is far outside the scope of boringproxy, I decided to do it since I can use it for other development work as well, its more work than using
certgrabber but it allows me to create certificates for non TLDs like boringproxy.lan. I don’t think this is something to be included as a standard feature.
That sounds interesting, but I agree probably out of scope. The link doesn’t seem to be working. Would you mind making a PR so I can see the diff in GitHub’s UI?
Apologies for the broken link, I merged it into my master branch and deleted the branch afterwards forgetting that I linked to it here. The link is restored.
I created a PR, this code (or a variation of it) can be integrated into master since it allows for integration of any ACME CA not just private servers