[squid-users] Squid question with letsencrypt
cbidwell at usgs.gov
Mon Jun 27 15:01:09 UTC 2016
Thanks so much for your help on this. So I'm changing it up a little bit.
Disregard the backend server certificates. I'm using 3 frontend servers
but I want to use LetsEncrypt to create the SAN certificate for them. Is
the concept the same with how you described this? Just as I mentioned, one
of the servers is running the letsencrypt process which communicates with
letsencrypt and then tries to resolve all of the dns names and
correspondingly checks the /.well-known/acme-challenge directory. This is
what I've got in my config:
# LetsEncrypt Cache-peer-access
cache_peer dev02-server.com parent 80 0 no-query originserver default
cache_peer dev02-server01.com parent 80 0 no-query originserver default
cache_peer dev02-server02.com parent 80 0 no-query originserver default
acl acme urlpath_regex ^/.well-known/acme-challenge
cache_peer_access dev02-server_80 allow acme
cache_peer_access dev02-server01_80 deny acme
cache_peer_access dev02-server02_80 deny acme
Where dev02-server_80 is running letsencrypt and the other two are the
What I'm expecting to do here is a wget (to test this) on
dev02-server-main.com which resolves to the IP's of server01.com and
server02.com. I'm still getting an error 403 Forbidden.
On Sat, Jun 25, 2016 at 12:51 AM, Amos Jeffries <squid3 at treenet.co.nz>
> On 25/06/2016 4:48 a.m., Bidwell, Christopher wrote:
> > Hi all,
> > I'm very new to squid and we are wanting to implement letsencrypt for our
> > ssl certificates.
> > Here's the scenario:
> > We've got several frontend servers running squid that are caching from
> > backend systems.
> > i.e. test.com -> 10.0.0.1, 10.0.1.1, 10.0.2.1 (all physically separated
> > from one another)
> > Each internal server also has its own dns name:
> > web1.test.com -> 10.0.0.1
> > web2.test.com -> 10.0.1.1
> > web3.test.com -> 10.0.2.1
> > Note that these are all public. Using 10. as examples.
> Ok, but dangerous. That allows the frontend to be bypassed whenever a
> client wants. So you will need to ensure security to the backend stays
> in sync with the frontend. If you don't have to, its best to avoid that
> trouble and filter everything consistently through the frontend.
> That also allows the backends to avoid public CAs like LetsEncrypt
> entirely. You can use a single custom CA exclusively for the
> frontend<->backend traffic and have much better security settings on
> those internal links since you no longer have to worry about random
> visitors capabilities.
> > I'd like to create a SAN certificate naming the 3 internal systems in
> > addition to the public name:
> > test.com, web1.test.com, web2.test.com, and web3.test.com.
> > On the letsencrypt forum they said that I could do a HTTP 301 redirect
> > the squid servers to the backend letsencrypt server where any match for:
> > /.well-known/acme-challenge/* would redirect with an HTTP 301 to that
> > backend letsencrypt server. I'm not sure how to do this and the squid
> > documentation is not easy to comprehend.
> > Let me know if this isn't clear how I've explained this.
> If LetsEncrypt are contacting web1 for example. They should be going to
> the backend directly. Since http://web1.test.* is not a frontend request.
> Whatever server is performing the LetsEncrypt for the frontend needs to
> know its doing it for the generic domain as well as itself. Squid is not
> a web server, so you need to nominate a backend to do that (could be a
> new one just of LetsEncrypt stuff).
> For example doing it on web1 would mean fitting these lines into your
> existing config (this order, but not necesarily together like this):
> acl acme urlpath_regex ^/.well-known/acme-challenge
> cache_peer_access web1 allow acme
> cache_peer_access web2 deny acme
> cache_peer_access web3 deny acme
> No "redirect" involved. Just tell Squid that server is where those URL
> are handled.
> squid-users mailing list
> squid-users at lists.squid-cache.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the squid-users