Squid Proxy Server

Create directories for certificates:

/usr/local/etc/squid/certs/janssen1.ddns.net

Enable SSH in jail for passing certificates from other VMs and jails over to the Squid Server.

Use SCP for passing certificates over:

scp -r /etc/letsencrypt/live/* sam@192.168.1.153:/home/sam/janssen1.ddns.net/

You then have to login to the Squid Server, change to root and copy the domain folder containing the certificates to /usr/local/etc/squid/certs.

Squid requires tls-cert=X should point to a PEM format file containing the certificate, private key, and any required intermediate CA certificate(s) for one domain.

Combine them into a single file like this:

cat ispconfig.ddns.net.key ispconfig.ddns.net.cer fullchain.cer > ispconfig.ddns.net.bundle.pem

After spending weeks trying to configure Squid for multiple site reverse proxy on the same public IP, the following conclusions have been reached.

Squid cannot handle multiple site reverse proxy on the same public IP (SNI)
GluTLS was added as per the example here: https://wiki.squid-cache.org/ConfigExamples/Reverse/HttpsVirtualHosting, but Squid continued to log the following warnings: "ERROR: OpenSSL does not support multiple server certificates. Ignoring additional cert= parameters." when using multiple origin SSL sites with certificates.

1. Squid was configured to accept encrypted connections on 443, connect to the origin server using encrypted connection on 443, respond back to the proxy using encrypted connection on 443 which the proxy then sent back to the client using encrypted connection on 443.
2. Squid was configured for reverse offloading. Meaning that Squid accepts connections on SSL 443 then reverse proxies to an origin server using port 80 - so encrypted when the client connects, unencrypted when passing to server behind proxy, unencrypted when the site responds to the proxy then encrypted again when the proxy passes back to the client.

Both above worked well until adding a second origin website using encrypted connection on 443 / additional certificates.

Internet lookups trying to the GnuTLS working state that GnuTLS is experimental:

Based on the documentation and release notes for Squid, GnuTLS support in Squid has historically been considered "experimental" and limited compared to OpenSSL, particularly regarding advanced TLS features.
mirror.ihost.md
mirror.ihost.md

While GnuTLS was added as an alternative to OpenSSL to avoid licensing issues, the following factors prevent full support for multiple SSL sites (using SNI) when using GnuTLS:

SSL-Bump/Dynamic Certificate Generation Lack: The primary mechanism in Squid for managing multiple SSL sites on one IP (SSL-Bump) requires dynamic certificate generation. This feature is not supported in GnuTLS builds, meaning Squid cannot generate unique certificates on-the-fly for different backend servers when using GnuTLS.

Experimental Status of GnuTLS: GnuTLS support was introduced in Squid 4.1, with release notes stating that it should be tested before use and that "many other less commonly used Squid TLS/SSL features" were missing.

Incomplete "Plumbing" for Reverse Proxy: Even with OpenSSL, using SNI to handle multiple reverse-proxy SSL certificates is complex. For GnuTLS, the "plumbing" to join necessary components together for SNI support has not been fully implemented.

The only other option is to use SslBump Peek and Splice, which looks as though you have to have your own Certificate Authority in Squid for creating certificates, and on top of that the client has to install the CA into their browser.

This is just not viable clients don't want this hastle.

Will continue to look at Squid for network features such as caching and security but for reverse proxy SNI moving to NGINX.