[squid-dev] Bug 4305: Squid reports X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY...
Alex Rousskov
rousskov at measurement-factory.com
Wed Dec 2 15:53:36 UTC 2015
On 12/01/2015 10:18 PM, Amos Jeffries wrote:
> On 2/12/2015 6:08 a.m., Alex Rousskov wrote:
>> On 12/01/2015 04:38 AM, Amos Jeffries wrote:
>>> 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.
My argument is that if we add a directive called
sslproxy_intermediate_certs, many admins are likely to attempt to put
intermediate https_port certificates there because it will look like a
good fit to them, _despite_ the facts you cite. Many will focus on the
"intermediate_cert" part and block out the other signals you mentioned.
This naming issue is not important to me. If you think
sslproxy_intermediate_certs is better than
sslproxy_untrusted_intermediate_certs or
sslproxy_foreign_intermediate_certs, then let's use
sslproxy_intermediate_certs.
Otherwise, let Christos pick the best out of those three names.
Thank you,
Alex.
More information about the squid-dev
mailing list