[squid-users] using "acl <name> user_cert CN <cn>"

[Amos Jeffries]

On 29/02/20 2:35 am, claudiu vasadi wrote:
> Hello list,
> 
> I’m currently trying to wrap my head around the concept of using “acl
> name user_cert CN cn” on squid 3.5. What I would like to achieve is a
> setup where the client needs to pass a certificate and squid
> allows/denies access to the internet based on said certificate CN. So
> far I came up empty.


Well, first you need that part of getting the client to send its
certificate.

http_port ... clientca=/path/to/clients/ca.pem


> 
> My current config:
> 
> acl ssl_authentication user_cert CN user.cn.com
> http_access allow all ssl_authentication
> 

The "all" in that line is completely pointless.


> http_port 443 ssl-bump  \
>   cert=/etc/squid/myCA.pem \
>   generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> 
> #this is what generates certs on the fly. Point to the CA you generated above.
> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /tmp/squid/ssl_db -M 4MB
> sslcrtd_children 5
> 
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump bump all
> ssl_bump stare all
> always_direct allow all
> 

Where are the cache_peer's this always_direct rule is bypassing?

Hint: pointless config again. Remove it.

> 
> From the client side I do:
> 
> curl -E certificate.pem -k -x http://myproxy:443 https://www.google.de
> 
> 
> but I get the access denied page.
> 
> Checking cache.log I see:
> matches: checking ssl_authentication = 0
> clientAccessCheckDone: The request CONNECT www.google.de:443 is
> DENIED; last ACL checked: all
> 
> So it’s clear the acl doesn’t match.

Indeed. TLS has not started yet. Not even the handshake parts.

Your config says that HTTP messages (lacking client TLS certs) are to be
denied. That means everything arriving in an http_port.


Amos