[squid-dev] Bug 4305: Squid reports X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY...

[Christos Tsantilas]

On 12/02/2015 07:18 AM, Amos Jeffries wrote:
> 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).

Well, this is not true.
For example the sslproxy_session_*,  are options which affect squid SSL 
server.
Other options like the sslproxy_cert_sign_hash, sslproxy_cert_adapt, and 
others are refer to the squid SSL server side of bumped connections.

If no objection I will select the  sslproxy_foreign_intermediate_certs. 
Looks the best choice...



>
> 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
>