On mån, 2008-06-30 at 12:11 +0200, Alex van Denzel wrote:
> In the dmz exists machine that does a port-forwarding of port 443 to
> our proxy. The firewalls are configured to allow that.
Hmm... then you loose the source IP before it reaches your Squid, which
would make the Squid logs a lot less useful.
> Our proxy connects to port 7511 of the appsrv. The firewalls are
> configured to allow that too.
Ok.
> The reverse proxy is a Squid-cache, version 2.6.STABLE19, running on
> Red Hat Enterprise Linux AS release 4 (Nahant Update 6).
Ok.
> First, the browser (IE and FF) give me a selection box where I can
> select the client certificate to use. But not all client certificates
> I installed are listed. How does the browser know which certificates
> to select, or, how does the server tell this to the browser?
Thats done by the clientca option.
It's also possible to request "any certificate" but not sure this is
implemented in Squid.
> Second, the only way out to the internet is through another proxy (I
> think a Microsoft ISA server). How can I tell Squid (or OpenSSL) to
> use this proxy for outgoing CA and CRL verification requests.
Squid does not automatically fetch CRL lists. You have to set up this
manually, and install the CRLs in a directory found by openssl.
Hmm.. we really should add a config option to specify the directory.
> Third. Recently we changed to another SSL provider (Comodo) and I've
> changed something in the configuration and client certificate
> verification didn't work anymore. I'ver tried some things, but I'm at
> a loss here.
Probably the CA of the issuer isn't known to your Squid..
clientca= doesn't automatically make those CAs trusted, it just makes
Squid request a sertificate issued by the subject of any certificate in
that file. Could just as well be a list of issuer names..
> Can anyone clarify what actually happens during client
> verification?
1. Squid request a certificate, asking the client to provide one which
matches clientca=..
2. Client sends certificate to Squid.
3. OpenSSL automatically verifies the certificate, which involves
finding the proper CA in the local CA store and also that it's not
revoked by a CRL in the local CRL store.
> I've read somewhere that this client certificate stuff in Squid is
> still experimental, but we'd really want to have it working.
Yes, it's still a bit experimental. Mainly due to the lack of OCSP for
online certificate validation without requiring the admin to set up CRL
downloads..
Regards
Henrik
This archive was generated by hypermail 2.2.0 : Mon Jun 30 2008 - 12:00:05 MDT