Search squid archive

Re: Sharepoint SSL Error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13/01/2012 3:27 a.m., Dale J. Rodriguez wrote:
Hello World. Noob Here.


I have successfully setup squid as a reverseproxy for port 80, however

What squid version?

my attempts to set up the same server to point to a https server on
sharepoint have failed. All I get is the authentication box, and the
following error message in cache.log:


fwdNegotiateSSL: Error negotiating SSL connection on FD 11:
error:00000000:lib(0):func(0):reason(0) (5/-1/104)

Squid is connecting to a remote server which is responding with something which is (a) not SSL encrypted, or (b) using an SSL / TLS version not supported by your OpenSSL library.


The only caveat I have is that I am using an SSL cert that was assigned
to another IP address, do you have to have matching SSL certs for this
to work properly?

If the certificate has been created to tie the domain and IP address together, then yes. I've only seen it on client certificates and some high-security setups. Most server ones seem to just be tied to the domain name, allowing re-use in reverse proxies like you are trying to do.





Here is my squid config:



visible_hostname squid.localhost

This is the visible (ie public) hostname (read: FQDN / fully qualified domain name) of your Squid machine.

Also, ".localhost" domain is invalid. The IANA registered domain you seem to be looking for is ".local". But that leads to problems with ISP admin unable to find out who on their own LAN is running the machine "squid".




always_direct allow all

This means do not use cache_peer entries in your config. Ever.

Fix #1:
Please remove this and your actual reverse-proxy config will start to work the way you configured it.


ssl_bump allow all

pipeline_prefetch off



http_port 80 defaultsite=1.2.3.60

This means your website *domain name* is "1.2.3.60" for all traffic received on port 80.

Note that clients connecting to 1.2.3.60 will of course *connect straight to 1.2.3.60* (instead of your Squid). So any URL re-write related side effects will bypass Squid and go straight to the backend server.

Clients which are somehow passing requests to Squid will have their traffic URLs re-written to http://1.2.3.60/ before Squid tries to resolve the domain (er, 1.2.3.60) in DNS and gets told the IP 1.2.3.60. always_direct will then force Squid to pass the re-written request to that IP.
 ** notice how cache_peer and the cache_peer access logics never got used.

Fix #2:
you need to add the actual public domain name clients are connecting to as defaultsite=. if you have multiple domains you need to enabel virtual hosting with the "vhost" reverse-proxy option to http_port



https_port 443 cert=/usr/ssl/lol.cer key=/usr/ssl/llol2.server.pem
connection-auth=on defaultsite=1.2.3.11

Same problems are happening here. But with the "domain name" 1.2.3.11.

Fix #3:  see fix #2.




cache_peer 1.2.3.60 parent 80 0 no-query originserver no-digest
login=PASS name=bi_iis

cache_peer 1.2.3.11 parent 443 0 connection-auth=on no-query
originserver login=PASSTHRU ssl sslflags=DONT_VERIFY_PEER
name=sharepoint

see notes above with always_direct.

These appear at first glance to be okay of themselves.



acl bi_server dst 1.2.3.60

acl sharepoint dst 1.2.3.11

acl lan1 src 1.2.3.0/32

acl lan2 src 1.2.3.0/32

acl vpn src 5.6.7.0/32

acl externalip src 2.3.4.0/32

cache_peer_access bi_iis allow bi_server

cache_peer_access bi_iis allow lan1

cache_peer_access bi_iis allow lan2

cache_peer_access bi_iis allow vpn

cache_peer_access bi_iis allow externalip

cache_peer_access bi_iis deny all

cache_peer_access sharepoint allow bi_server

cache_peer_access sharepoint allow lan1

cache_peer_access sharepoint allow lan2

cache_peer_access sharepoint allow vpn

cache_peer_access sharepoint allow externalip

cache_peer_access sharepoint deny all

see always_direct.

What I see here is nothing like a normal reverse-proxy configuration. When you have the correct domain names passing through from http_port and always_direct gone you should be able to revert these back to the simple dstdomain ACL which are documented for reverse-proxy. Possibly with HTTP/HTTPS ACLs tying the secure traffic to the SSL peer if you want.



http_access allow lan1

http_access allow lan2

http_access allow vpn

http_access allow externalip

#negative dns entry



acl localhost src 127.0.0.1/32

acl manager proto cache_object

acl Safe_ports port 80 # httpacl Safe_ports port 443 #https

acl CONNECT method CONNECT

acl POST method POST

never_direct allow CONNECT

never_direct allow POST

never_direct allow ALL

A series of allow lines followed by "allow all" is meaningless. Same applies to a series of deny and "deny all". Every possible ACL test or combination of tests is a subset of "all". The only reason you may want to performuse for a test sequence like this was if it had side effects (DNS lookups, external ACL helper calls, auth credentials lookup etc) which were needed soon by some following fast-group access control which cannot perform the lookup itself.

"always_direct allow all" and "never_direct allow all" in the same config file shows a misunderstanding of how ACLs work. always_direct determines whether use of cache_peer is forbidden (DIRECT forced) or if peers *may* be used. never_direct determines whether DIRECT may be used as a back when the cache_peer all have problems. DIRECT being a DNS lookup of the domain name, and connection to the IP addresses found in DNS.



sslproxy_flags DONT_VERIFY_PEER



cache_mgr a@xxxxxxx

http_access allow manager localhost

http_access allow lan1

http_access allow lan2

http_access allow vpn

http_access allow externalip

You allow'ed these already up above already.


http_access deny manager

http_access deny !Safe_ports

http_access deny CONNECT

#http_access deny all

This needs a look at after the rest is configured. None of it makes much sense in a reverse-proxy and can br removed. But for a general proxy it is broken at present and needs fixing.

Amos


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux