Let's Encrypt certificate for client to Squid proxy encryption

Good day,

I am trying to get Let's Encrypt to work with client to Squid Proxy SSL in a Kubernetes cluster. The proxy is used for testing. I have seen a few other Squid Proxy posts here. Not sure if this is an issue with the certificate or squid.

The problem is the proxy has one certificate presented, instead of the full chain. This works file with curl, but does not work with Node or OpenSSL. I checked the pem file on the squid node, and it has all the certificates, including the intermediate CAs. Also tried with the DST cross signed certificate.

Has anyone gotten a recent version of Squid to work with Let's Encrypt certificate for client to Squid proxy encryption?

My domain is: squid-proxy-ssl.ops2.cresta.ai:3128

I ran this command: openssl s_client -showcerts -connect squid-proxy-ssl.ops2.cresta.ai:3128

It produced this output:

> openssl s_client -showcerts -connect squid-proxy-ssl.ops2.cresta.ai:3128
CONNECTED(00000006)
depth=0 CN = squid-proxy.ops2.cresta.ai
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = squid-proxy.ops2.cresta.ai
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = squid-proxy.ops2.cresta.ai
verify return:1
---
Certificate chain
 0 s:CN = squid-proxy.ops2.cresta.ai
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct 13 15:54:37 2023 GMT; NotAfter: Jan 11 15:54:36 2024 GMT
-----BEGIN CERTIFICATE-----
<SNIP>
---
Server certificate
subject=CN = squid-proxy.ops2.cresta.ai
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1872 bytes and written 412 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
8060A7E901000000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:ssl/record/rec_layer_s3.c:304:

My web server is (include version): ubuntu/squid 4.10-20.04_beta and tried 5.6-22.10_beta

Squid configuration:

      https_port 3128 tls-cert=/certs/tls.crt tls-key=/certs/tls.key tls-cafile=/certs/tls.crt

The operating system my web server runs on is (include version): Ubuntu 22.10 or 20.04

My hosting provider, if applicable, is: AWS

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Kubernetes

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): cert-manager v1.13.1

Does not work with curl either

curl -I https://squid-proxy-ssl.ops2.cresta.ai:3128
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

I know nothing of squid but why doesn't it provide the intermediate chain? You say squid has them so maybe try asking on a squid forum.

3 Likes

Review the cert-manager docs and see if they provide a "fullchain" file.

OR

Perhaps this was a TYPO - these two are pointing to the same file:

tls-cert  =/certs/tls.crt
tls-cafile=/certs/tls.crt

[alligned to make it more noticeable]

3 Likes

Thanks! It does work for me. So that means this is some extra configuration, i.e. a CA added, on my machine.

curl -I https://squid-proxy-ssl.ops2.cresta.ai:3128
HTTP/1.1 400 Bad Request
Server: squid
Mime-Version: 1.0
Date: Mon, 23 Oct 2023 12:58:42 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3525
X-Squid-Error: ERR_INVALID_URL 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from squid-84864b79b7-5llhw
X-Cache-Lookup: NONE from squid-84864b79b7-5llhw:3129
Via: 1.1 squid-84864b79b7-5llhw (squid)
Connection: close

I don't see a chain file:

openssl s_client -connect squid-proxy-ssl.ops2.cresta.ai:3128 -showcerts
CONNECTED(00000003)
depth=0 CN = squid-proxy.ops2.cresta.ai
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = squid-proxy.ops2.cresta.ai
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = squid-proxy.ops2.cresta.ai
verify return:1
---
Certificate chain
 0 s:CN = squid-proxy.ops2.cresta.ai
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct 20 14:51:53 2023 GMT; NotAfter: Jan 18 14:51:52 2024 GMT
-----BEGIN CERTIFICATE-----
MIIFIDCCBAigAwIBAgISA4TH9FaUEFPaLQNUkF0xKPLZMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzEwMjAxNDUxNTNaFw0yNDAxMTgxNDUxNTJaMCUxIzAhBgNVBAMT
GnNxdWlkLXByb3h5Lm9wczIuY3Jlc3RhLmFpMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA0HWFRF+Tb3HM/w7z1UgefWT/KIyI2aHWEVrcukjd+P8UBtL0
V3qLdF0H3fMgMVIDrAXQivC2x4atJDu7ogrAkPcYDk8cYAKGOaD/acWvMKz3LzzL
gs8GAiZ3pt230ImiHueY+Aq97P6lAQPiawfes2RmCJFSMQtUipdtyy8OHDXPGjbH
8jgECiptGG24l+poCpFWuSnsxBs/mvd1Ncq0Bwf9Rq0OIIxQ2Zgn+NBugJ9IONjr
nggWY7uHciF3MLiUBTwW2dec3BCqbbut5dWt917CwEZDbQXQq5+fw7MW/zWYqk8j
tux4exZVrAagZ8HABJSUKIL/ax/YI6COAe8k7QIDAQABo4ICOzCCAjcwDgYDVR0P
AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMB
Af8EAjAAMB0GA1UdDgQWBBThAA6zEoTkRKih2jzDa6OKrb+XiDAfBgNVHSMEGDAW
gBQULrMXt1hWy65QCUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUH
MAGGFWh0dHA6Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3Iz
LmkubGVuY3Iub3JnLzBFBgNVHREEPjA8gh5zcXVpZC1wcm94eS1zc2wub3BzMi5j
cmVzdGEuYWmCGnNxdWlkLXByb3h5Lm9wczIuY3Jlc3RhLmFpMBMGA1UdIAQMMAow
CAYGZ4EMAQIBMIIBAwYKKwYBBAHWeQIEAgSB9ASB8QDvAHYAO1N3dT4tuYBOizBb
Bv5AO2fYT8P0x70ADS1yb+H61BcAAAGLTck1HQAABAMARzBFAiBaCwGhydN3UsUq
ybsT1iHjDxfJ1uFcp+ybKO119q0sEwIhAPvtAK4/5AOrr+d9EeemIq3b2iwLOx39
jZrsk9PrYR74AHUAdv+IPwq2+5VRwmHM9Ye6NLSkzbsp3GhCCp/mZ0xaOnQAAAGL
Tck1TwAABAMARjBEAiAsLRsYI0zgFaL/3hoc2n7ePqpBqtvbggiwIohzrqFI0gIg
J+u+tTRlvvOOixG/xjBcwp+bD1kkgqbJUV8mWu8qDT8wDQYJKoZIhvcNAQELBQAD
ggEBAFNciRqVmcriA+gI3JWROvRfY17Tp6hojiUX2Fh+QQewdKu4b4RZ7nhgHp3V
DT0+Fy5EvluakPV2oY/W4O7q7pVhm4o/Z70X8D1Tv3U5ReNlgg9y8urbHhdlPlfI
54hD4jzBhOy7/dabtd2xBoJFTPhFwSKHYvfQSFqKu4ulKZwS8u+kRL9NkWSLBlhQ
eITWZG2WjbNxNzQGqJ9XDzM1zDxYuATRmVxR7IqDkyJ1Xbnf+WWAIucgz0J6jvEx
It1Iv3GhFE136910mfYAyaVpJoTNuJ9w25ank0ILQBWZ+weReLHwag/QUJD0iRJD
JKA1bsBQA/IJQtzsms87cBadAG0=
-----END CERTIFICATE-----
---
Server certificate
subject=CN = squid-proxy.ops2.cresta.ai
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1872 bytes and written 412 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
3 Likes

Yes, that is a mistake, the tls-cafile is for client certificates. Removing the tls-cafile line does not fix the issues.

It is the full chain, I tried using the DST and ISRG certificates.

kubectl get secret cresta-cert-squid -ojsonpath='{.data.tls\.crt}' | base64 -D | certigo dump
** CERTIFICATE 1 **
Input Format: PEM
Valid: 2023-10-20 14:51 UTC to 2024-01-18 14:51 UTC
Subject:
	CN=squid-proxy.ops2.cresta.ai
Issuer:
	C=US, O=Let's Encrypt, CN=R3
DNS Names:
	squid-proxy-ssl.ops2.cresta.ai, squid-proxy.ops2.cresta.ai

** CERTIFICATE 2 **
Input Format: PEM
Valid: 2020-09-04 00:00 UTC to 2025-09-15 16:00 UTC
Subject:
	C=US, O=Let's Encrypt, CN=R3
Issuer:
	C=US, O=Internet Security Research Group, CN=ISRG Root X1

** CERTIFICATE 3 **
Input Format: PEM
Valid: 2021-01-20 19:14 UTC to 2024-09-30 18:14 UTC
Subject:
	C=US, O=Internet Security Research Group, CN=ISRG Root X1
Issuer:
	O=Digital Signature Trust Co., CN=DST Root CA X3

Well...
It is only serving the leaf cert.

3 Likes

Are these paths equal?:

3 Likes

Thanks so much for your help @rg305!

Yes, it is only the leaf cert :frowning: Might be due to usage of GnuTLS.

The .data.tls\.crt and tls-cert =/certs/tls.crt are equal, I have checked the pod filesystem itself to confirm.

The documentation says for Ubuntu squid, that uses GnuTLS, one can pass multiple tls-cert= for different domains. It only mentions intermediate CA certificates when using OpenSSL.

I have the feeling I need to build or find a container version of Squid that uses OpenSSL instead of GnuTLS. Looks like this email list archive confirms that!

P.S. There is already an Ubuntu bug report for the Squid OpenSSL container.

Documentation:

tls-cert=	Path to file containing an X.509 certificate (PEM format)
			to be used in the TLS handshake ServerHello.

			If this certificate is constrained by KeyUsage TLS
			feature it must allow HTTP server usage, along with
			any additional restrictions imposed by your choice
			of options= settings.

			When OpenSSL is used this file may also contain a
			chain of intermediate CA certificates to send in the
			TLS handshake.

			When GnuTLS is used this option (and any paired
			tls-key= option) may be repeated to load multiple
			certificates for different domains.

			Also, when generate-host-certificates=on is configured
			the first tls-cert= option must be a CA certificate
			capable of signing the automatically generated
			certificates.
2 Likes

You could always slap a proxy in from of [that proxy] - LOL

4 Likes

This is the solution I came up with. Just building a new image based on the Ubuntu image for Squid. But instead of using the Ubuntu package squid using the squid-openssl package.

It worked perfectly without any issues.

Dockerfile:

FROM ubuntu/squid:5.2-22.04_beta

RUN set -eux; \
	apt-get update; \
	DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
		squid-openssl; \
    rm -rf /var/lib/apt/lists/*; \
	/usr/sbin/squid --version
2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.