Hi,
I've been trying, with mixed success, to package a version of squid for
redistribution on OSX with ssl-bumping for the purpose of restricting access
to certain URLs.
On some test machines, everything works perfectly - SSL connections are
decrypted, and reencrypted with a generated cert signed by my testCA. On
others, an untrusted cert is returned, issued by 'Not trusted by "testCA" '.
Previously I encountered a squid error of
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY, is this the same behaviour
except handled differently, as I am now using squid 3.3.3 with
bump-server-first?
I understand that openssl is used as a library, and that the command line
binary is irrelevant to squid for validation. Thus to improve portability, I
configured with the following flags:
'--enable-ssl' '--enable-static' '--with-openssl=/usr/include/openssl'
'--enable-strict-error-checking=no' '--enable-ssl_crtd'
Am I correct in believing that this should be linking against openssl
statically, and allowing the squid binary to be independent of the system
version of openssl? Or, are libraries in some default location being used?
Perhaps this isn't an openssl problem at all? Combing the logs on the
problematic test machines has not yielded anything useful/relevant, though I
can see that the original CA files are being downloaded from Verisign etc.
The default command line openssl binary on the machine appears to validate
certificates correctly, for example "openssl s_client -connect
google.com:443" will result in "Verify return code: 0 (ok)"
Any pointers appreciated!
Received on Tue Mar 19 2013 - 16:29:59 MDT
This archive was generated by hypermail 2.2.0 : Wed Mar 20 2013 - 12:00:06 MDT