[squid-users] Client certificate authentication problem

[Neven Vrenko]

Message-ID:
        <248ca98d-1862-0ead-87c0-67a0aa408ea8 at measurement-factory.com>
Content-Type: text/plain; charset=utf-8

> On 4/30/21 4:40 AM, Neven Vrenko wrote:
> Hello Alex,
>
> thank you for your answer. I was little bit puzzled since I haven't got
> any error when using "clientca" with "http_port". I thought, maybe it
> was somehow possible, beyond my understanding. :)
>
> The reason why I didn't respond immediately, because I wanted to test
> everything with the "https_port" configuration.
>
> Now my configuration looks like this:
>
>> https_port 443 tls-cert=/etc/squid/certs/new-squid.cert
> tls-key=/etc/squid/certs/new-squid.key
> clientca=/etc/squid/certs/autn.pem capath=/etc/squid/certs/CAs sslcontext=id
>
> This works...
>
> What I'm trying to do is access control with *user_cert* ACL based on CN
> information.
>
> My ACL configuration is super minimal:
>
>> acl ssl_auth user_cert CN "/etc/squid/allowed.cn <http://allowed.cn>"
>> http_access allow ssl_auth
>>
>> http_access deny all
>
> File "/etc/squid/allowed.cn" contains one row/entry:
> "Doe John PKI 1234567890" (without quotes)
>
> However this doesn't work.
>
> From the cache.log, it is visible that client certificate information is
> fetched:
>
>> clientNegotiateSSL: New session 0x11415a0 on FD 12 (10.x.x.x:60308)
>> retrieveNegotiatedInfo: SSL connection info on FD 12 SSL version
> TLS/1.2 negotiated cipher AES128-GCM-SHA256
>> clientNegotiateSSL: FD 12 client certificate: subject: /DC=tst/CN=Doe
> John PKI 1234567890
>> clientNegotiateSSL: FD 12 client certificate: issuer:
> /DC=com/DC=tst/DC=PKI/CN=CA-AUTH-01
>> Server.cc(90) readSomeData: conn7 local=10.x.x.x:443
> remote=10.x.x.x:60308 FD 12 flags=1: reading request...
>
> From the cache.log is as well visible that ssl_auth ACL is checked, but
> there is NO MATCH:
>
>> Acl.cc(124) matches: checking http_access
>> Checklist.cc(398) bannedAction: Action 'ALLOWED/0' is not banned
>> Acl.cc(124) matches: checking http_access#1
>> Acl.cc(124) matches: checking ssl_auth     < --- Access list
>>
>> CertificateData.cc(68) match: CN=Doe John PKI 1234567890   < ---
> Client certificate CN
>>
>> MemBlob.cc(56) MemBlob: constructed, this=0x14dccc0 id=blob1388
> reserveSize=35
>> MemBlob.cc(101) memAlloc: blob1388 memAlloc: requested=35, received=40
>> SBuf.cc(866) reAlloc: SBuf5096 new store capacity: 40
>> StringData.cc(33) match: aclMatchStringList: checking 'Doe John PKI
> 1234567890'
>>
>> StringData.cc(36) match: aclMatchStringList: 'Doe John PKI 1234567890'
> NOT found   < --- doesn't match
>>
>> Acl.cc(151) matches: checked: ssl_auth = 0
>> Acl.cc(151) matches: checked: http_access#1 = 0
>
>
> I'm really not sure what I have missed...
> I tried to put CN directly in the ACL, so with no reference to thefile.
> I tried to put single and double quotes around CN in allowed.cn
> <http://allowed.cn> file, as well.
>
> Could you please help me further? What am I doing wrong here?

>I see no red flags in what you are describing and in the provided logs.
>Unfortunately, ACLStringData::match() does not log the strings it is
>comparing the configured ACL value against, and I lack the free time
>necessary to triage this further for you right now. Hopefully, somebody
>else will volunteer to triage this. It should not be very difficult to
>get to the bottom of it.


>Sorry,

>Alex.

Hi Alex,

thank you for your opinion and time you took for answering. I dove
into the code a little bit and did some debugging.
It seems that nothing is wrong there. What I did eventually, more out
of desperation than common sense, was restarting the whole machine,
rather than the Squid process for 1001st time.

That did the trick... Now everything is working... I don't have an
explanation for why, but now it works...

Thank you one again,
Neven