[squid-users] Squid question with letsencrypt

Bidwell, Christopher 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
squid servers.

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
> the
> > backend systems.
> Ok,
> >
> > i.e. test.com ->,, (all physically separated
> > from one another)
> >
> Ok,
> > Each internal server also has its own dns name:
> >
> > web1.test.com ->
> > web2.test.com ->
> > web3.test.com ->
> >
> > 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
> from
> > 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.
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160627/da9e1fdf/attachment.html>

More information about the squid-users mailing list