Proxy - Squid listening ports, dc2-a-vcprx001

category: solutionz/proxy · date: 2019-12-31 · updated: 2026-10-03 · author: LALA

Proxy Solution · Config document · referenced from Squid with SSL interception

noteBoth lines are printed without a comment sign, so as printed both were active. Both name port 3128 without an address; that two listeners on the same port and the same addresses cannot both bind is my understanding of socket binding, not something the notes or a Squid document state, and how Squid ran with both lines the notes do not say. Nothing else of the production squid.conf is in them.

The two lines of /etc/squid/squid.conf on the datacenter 2 proxy that carry ssl-bump, as grep printed them at the start of the certificate renewal (the note is filed under 2018; its text carries no date), to see which certificate and key the interception used. Apart from the file names they are the same two lines as on dc1-a-vcprx001, see Listening ports of dc1-a-vcprx001. The renewal and the SELinux problem that followed it are in Certificate renewal and SELinux and client trust.

Item	Value
Host	`dc2-a-vcprx001.adm.example.net`, RHEL 7.5
Run as	`root`, reads only
File	`/etc/squid/squid.conf`; the certificate and key under `/etc/ssl/squid/`
Certificate at the time	`dc2-a-vcprx001_2.crt`, valid until 27 April 2019
Software version	Squid 3.5 (the RHEL 7.5 package, `squid-3.5.20-12.el7`; the notes print no version)

The listing

bash

$ cat /etc/squid/squid.conf | grep ssl-bump

output 2 lines

http_port 3128 ssl-bump cert=/etc/ssl/squid/dc2-a-vcprx001_2.crt key=/etc/ssl/squid/dc2-a-vcprx001_2.key generate-host-certificates=on version=1 options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
https_port 3128 cert=/etc/ssl/squid/dc2-a-vcprx001_2.crt key=/etc/ssl/squid/dc2-a-vcprx001_2.key ssl-bump intercept generate-host-certificates=on version=1 options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE

The options

What each option does is my reading of the Squid 3.5 http_port and https_port documentation; the notes hold the lines and nothing about why they were written this way.

Option	On	Meaning
`http_port 3128`	first line	A forward-proxy listener on every address of the host, port 3128; clients send requests and `CONNECT` tunnels to it. The lab bound it to the internal address, this line does not
`https_port 3128`	second line	A listener that speaks TLS itself on port 3128, the same port as the first line
`ssl-bump`	both	SSL interception is on for connections through this port
`cert=…_2.crt`	both	The self-signed certificate that signs the generated host certificates and that the servers trust as a CA
`key=…_2.key`	both	Its private key; the `_2` suffix is how this host's files were named, differently from datacenter 1's `crt_1` and `private_1`. The key was kept at the renewal
`generate-host-certificates=on`	both	Squid generates a certificate for every bumped origin server, through `ssl_crtd` and the cache `/var/lib/ssl_db`
`intercept`	second line	The port expects connections redirected to it by NAT, not explicit proxy requests. No firewalld rule in the notes redirects anything to it
`version=1`	both	The TLS version selector of Squid 3.5, where `1` means automatic, the default; the notes do not say why it was written out
`options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE`	both	OpenSSL options: refuse SSLv2 and SSLv3, use a fresh Diffie-Hellman key per handshake. The notes do not say why these three

The two production hosts name their certificate files differently, <fqdn>.crt_1 and <fqdn>.private_1 in datacenter 1 against <host>_2.crt and <host>_2.key here, which suggests the two files were written by hand rather than by one template; the notes do not say. The lab line, for comparison, is in squid.conf of the lab.

Checked against Squid 7.7

As built	Today
Squid 3.5 from RHEL 7.5 (`squid-3.5.20-12.el7`)	Squid 7.7 (August 2026) is the only supported series; RHEL 8 ships 4.15, RHEL 9 5.5, RHEL 10 6.10. RHEL 7 left maintenance support on 2024-06-30
`cert=`, `key=`	Spelled `tls-cert=` and `tls-key=` since Squid 4; the old spellings are still accepted without a warning. On `https_port` the certificate option is mandatory
`generate-host-certificates=on`	The default since Squid 4; the option is redundant but harmless. Squid 7.7 adds that the first `tls-cert=` "must be a CA certificate capable of signing the automatically generated certificates"
`version=1`	In 3.5.20 `1` meant "automatic (default)", so the option restated the default. Squid 4 removed `version=` in favour of `tls-min-version=1.N` and `tls-options=`; 7.7 still parses it but logs "WARNING: UPGRADE: SSL version= is deprecated" and ignores the values 0 to 2
`options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE`	Squid 4 removed every SSLv2 setting, SSLv2 is forced off: `NO_SSLv2` now logs "ERROR: Unknown TLS option NO_SSLv2". `NO_SSLv3` and `SINGLE_DH_USE` are unchanged. The modern way to limit protocols is `tls-min-version=1.2`
`intercept` on `https_port`	Unchanged: "Support for IP-Layer NAT interception delivering traffic to this Squid port", and `ssl_bump` is consulted "when a CONNECT request is received on an http_port (or a new connection is intercepted at an https_port)"
Certificate made with `openssl x509 -req -signkey`	OpenSSL 3 renamed `-signkey` to `-key`, keeping the alias; a certificate made this way without `-extfile` carries no `basicConstraints`, so it is not a CA certificate in the sense Squid 7.7 now documents

Carried to Squid 7.7 as written, the first line would start with two log entries, a deprecation warning for version= and an error for NO_SSLv2, and lose nothing else; written today it would read tls-cert=… tls-key=… tls-min-version=1.2 options=SINGLE_DH_USE. The question of the second line does not depend on the version: two listeners on the same port with no address, which, as I understand socket binding, no release changes; how Squid ran with both the notes do not say.