[squid-users] Re: ssl-bumping certificate validation (on OSX)

lsof (no strace on OSX) doesn't indicate any certificate store files being
opened either for the openssl command line tool, or for squid. I do notice
that squid (or ssl_crtd) seems to be downloading root certs itself, this
shows up in access.log whenever I browse to certain SSL sites:

1366295696.233 217 127.0.0.1 TCP_MISS/200 2586 GET
http://crl.geotrust.com/crls/secureca.crl - HIER_DIRECT/199.7.55.190
application/pkix-crl
1366295740.015 134 127.0.0.1 TCP_REFRESH_UNMODIFIED/200 2547 GET
http://crl.geotrust.com/crls/secureca.crl - HIER_DIRECT/199.7.55.190
application/pkix-crl
1366295766.345 0 127.0.0.1 NONE_ABORTED/000 0 GET
http://svrintl-crl.verisign.com/SVRIntl.crl - HIER_NONE/- -
1366295766.345 0 127.0.0.1 NONE_ABORTED/000 0 GET
http://crl.verisign.com/pca3.crl - HIER_NONE/- -
1366295766.949 603 127.0.0.1 TCP_MISS/200 1351 GET
http://crl.verisign.com/pca3.crl - HIER_DIRECT/199.7.55.190
application/pkix-crl
1366295767.085 741 127.0.0.1 TCP_MISS/200 48972 GET
http://svrintl-crl.verisign.com/SVRIntl.crl - HIER_DIRECT/199.7.55.190
application/pkix-crl

I assume this means ssl_crtd is downloading and storing the certificates
into its own cache folder.

otool (no ldd on OSX) shows that the binary I have been building is not in
fact linked statically:

../sbin/squid:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
159.1.0)
        /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version
44.0.0)
        /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current
version 44.0.0)
        /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
(compatibility version 5.0.0, current version 6.0.0)
        /usr/lib/libltdl.7.dylib (compatibility version 10.0.0, current version
10.2.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
52.0.0)

../libexec/ssl_crtd:
        /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version
44.0.0)
        /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current
version 44.0.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
52.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
159.1.0)

although, all of those .dylibs are present on both the functional and
problematic machines. There doesn't seem to be any difference in the runtime
configurations for openssl (in fact I don't think openssl has a config file
as such), so hopefully a statically linked build would help. --enable-static
doesn't seem to do this, though, and I have ensured that libssl.a is present
on the building machine. LDFLAGS is set to /usr/local/ssl/lib, to ensure
libssl.a can be found, and LIBS is set to -lssl. Configuration and build
outputs don't mention anything about openssl/libssl, so I am out of ideas as
to why it's choosing to link dynamically.

Any ideas?

Jeff

--
View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/ssl-bumping-certificate-validation-on-OSX-tp4659066p4659561.html
Sent from the Squid - Users mailing list archive at Nabble.com.