Squid Reverse Proxy and LetsEncrypt - Help a noob out?
-
[First off, please feel free to move this into another forum board if this is the wrong place for this.]
Ok guys. After taking a bit of a breather from the whole homelab web configuration while instead focusing on a few game servers, I am back with yet another SQUID RP assistance request, this time with less stupidity of what a RP actually is! Woo!
Lessons learned from my previous post: RP is not a catch all redirection tool for every protocol; only HTTP/HTTPS. Awesome! It just so happens, that I am looking to forward HTTPS traffic out to the world through pfsense now. The catch though, is I will have to utilize Let'sEncrypt certificates to do so.
Basically, I am in need of some sort of tutorial on how to tunnel https traffic from multiple sources, through squidRP, and out to the network without losing TLS security in the process.
urlrequest: https://sub.domain.com –-------V sub.domain.com@192.168.1.10
urlrequest: https://subsub.domain.com -----> Pfsense Reverse Proxy -----> subsub.domain.com@192.168.1.11
urlrequest: https://subv3.domain.com ------^ subv3.domain.com@192.168.1.12So that's a basic network overview of what a RP does right? Now when it comes to certificates, in my mind, Squid basically intercepts the encrypted packets by acting as a "man in the middle" of sorts, intercepting the certificate by having the private key of said certificate, then repackages the information packet after doing the required "routing" that RP does. I believe, therefore, that in order to setup the system that I am devising, I would need to verify both the central PFSense box with LetsEncrypt (aka ACME Certificates) as well as the server instances I am wishing to utilize as web hosts.
So... questions now are:
- How does one go about setting up this encryption chain through the network? I already know that you would need ACME on PFSense and certbot on whichever webhost I am setting up. But just how do these communicate with eachother in the RP hierarchy?
- How do I set up the RP to forward https traffic to the ACME daemon on PFSense? Right now, upon attempting to verify my cert information, I come up with an error of:
"[domain].com:Verify error:Incorrect validation certificate for tls-sni-01 challenge. Requested 1f67d9d9124368539bcbe489de7c03b9.28cb710e0ebb36121c6f1cb0077c3b67.acme.invalid from xx.xx.xx.xx:443. Received 3 certificate(s), first certificate had names "
-
Any advice here? Still really looking to get this up and operational; especially now that I'm trying to get Collabora integration on my server soon (a service that requires reverse proxy services enabled).
-
Bump No. 1
-
What I did, was to setup a single certificate with multiple subject alternative names in it for your backend systems. You will then assign this certificate to your reverse squid configuration in the "Reverse SSL Certificate"
section.
I hope that helps. -
Hello - yours problem that you try to receive certificate from LetsEncrypt on port 443 where now you havent valid certificate!
You need do this on 80 port and on pure HTTP
Look:
"[domain].com: Verify error:Incorrect validation certificate for tls-sni-01 challenge. Requested 1f67d9d9124368539bcbe489de7c03b9.28cb710e0ebb36121c6f1cb0077c3b67.acme.invalid from xx.xx.xx.xx:443. Received 3 certificate(s), first certificate had names "
P.S.:- you must check box Disable webConfigurator redirect rule on System=>Advanced=>Admin Access because it occupies 80 port that you need
- you must open 80 and 443 ports on firewall on that WAN interface you need to accept requests
But how I figure out now ACME.sh LetsEncrypt packet with version 0.1.20 have bug and cat receive new certificate from any http method on pfSense, only from DNS method. But after you receive cert you can succesful use http or https method to renew your certificates. You can read my research at https://forum.pfsense.org/index.php?topic=138366.msg757153#msg757153
-
Had any luck working on this exact scenario now. I validated my cert using my external web host then redirected it back to my external IP but I get a ERR_SSL_PROTOCOL_ERROR now.
-
you must use 80 port and http, why you all guys try use ssl when you haven't it?
-
My cert is verified
Still running 2.1.5 planning on upgrading soonSince I'm using my hvac.domain.com cert for the reverse ssl certificate how would I get it working for main.domain.com? Am I going to need a wildcard certificate to get it working?
-
why you write about your Squid Reverse Proxy in post about Squid Reverse Proxy+LetsEncrypt?
P.S. Yes you need or another cert, or wildcard, or multidomain cert. -
Because I'm using letsencrypt I just found one of my issues was the CSR created by my app was messed up. I let letsencrypt create it and now its working externally when just nat port 443 open. Still havent add any luck getting it to reverse proxy 443 with the updated cert.
Can you use multiple certs with the reverse proxy since you have to define one for the reverse proxy? Or do I just need to use a wildcard there and internally use the specific name cert i.e. "hvac.domain.com"
-
I really do not understand want at end…
-
Ok, so I think I'm finally understanding where I was messing up in my squid RP logic. I was under the impression that each web server would be encapsulating their traffic into their own Let's Encrypt certificates, then forwarding that traffic to the RP server, which would then encapsulate it with its own certificate.
So… with that said, I now have another issue, which is that at least a couple of my services (OpenCloud being the main one) have https, server checks inbedded in the system, and will throw errors if not encrypted properly. Is there any way to set an end-to-end encryption path for apps like this, and really for any other http service I may have running? (I don't really like the idea of my passwords floating around on my lan between servers that much). Is there a setting in Squid Reverse Proxy for an upstream, either self-generated or squid generated certificate?