On 24/12/19 3:47 pm, GeorgeShen wrote: > > >> No. You receive a server cert and the CA chain required to validate that >> server cert. >> >> Stop thinking of certs as belonging to the proxy. It seems to be >> confusing you. All 3 certs can be called "the proxy's certs" and yet >> none of them is a "proxy cert" in TLS definitions. > > Amos, > > but those two certs the client got is the certificate I created for the > proxy, and it is defined on the 'ssl-bump' line > cert=/usr/local/squid/etc/ssl_cert/myCA.pem. That myCA.pem has a private key > and a certificate, the client 'openssl s_client' receives two of the certs > are that certificate. I thought this had to be the 'proxy' cert. Lets start with some of the basics: TLS has the concept of a "proxy cert" - that is a certificate with a flag stating that the server type is a proxy. That makes modifications to how things like SNI, same-origin protections and nested encryption are handled in clients. The traffic inside the TLS is the same as you would see on port 3128 - its just encrypted now. The "cert you put in the proxy" for SSL-Bump should be a CA cert. Either a root/self-signed or intermediate CA cert. That type of cert can sign other certs. SSL-Bump generates the 'modified host cert' and needs a CA to sign it. The client thinks it is talking to an origin server - the traffic inside the TLS is usually the same as you would see on port 80. I hope that makes the situation(s) clear? (I am simplifying a few things. But they should not matter to the basic understanding.) If you are looking to view the cert the proxy has been _configured with_ on an ssl-bump port that 'cert' is the *entire chain* of CAs following the server cert you called the "modified host cert". Some will have been loaded through 'cert=' and some maybe loaded through other directives (eg cafile or capath). Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users