OK so it makes more sense when you say it's intentional.
I do not agree with this approach and it's a bit off topic but I got my answer.
Thanks,
Eliezer
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il
-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
Sent: Friday, July 20, 2018 6:17 PM
To: Eliezer Croitoru ; 'Squid Users'
Subject: Re: [squid-users] question about squid and https connection .
On 07/20/2018 03:04 AM, Eliezer Croitoru wrote:
> I think we can use MD5/SHA1/SHA256 or even CRC32 to show the "freshness" of
> the certificate.
Sorry, you lost me: I see no connection between the previous discussion
about CA keys and your new statement about something you call
certificate "freshness".
> Also this way the ssl_db folder will be free of the burden of tight 600 or
> 700 permissions.
>
> Did I got it right?
The stored generated certificates include their private keys so the
database should use tight permissions.
Alex.
> -Original Message-
> From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
> Sent: Thursday, July 19, 2018 11:29 PM
> To: Eliezer Croitoru ; 'Squid Users'
>
> Subject: Re: [squid-users] question about squid and https connection .
>
> On 07/19/2018 12:08 PM, Eliezer Croitoru wrote:
>
>> So the ROOT CA key which squid is using is being used for all the fake
>> certificates, why do we need so many copies of it?
>
> FWIW, I cannot think of any reason to store the CA certificate key in
> the database of generated certificates. That key is only used to sign a
> freshly generated certificate, and the certificate generator never
> regenerates certificates, so I do not see the need to reuse that CA key.
>
> Alex.
>
>
>> -Original Message-
>> From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
>> Sent: Wednesday, July 18, 2018 11:45 PM
>> To: Eliezer Croitoru ; 'Squid Users'
>>
>> Subject: Re: [squid-users] question about squid and https connection .
>>
>> On 07/18/2018 02:23 PM, Eliezer Croitoru wrote:
>>
>>
>>> Every certificate have the same properties of the original one except
>>> the "RSA key" part which it's certifiying.
>>
>> Assuming you are talking about the generated certificates for the same real
>> certificate X, then yes, they will all have the same (mimicked) fields.
>> Whether they will be signed by the same CA depends on Squid configuration.
>> In my answers, I assumed that all those Squids are configured with the same
>> CA (including the same private key).
>>
>>
>>> So what I'm saying is that you cannot say that every certificate which
>>> will be created with the same CA will be the same for two different
>>> 2048 bits RSA keys.
>>
>> ... unless the keys are also the same, which was my and, AFAICT, OP
>> assumption.
>>
>> Also, unless you are doing something nasty, it probably does not make sense
>> to configure a bumping Squid with a public CA certificate that is identical
>> to some other public CA certificate but has a different private key. In
>> other words, if you are using 200 Squids with a single public CA
>> certificate, then all those Squids should use the same private key.
>>
>> Alex.
>>
>>
>>
>>> -Original Message-
>>> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org]
>>> On Behalf Of Alex Rousskov
>>> Sent: Friday, July 13, 2018 2:01 AM
>>> To: 'Squid Users'
>>> Subject: Re: [squid-users] question about squid and https connection .
>>>
>>> On 07/12/2018 02:35 PM, Eliezer Croitoru wrote:
>>>
Every RSA key and certificate pair regardless to the origin server
and the SSL-BUMP enabled proxy can be different.
>>>
>>> I cannot find a reasonable interpretation of the above that would
>>> contradict what I have said. Yes, each unique certificate has its own
>>> private key, but that is not what Ahmad was asking about AFAICT.
>>>
>>>
Will it be more accurate to say that just as long as these 200 squid
instances(different squid.conf and couple other local variables) use
the same exact ssl_db cache directory then it's probable that they
will use the same certificate.
>>>
>>> That statement is incorrect. Squids configured with different CA
>>> certificates will generate different fake certificates for the same
>>> real certificate.
>>>
>>> I assume that Ahmad was asking about a situation where 200 Squid
>>> instances had the same configuration (including CA certificates).
>>>
>>> Please note that the certificate generator helper gets the signing
>>> (CA) certificate as a parameter with each generation request (because
>>> different Squid ports may use different CA certificates). Also, Squid
>>> probably does not officially support sharing the certificate directory
>>> across Squid instances (even if it works).
>>>
>>>
Or these 200 squid instances are in SMP mode with 200 workers... If
these 200 instances do not share memory and
