Thanks for this Amos....I will try and do more experimenting this week with more results.
James On Tue, 2015-05-26 at 19:46 +1200, Amos Jeffries wrote: > On 26/05/2015 4:26 a.m., James Lay wrote: > > So following advice and instructions on this page: > > > > http://wiki.squid-cache.org/Features/DynamicSslCert > > > > I have set up my lab with explicit proxy by exporting http_proxy and > > https_proxy. After creating the self-signed root CA certificate above > > and creating the .der file for the client, here are my results: > > > > From the squid side: > > 2015/05/25 10:02:20.161| Using certificate > > in /opt/etc/squid/certs/SquidCA.pem > > 2015/05/25 10:02:20.170| support.cc(1743) readSslX509CertificatesChain: > > Certificate is self-signed, will not be chained > > I get the below when I don't specify a CA with curl, otherwise when I do > > I get no error: > > 2015/05/25 09:21:02.229| Error negotiating SSL connection on FD 12: > > error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca (1/0) > > If that error is displayed by Squid about the clients connection. Then I > believe it means the client is attempting to perform TLS authentication > to Squid using the CA you installed there. Which is not possible as the > CA is supposed to make the client trust Squid generated certs, not the > other way around. > > > > > > And from the client side: > > root@kali:~/test# curl -v https://mail.slave-tothe-box.net > > * About to connect() to proxy 192.168.1.9 port 3129 (#0) > > * Trying 192.168.1.9... > > * connected > > * Connected to 192.168.1.9 (192.168.1.9) port 3129 (#0) > > * Establish HTTP proxy tunnel to mail.slave-tothe-box.net:443 > >> CONNECT mail.slave-tothe-box.net:443 HTTP/1.1 > >> Host: mail.slave-tothe-box.net:443 > >> User-Agent: curl/7.26.0 > >> Proxy-Connection: Keep-Alive > >> > > * Easy mode waiting response from proxy CONNECT > > < HTTP/1.1 200 Connection established > > < > > * Proxy replied OK to CONNECT request > > * successfully set certificate verify locations: > > * CAfile: none > > CApath: /etc/ssl/certs > > * SSLv3, TLS handshake, Client hello (1): > > * SSLv3, TLS handshake, Server hello (2): > > * SSLv3, TLS handshake, CERT (11): > > * SSLv3, TLS alert, Server hello (2): > > * SSL certificate problem: self signed certificate in certificate chain > > * Closing connection #0 > > > > And testing with specifying the .der file: > > root@kali:~/test# curl --cacert /etc/ssl/certs/SquidCA.der -v > > https://mail.slave-tothe-box.net > > * About to connect() to proxy 192.168.1.9 port 3129 (#0) > > * Trying 192.168.1.9... > > * connected > > * Connected to 192.168.1.9 (192.168.1.9) port 3129 (#0) > > * Establish HTTP proxy tunnel to mail.slave-tothe-box.net:443 > >> CONNECT mail.slave-tothe-box.net:443 HTTP/1.1 > >> Host: mail.slave-tothe-box.net:443 > >> User-Agent: curl/7.26.0 > >> Proxy-Connection: Keep-Alive > >> > > * Easy mode waiting response from proxy CONNECT > > < HTTP/1.1 200 Connection established > > < > > * Proxy replied OK to CONNECT request > > * error setting certificate verify locations: > > CAfile: /etc/ssl/certs/SquidCA.der > > CApath: /etc/ssl/certs > > > > * Closing connection #0 > > curl: (77) error setting certificate verify locations: > > CAfile: /etc/ssl/certs/SquidCA.der > > CApath: /etc/ssl/certs > > > > > > I can confirm that the server is using a bona-fide certificate issued > > from StartSSL and works, so at this point I'm open to suggestions. > > Thank you. > > curl is complaining that the CA chain for the Squid-generted cert has a > self-signed CA. This is expected and desired behaviour if the > self-signed CA was sent by Squid. > > The errors only occur when the self-signed CA is not sent by Squid, but > using the one installed on the client. > > > For that I believe you need to configure Squid to sign/generate using > the intermediate certificate. The self-signed root CA not configured in > Squid at all. > > Like so: > > A) > client Trust DB installed with self-signed root CA > > squid.conf cert= configured with intermediary CA certificate > > squid.conf cafile= configured with any other intermediary CA > certificates (in order back to root CA, but excluding it). > > Squid generates per-connection certificate > > OR: > > B) > client Trust DB installed with self-signed root CA > > squid.conf cert= configured with self-signed root CA > > Squid generates per-connection certificate > > > Note that in (B) there is no intermediary certificate at all, and Squid > does not emit any CA chain to the client. > > It works exactly the same way as the globally trusted CA do. But they > are contractually obliged to refuse giving out intermediary CA for > anyones use, or loose their status as trusted CA. > > Amos > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
