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
Attachment:
signature.asc
Description: This is a digitally signed message part
