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.
