Why is a certificate needed for squid reverse https?
Damned last edited by
I currently have alot of websites on different servers behind one public IP. All running on different ports in order to be NATed.
I recently discovered letsencrypt and have started using https. It's chaos however and I can never seem to remember what service runs on what port.
So I asked google what to do. Google told me I needed a reverse proxy.
However, the concept of reverse proxy does not work like I thought it worked.
In my world it is a fairly simple concept. Similiar to vhosts in Apache or NAT in pfsense itself:
So with this fundamental knowledge I thought it would be a piece of cake. I installed squid, went to the reverse proxy setting. Enabled it, and immediately got some errors:
The following input errors were detected: 'Reverse HTTPS port' must contain a port number higher than net.inet.ip.portrange.reservedhigh sysctl value(1023). To listen on low ports, change portrange.reservedhigh sysctl value to 0 in System: Advanced: System Tunables and restart Squid daemon. A valid certificate for the external interface must be selected when 'HTTPS Reverse Proxy' is enabled.
The highport thing, I think I've come to understand(well, accept) I need to create a rule, and it is first then when it gets forwarded to localhost on a specific port that squid does stuffs. Because for some reason squid can't see it otherwise. Fine.
Then where I really get stuck is the certificate-part.
I only want to forward to the correct web-server on my internal network. That server itself has a certificate I installed from letsencrypt. Why do squid require this? Installing certificates on pfsense is a bit over my head. But I still don't see why I'd need one.
Could someone please explain why stuff don't work like I want it to work?
JoeFjell last edited by
I wonder that my self. So if there is anyone out there that can tell us WHY??
doktornotor Banned last edited by
The TLS cert= option is mandatory on HTTPS ports.
And in general - do yourself a favour and use haproxy instead.
kpa last edited by
A slightly longer answer is that any SSL/TLS endpoint that is going to decrypt and authenticate incoming HTTPS connections MUST have a certificate because it's the cryptographic identification and authentication of a peer. If an SSL/TLS server you're connecting to claims to be 'www.example.tld' it must present a certificate (preferably signed by a trusted third party so it verifies correctly) with a CN (common name) 'www.example.tld', otherwise the SSL/TLS handshake will be aborted if the server can not present such certificate.