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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
