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 <squ...@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@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users