Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Squid Reverse Proxy and LetsEncrypt - Help a noob out?

    Scheduled Pinned Locked Moved Cache/Proxy
    12 Posts 4 Posters 7.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N
      Nerumph
      last edited by

      [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.12

      So 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:

      1. 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?
      2. 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 "

      1 Reply Last reply Reply Quote 0
      • N
        Nerumph
        last edited by

        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).

        1 Reply Last reply Reply Quote 0
        • N
          Nerumph
          last edited by

          Bump No. 1

          1 Reply Last reply Reply Quote 0
          • E
            elmo_
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • dragoangelD
              dragoangel
              last edited by

              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

              Latest stable pfSense on 2x XG-7100 and 1x Intel Xeon Server, running mutiWAN, he.net IPv6, pfBlockerNG-devel, HAProxy-devel, Syslog-ng, Zabbix-agent, OpenVPN, IPsec site-to-site, DNS-over-TLS...
              Unifi AP-AC-LR with EAP RADIUS, US-24

              1 Reply Last reply Reply Quote 0
              • P
                pollardhimself
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • dragoangelD
                  dragoangel
                  last edited by

                  you must use 80 port and http, why you all guys try use ssl when you haven't it?

                  Latest stable pfSense on 2x XG-7100 and 1x Intel Xeon Server, running mutiWAN, he.net IPv6, pfBlockerNG-devel, HAProxy-devel, Syslog-ng, Zabbix-agent, OpenVPN, IPsec site-to-site, DNS-over-TLS...
                  Unifi AP-AC-LR with EAP RADIUS, US-24

                  1 Reply Last reply Reply Quote 0
                  • P
                    pollardhimself
                    last edited by

                    My cert is verified
                    Still running 2.1.5 planning on upgrading soon

                    Since 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?

                    CAs.PNG
                    CAs.PNG_thumb
                    Cert.PNG
                    Cert.PNG_thumb
                    NAT.PNG
                    NAT.PNG_thumb
                    Squid1.PNG
                    Squid1.PNG_thumb
                    Squid2.PNG
                    Squid2.PNG_thumb
                    Squid3.PNG
                    Squid3.PNG_thumb

                    1 Reply Last reply Reply Quote 0
                    • dragoangelD
                      dragoangel
                      last edited by

                      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.

                      Latest stable pfSense on 2x XG-7100 and 1x Intel Xeon Server, running mutiWAN, he.net IPv6, pfBlockerNG-devel, HAProxy-devel, Syslog-ng, Zabbix-agent, OpenVPN, IPsec site-to-site, DNS-over-TLS...
                      Unifi AP-AC-LR with EAP RADIUS, US-24

                      1 Reply Last reply Reply Quote 0
                      • P
                        pollardhimself
                        last edited by

                        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"

                        1 Reply Last reply Reply Quote 0
                        • dragoangelD
                          dragoangel
                          last edited by

                          I really do not understand want at end…

                          Latest stable pfSense on 2x XG-7100 and 1x Intel Xeon Server, running mutiWAN, he.net IPv6, pfBlockerNG-devel, HAProxy-devel, Syslog-ng, Zabbix-agent, OpenVPN, IPsec site-to-site, DNS-over-TLS...
                          Unifi AP-AC-LR with EAP RADIUS, US-24

                          1 Reply Last reply Reply Quote 0
                          • N
                            Nerumph
                            last edited by

                            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?

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.