On 10/09/11 03:13, Sidnei Moreira wrote:
> hello amos, thanks for the quick reply.
>
> i've changed the config according the your link ref. owa. but i still have
> doubts because it is still not working.
>
> i didn't quite understand what you mean when you said:
> "All requests entering through this port are re-written with the domain name
> "mail.my-domain.com". Update your EXCH ACL to permit "mail.my-domain.com"
> and ensure that the exchange server believes its public domain name is
> "mail.my-domain.com"."
>
> my public domain name which is "mail.my-domain.com" is never known by the
> exchange server. the only name it knows is "exchange-server.local", which is
> reflected in the self-signed certificate contained in the cache_peer clause.
I meant it exactly as stated. Requests arrive at Squid, your https_port
configuration (defaultsite= without vhost) tells Squid to ignore the
details sent by the client and use the value of defaultsite in the URL
for all internal operations.
So the cache_peer_access ACLs only compare the dstdomain value against
the defaultsite value when making their decision to block access or not.
Additionally the public domain name used by the client gets passed
straight through Squid to the exchange server. So the exchange server
can generate response and HTML pages with correct URLs, along with
whatever security controls it needs based on that.
>
> the public certificate (and its related public domain "mail.my-domain.com"
> or "mail.my-domain.com/owa", is only known by the squid server.
> because of a couple of reasons i am not able to install the public geotrust
> certificate into my exchange server. and if i could, there would be no need
> to use squid in between, once exchange could handle the outside connections
> by itself. i am just adding squid to this scenario because squid needs to
> handle the public internet connections (based on the public geotrust
> certificate), and pass it on to exchange as an internal client would do
> (based on self-signed certificate).
You don't need any particular certificate on the exchange server. The
FRONT_END_HTTPS details on the OWA page inform Exchange that it is being
secured by Squid instead and URLs sent to the client should contains
https://. Even if there is no SSL between itself and Squid.
It will also work with Squid perfectly well using a self-signed
certificate for the public domain name.
The DONT_VERIFY_PEER flag inform Squid to accept any certificate given
by the Exchange server,
OR,
loading your self-signing CA as cacert= to verify with, informs Squid
to trust the Exchange server self-signed certificate but not any others.
>
> so, my actual config is now like this:
> ##############
> https_port squid-ip-address:443 cert=/etc/squid3/public_geotrust_cert.pem
> defaultsite=mail.my-domain.com connection-auth=off
> cache_peer exchange-ip-address parent 443 0 no-query originserver login=PASS
> ssl sslcert=/etc/squid3/self_signed_cert.pem name=owaServer
^^^ this informs Squid to use the self_signed_cert.pem to encrypt
things going to Exchange. The certificate handed over by Exchange will
be verified against the public trusted CA.
Which appears to be what is failing below.
> acl OWA dstdomain exchange-server-name.local
> cache_peer_access owaServer allow OWA
> never_direct allow OWA
> http_access allow OWA
> http_access deny all
> miss_access allow OWA
> miss_access deny all
> ##############
> and i still got the error in cache.log:
> TCP_DENIED/403 4027 GET http://mail.my-domain.com/owa - NONE/- text/html
>
> but, if I change:
> acl OWA dstdomain exchange-server-name.local
> to
> acl OWA dstdomain mail.my-domain.com
>
> then i got several of these in cache.log:
> TCP connection to exchange-ip-address/443 failed
> fwdNegotiateSSL: Error negotiating SSL connection on FD 14:
> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed (1/-1/0)
> temporary disabling (Service Unavailable) digest from 'exchange-ip-adress'
> and this on the browser:
> failed to establish a secure connection with owaServer / returned: (71)
> Protocol error
>
> thanks again,
> sidnei
>
>
> -----Mensagem original-----
> De: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Enviada em: quinta-feira, 8 de setembro de 2011 21:08
> Para: squid-users_at_squid-cache.org
> Assunto: Re: [squid-users] reverse proxy shows error 403 denied
>
> On 09/09/11 02:29, Sidnei Moreira wrote:
>> hello,
>>
>> i have configured squid to reverse-proxy an internet connection going
>> into my internal exchange server.
>> the squid configuration section is like this one:
>>
>> ##############################
>> # ip 10.0.1.1 - squid server
>> # ip 10.0.1.2 - ms-exchange server
>> https_port 10.0.1.1:443 cert=/etc/squid3/geotrust_cert.pem
>> defaultsite=mail.my-domain.com
>
> All requests entering through this port are re-written with the domain name
> "mail.my-domain.com".
>
> Update your EXCH ACL to permit "mail.my-domain.com" and ensure that the
> exchange server believes its public domain name is "mail.my-domain.com".
>
>> cache_peer 10.0.1.2 parent 443 0 no-query originserver login=PASS ssl
>> sslcert=/etc/squid3/selfsigned.pem name=exchangeServer
>>
>> acl EXCH dstdomain .rpc_domain_name
>> cache_peer_access exchangeServer allow EXCH cache_peer_access
>> exchangeServer deny all
>>
>> never_direct allow EXCH
>> http_access allow EXCH
>> http_access deny all
>> miss_access allow EXCH
>> miss_access deny all
>> ##############################
>>
>> but, when i try to connect from the internet i receive a denying page,
>> and the cache log says:
>> TCP_DENIED/403 3861 GET https://mail.my-domain.com/owa - NONE/-
>> text/html
>>
>
> That looks like an OWA request.
>
> They require some different peer configuration than RPC.
> http://wiki.squid-cache.org/ConfigExamples/Reverse/OutlookWebAccess
>
> IIRC it had something to do with OWA doing client certificate verification.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE9 or 3.1.15
> Beta testers wanted for 3.2.0.11
>
-- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.15 Beta testers wanted for 3.2.0.11Received on Sat Sep 10 2011 - 04:24:48 MDT
This archive was generated by hypermail 2.2.0 : Sat Sep 10 2011 - 12:00:02 MDT