[squid-dev] [PATCH] Errors served using invalid certificates when dealing with SSL server errors.

[Tsantilas Christos]

The patch for squid-3.5.
I suppose it should applied here too.

On 07/09/2015 04:13 PM, Tsantilas Christos wrote:
> Applied to trunk as r14145.
>
>
> On 07/07/2015 09:05 PM, Amos Jeffries wrote:
>> On 8/07/2015 4:28 a.m., Tsantilas Christos wrote:
>>> Hi all,
>>>
>>> When bumping Squid needs to send an Squid-generated error "page" over a
>>> secure connection, Squid needs to generate a certificate for that
>>> connection. Prior to these changes, several scenarios could lead to
>>> Squid generating a certificate that clients could not validate. In those
>>> cases, the user would get a cryptic and misleading browser error instead
>>> of a Squid-generated error page with useful details about the problem.
>>>
>>> For example, is a server certificate that is rejected by the certificate
>>> validation helper. Squid no longer uses CN from that certificate to
>>> generate a fake certificate.
>>>
>>> Another example is a user accessing an origin server using one of its
>>> "alternative names" and getting a Squid-generated certificate containing
>>> just the server common name (CN).
>>>
>>> These changes make sure that certificate for error pages is generated
>>> using SNI (when peeking or staring, if available) or CONNECT host name
>>> (including server-first bumping mode). We now update the
>>> ConnStateData::sslCommonName  field (used as CN field for generated
>>> certificates) only _after_ the server certificate is successfully
>>> validated.
>>>
>>
>> +1.
>>
>> Amos
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Invalid-Certificate-on-Blocked-SSL-Errors-squid-3.5-t2.patch
Type: text/x-patch
Size: 9508 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20150709/879cf997/attachment.bin>