[squid-users] SSL3_READ_BYTES:sslv3 alert certificate unknown

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
Browser do. Bump-enabled proxy is not.

This is significantly limits the possibility of operating SSL bump in a
more or less large installations.

In addition, not every system administrator is able to write any complex
helper in any language. I mean, it seems to me, is to write such and be
included in the proxy. Not a toy demonstrator features. A full-helper,
which, though in a much easier life of the system administrator.

So far I have only heard that such solutions exist - even in a single
instance. But not a single piece of code seen.

Personally, I used the method of Edison - each case I found out manually
find and install the desired one certificate. But this is - not the
solution. I have only a few hundred users. I find it difficult to
determine what the problems will be the system administrator really
large cache - say, 10 thousand users.

Perl/Python/Haskell/Go/C/C++ really cool - but not every geek is
red-weeks to address the CA's problem of productive server.

28.10.15 19:55, Amos Jeffries пишет:
> On 28/10/2015 11:57 p.m., Yuri Voinov wrote:
>>
>>
>> 28.10.15 16:47, Amos Jeffries пишет:
>>> On 28/10/2015 11:35 p.m., Yuri Voinov wrote:
>>>> Hi gents.
>>>>
>>>> I think, all of you who use Bump, seen much this messages in your
>>>> cache.log.
>>>>
>>>> SSL3_READ_BYTES:sslv3 alert certificate unknown
>>>>
>>>> AFAIK, no way to identify which CA is absent in your setup.
>>>>
>>>> I propose to consider the following questions: how do properly support
>>>> SSL proxy, if you can not identify the problem certificates? Telepaths
>>>> sunbathing in Bali. The procedure, which currently can not quickly and
>>>> in any way to effectively determine such a certificate.
>>>>
>>>> At the moment, the situation is as follows. SSL library - a thing in
>>>> itself, it runs by itself and does not write any logs. Squid - itself
>>>> and any useful information on the library does not receive but obscure
>>>> diagnostic messages. The possibility in any way specify the SSL library
>>>> diagnostic messages we have, and, as I understand it, will not.
>>>>
>>>> So, any ideas?
>>> Make sure Squid is sending the whole CA chain to the remote end?
>> I think so, "From the remote end". If we have web-server with CA, which
>> is not exists on our proxy, we must install it (which means "trust
>> them", yea?) in our proxy manually.
>>
>> I have idiotic idea - Squid fetch remote CA and offer us to trust and
>> install interactively. :) This is, of course, clinically idiotism. :)
>>
>
> That is what the Browsers do. It has been suggested to write a cert
> validator that does it too.
>
>
>> But - to support real Squid installation with thoursands users, I really
>> want to know, which CA's not exists from my side.
>>
>> Intermediate CA's is no matter - if we have root CA already, fetch
>> intermediate chain is not big problem.
>>
>> In this case, however, we faced unknown root CA exactly.
>>
>> Yes?
>
> I doubt. Chains do not have length limits and IIRC you can't know that
> it is a root CA until you actually have it and see that it is
> self-signed. At which point it is not "certificate unknown" anymore.
>
> What is missing is just some CA in the chain. It needs to be located
> somehow, only then can the decision happen about whether to trust or not
> and see if another up the chain is needed too.
>
>
>>
>> And so what?
>
> So by walking the chain and filling in as needed the cert validator
> helper can probably fill the whole sequence in and reach a root CA that
> is already trusted and tells you the found ones can be too. That is what
> the Browsers do.
>
>
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJWMNZ1AAoJENNXIZxhPexGX3MIAKTns/hgWpoNXj5DEf30U9Ys
WChLf9iBbdqM2bUKIczNOVnqLEF2HhrY+sNByImXTwdxOPuj3IIzAb8XPDeXdIvt
P6pCWU18tT8ty4KT/4Vkcfnpni9ytOAh9pp1DpRaw8WI2+NT+DkLnaMJ+yLYiqKt
JokNGkuz+UtyfGYF+YvLqtWXz8C8kSI1DbWtbqDXcjyk2d0rqswSjSQRptD8xEsf
UAvCZp+IoOdOYUHDd24rQgFt/Xhuao6+clCROh86o6I5Uhfh0MoESbSUwZhPeOc9
WckGd0jOjBBQOrQMbY6dz9XoLluhbFeY1ia01XM3/45zKWgjMnEEciXBkK7dw/M=
=SZDs
-----END PGP SIGNATURE-----