I'm using 4.13 with libressl 3.2.2 and SSL bumps. Most of the time
it works (e.g. google). Some other time it get me back a 'fake untrusted'
certificate (like CN=Not trusted by \"proxy.proxind.it\") and this of
course gives user issues.
In the logs I see lines like
2020-11-11 12:47:59.314124500 L 290 192.168.2.102 NONE/200 0 CONNECT www.selcdn.ru:443 - HIER_DIRECT/18.104.22.168 - /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL RSA CA 2018 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY@depth=2
which suggest something missing in the certificate store.
However testing with openssl verify the certificate from the server
(extracted with a browser *outside* the squid network) it verifies OK.
The certs.pem file is the same (I checked:P) so I don't get why it
should fail. In fact I ensured it with tls_outgoing_options cafile=/var/lib/openssl/certs.pem
Any ideas on how to solve/troubleshoot/workaround the problem?
On Wed, Nov 11, 2020 at 03:13:19PM +0100, Dieter Bloms wrote:
> for me it looks like the server doesn't deliver the intermdeiate
> certificate and your squid proxy doesn't download this certificate
Well, squid couln't download even if wanted if it isn't supplied by the
server. AFAIK there is no field in the certificate to hold an url to
download the signer one. In fact in the past I had to put some
intermediates in the cert store (OK, not great, not recommended, but at
least it works).
That aside, if I save the certificate as a PEM from the browser (*only*
the certificate, not the whole chain) and I do an openssl verify on it
it validates, so in the store there are all the certs needed to verify
it. I even tried doing it as the squid user in case of permission
For some reason squid doesn't like *some* certificates. And I don't
think that so many sites anyway send incomplete chains.
On Wed, Nov 11, 2020 at 11:45:26AM -0500, Alex Rousskov wrote:
> On 11/11/20 6:56 AM, Lorenzo Marcantonio wrote:
> > I'm using 4.13 with libressl 3.2.2 and SSL bumps.
> FYI: Libressl-based builds are not officially supported. I do not know
> whether libressl is a factor here.
Uhm. That could be. However I think that mixing openssl and libressl
could be an even bigger can of worm, given that they have the same soname.