Squid Proxy - transparent proxy - Let's encrypt certificate (not working)

[cixhebus]

Hi there,

All is up to date.

I'm tuck to enable squid proxy (transparent) with a "Let's encrypt" certificate.
Everything was working nice.
- ACME plugin
- certificate creation/installation. No errors.

I can use my certificate in "system/settings/administration" and access opnsense with my domain.

Squid Proxy is UP (green play button) is I let the opensense "own signed" certificate but as soon as I use the "let's encrypt" one, I got "red square button".
If I click on start I get:

Segmentation fault
Starting squid.
CPU Usage: 0.009 seconds = 0.009 user + 0.000 sys
Maximum Resident Size: 65824 KB
Page faults with physical i/o: 0
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/squid.conf (depth 0)
2025/10/14 10:28:41| Starting Authentication on port 127.0.0.1:3128
2025/10/14 10:28:41| Disabling Authentication on port 127.0.0.1:3128 (interception enabled)
2025/10/14 10:28:41| Starting Authentication on port [::1]:3128
2025/10/14 10:28:41| Disabling Authentication on port [::1]:3128 (interception enabled)
2025/10/14 10:28:41| Starting Authentication on port 127.0.0.1:3129
2025/10/14 10:28:41| Disabling Authentication on port 127.0.0.1:3129 (interception enabled)
2025/10/14 10:28:41| Starting Authentication on port [::1]:3129
2025/10/14 10:28:41| Disabling Authentication on port [::1]:3129 (interception enabled)
2025/10/14 10:28:41| WARNING: empty ACL: acl bump_nobumpsites ssl::server_name "/usr/local/etc/squid/nobumpsites.acl"
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/pre-auth/40-snmp.conf (depth 1)
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/pre-auth/dummy.conf (depth 1)
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/pre-auth/parentproxy.conf (depth 1)
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/auth/dummy.conf (depth 1)
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/post-auth/dummy.conf (depth 1)
2025/10/14 10:28:41| WARNING: HTTP requires the use of Via
2025/10/14 10:28:41| WARNING: 'HTTP_port 127.0.0.1:3128' missing private key in '/var/squid/ssl/ca.pem'
2025/10/14 10:28:41| Not currently OK to rewrite swap log.
2025/10/14 10:28:41| storeDirWriteCleanLogs: Operation aborted.
2025/10/14 10:28:41| FATAL: No valid signing certificate configured for HTTP_port 127.0.0.1:3128
2025/10/14 10:28:41| Squid Cache (Version 6.14): Terminated abnormally.
/usr/local/etc/rc.d/squid: WARNING: failed to start squid

I search and I tried to understand but I'm completely stuck.
May be a wrong parameter on the certificate (I mean certificate is valid but Squid was waiting for a special value?).
I really don't know what to do.

Thanks a lot for any help

[Patrick M. Hausen]

You need to create your own private CA for transparent proxying of TLS. This part of the error messages hints at that:

Code Select Expand

2025/10/14 10:28:41| FATAL: No valid signing certificate configured for HTTP_port 127.0.0.1:3128

"signing certificate" == CA

HTH,
Patrick

[meyergru]

What you are trying is not going to work:

For a transparent proxy to work and break up TLS traffic, you need your own CA (i.e. self-signed certificate and corresponding private key) to create certificates on-the-fly while the traffic passes through the proxy. Actually, there are two TLS connections: one from your PC to the proxy and one from the proxy to the website. The first connection is where the problem arises: Your PC requests a website (e.g. "xyz.domain.com") and expects to get a valid (i.e. "trusted") certificate for it.

This is where the proxy creates a certificate for xyz.domain.com and presents it to your PC. In order to be trusted, the CA the certificate was created with has to be added to the trust store of the PC.

In practice, that means you can only use your own CA to do this and you have to make sure that each LAN client trusts that CA. Apart from that, there are certain sites that do not want to have their traffic inspected (like banks) and use mechanisms to enforce that this will not happen, like certificate pinning or at least, by having a CAA DNS entry that show the CAs which may hand out certificates for a specific domain in the first place - such that your own CA will never work. For each of these types of websites, you have to create an exemption list (aka SSL bump sites). Also, for some clients (like IoT devices), you cannot even change the trusted CA list, so those clients have to be exempt from inspecting traffic as well.

All in all, this is something that needs a lot of work to get going and therefore is mostly used in business environments. For most end-user applications, it is practically not feasible.

What is worse, is that you misinterpreted what a LetsEncrypt certificate is about: You can only have normal certificates (not CA certificates) signed by LetsEncrypt - and only if you can verify that you own that specific domain. So, you cannot make use of LetsEncrypt within a transparent proxy context at all, no matter how hard you may try.

[cixhebus]

You need to create your own private CA for transparent proxying of TLS. This part of the error messages hints at that:

Code Select Expand

2025/10/14 10:28:41| FATAL: No valid signing certificate configured for HTTP_port 127.0.0.1:3128

"signing certificate" == CA

HTH,
Patrick

Thanks .. I think I finally understand (a little ;-) )

[cixhebus]

What you are trying is not going to work:

For a transparent proxy to work and break up TLS traffic, you need your own CA (i.e. self-signed certificate and corresponding private key) to create certificates on-the-fly while the traffic passes through the proxy. Actually, there are two TLS connections: one from your PC to the proxy and one from the proxy to the website. The first connection is where the problem arises: Your PC requests a website (e.g. "xyz.domain.com") and expects to get a valid (i.e. "trusted") certificate for it.

This is where the proxy creates a certificate for xyz.domain.com and presents it to your PC. In order to be trusted, the CA the certificate was created with has to be added to the trust store of the PC.

In practice, that means you can only use your own CA to do this and you have to make sure that each LAN client trusts that CA. Apart from that, there are certain sites that do not want to have their traffic inspected (like banks) and use mechanisms to enforce that this will not happen, like certificate pinning or at least, by having a CAA DNS entry that show the CAs which may hand out certificates for a specific domain in the first place - such that your own CA will never work. For each of these types of websites, you have to create an exemption list (aka SSL bump sites). Also, for some clients (like IoT devices), you cannot even change the trusted CA list, so those clients have to be exempt from inspecting traffic as well.

All in all, this is something that needs a lot of work to get going and therefore is mostly used in business environments. For most end-user applications, it is practically not feasible.

What is worse, is that you misinterpreted what a LetsEncrypt certificate is about: You can only have normal certificates (not CA certificates) signed by LetsEncrypt - and only if you can verify that you own that specific domain. So, you cannot make use of LetsEncrypt within a transparent proxy context at all, no matter how hard you may try.

Ok thanks for your answer.
So I was confuse. I mixed the certificate who need to be used to access opnsense using my domain name (ACME plugin/let's encrypt certificate ... ) on a secure way and the CA needed by the proxy to run and manage https "inside opnsense"
Am I nearly right?

best regards