[squid-users] Squid question with letsencrypt

[Bidwell, Christopher]

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
name=dev02-server_80
cache_peer dev02-server01.com parent 80 0 no-query originserver default
 name=dev02-server01_80
cache_peer dev02-server02.com parent 80 0 no-query originserver default
 name=dev02-server02_80

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>
wrote:

> 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 -> 10.0.0.1, 10.0.1.1, 10.0.2.1 (all physically separated
> > from one another)
> >
>
> Ok,
>
> > 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
> 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>