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

[Amos Jeffries]

On 1/12/2015 9:36 p.m., Christos Tsantilas wrote:
> On 11/29/2015 09:00 AM, Amos Jeffries wrote:
>> On 28/11/2015 9:35 p.m., Christos Tsantilas wrote:
>>> Hi all,
>>>    Sometimes the SSL servers does not send the full chain of
>>> intermediate
>>> certificates, but instead send a link where the client can download the
>>> intermediate certificates.
>>>
>>> Currently squid can not handle such cases. Measurement Factory build a
>>> patch which provides a workaround for this problem: Allow the users to
>>> build a database of intermediate certificates, which can be used by
>>> squid to complete certificate chains.
>>>
>>> Measurement Factory currently works to implement a full solution for
>>> this bug, a downloader for squid which will retrieve missing
>>> certificates from the net.
>>> However this solution may take some time to test and finish it.
>>>
>>> Is it OK to apply to trunk the workaround patch in bug 4305?
>>
>>
>> It touches the squid.conf UI so I would rather not at this point.
>>
>> That said the problem it resolves is rather more important than
>> preserving an arbitrary policy. So I am in agreement with it going in
>> sooner rather than later provided it works as planned.
> 
> This is means that I should apply it to trunk?
> 

Yes, +1 with the documentation change being discussed below.

>>
>>
>> But please extend the squid.conf documentation to state that self-signed
>> (aka root) certificates are not supported by the new option and will be
>> ignored. They are ignores silently, so it needs to be stated somewhere
>> to avoid confusion.
> 
> The new directive "sslproxy_untrusted_certs" documented as
> 
> "Squid uses the intermediate certificates pre-loaded from the specified
> file to validate origin server certificate chains. Squid receives many
> incomplete chains (i.e., chains with intermediate certificates missing).
> The file is expected to contain zero or more PEM-encoded intermediate
> certificates. These certificates are not treated as trusted root
> certificates."
> 
> Isn't it enough the following reference: "These certificates are not
> treated as trusted root certificates."?

No, that sentence currently implies that root certificates are still
useable. Reality in the code is that they will not be even added to the
chain. Just silently skipped.

(that skip should probably be done in Ssl::loadCerts() to save memory).


> Moreover the name of new directive it should be clear about the purpose
> of these certificates.

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.
But I dont have any preference either way.


Also, now that I think of it, the code is already capable of loading
multiple files. That needs to be mentioned too.


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
"

Amos