On 2/12/2015 6:08 a.m., Alex Rousskov wrote: > On 12/01/2015 04:38 AM, Amos Jeffries wrote: > >> So, I suggest this for the full doc: >> " >> DOC_START >> Many origin servers fail to send their full server certificate >> chain for verification. Assuming the client already has or can >> easily locate any intermediate certificates that are missing. >> >> Squid uses the certificates from the specified file to fill in >> these missing chains when trying to validate origin server >> certificate chains. >> >> The file is expected to contain zero or more PEM-encoded >> intermediate certificates. These certificates are not treated >> as trusted root certificates and any self-signed certificate in >> this file will be ignored. >> >> This directive may be repeated to load multiple files >> DOC_END >> " > > Looks good to me, assuming the code ignores self-signed certificates and > does support loading multiple files. > > s/verification. Assuming/verification, assuming/ > > s/any intermediate certificates that are missing/any missing > intermediate certificates/ > > s/certificates and any/certificates, and any/ > > s/multiple files/multiple files./ > > >> Nod. "untrusted" is not exactly a clear name to anyone unfamiliar with >> the internals of OpenSSL. To the rest of the world (including Squid's >> usage) these are "intermediate certificates". So calling it >> "sslproxy_intermediate_certs" might be clearer to admin than untrusted. > > Agreed. On the other hand, the proxy itself may need send its own > intermediate certificates (for regular https_port connections, when > _not_ doing SslBump) so some admins will try to stuff those proxy > intermediate certificates here.
AFAICS, "sslproxy_" directive set are all consistently scoped as being for configuring the outgoing server connections (specifically DIRECT ones, not cache_peer). The equivalent https_port intermediate certificates are probably best loaded as multiple certificates from the cert= file. That seems to be where admin are first attempting to putting them already. Amos _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
