<div dir="ltr">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:<div><br></div><div><div><font face="monospace, monospace"># LetsEncrypt Cache-peer-access</font></div><div><font face="monospace, monospace">cache_peer <a href="http://dev02-server.com" target="_blank">dev02-server.com</a> parent 80 0 no-query originserver default name=dev02-server_80</font></div><div><font face="monospace, monospace">cache_peer dev02-</font><span style="font-family:monospace,monospace"><a href="http://server01.com" target="_blank">server01.com</a></span><font face="monospace, monospace"> parent 80 0 no-query originserver </font><span style="font-family:monospace,monospace">default</span><font face="monospace, monospace"> name=dev02-server01_80</font></div><div><font face="monospace, monospace">cache_peer dev02-</font><span style="font-family:monospace,monospace"><a href="http://server02.com" target="_blank">server02.com</a></span><font face="monospace, monospace"> parent 80 0 no-query originserver </font><span style="font-family:monospace,monospace">default</span><font face="monospace, monospace"> name=dev02-server02_80</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">acl acme urlpath_regex ^/.well-known/acme-challenge</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">cache_peer_access dev02-server_80 allow acme</font></div><div><font face="monospace, monospace">cache_peer_access dev02-server01_80 deny acme</font></div><div><font face="monospace, monospace">cache_peer_access dev02-server02_80 deny acme</font></div><div><br></div><div>Where dev02-server_80 is running letsencrypt and the other two are the squid servers.  </div><div><br></div><div>What I'm expecting to do here is a wget (to test this) on <a href="http://dev02-server-main.com">dev02-server-main.com</a> which resolves to the IP's of <a href="http://server01.com">server01.com</a> and <a href="http://server02.com">server02.com</a>.  I'm still getting an error 403 Forbidden.</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 25, 2016 at 12:51 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On 25/06/2016 4:48 a.m., Bidwell, Christopher wrote:<br>
> Hi all,<br>
><br>
> I'm very new to squid and we are wanting to implement letsencrypt for our<br>
> ssl certificates.<br>
><br>
> Here's the scenario:<br>
><br>
> We've got several frontend servers running squid that are caching from the<br>
> backend systems.<br>
<br>
</span>Ok,<br>
<span><br>
><br>
> i.e. <a href="http://test.com" rel="noreferrer" target="_blank">test.com</a> -> 10.0.0.1, 10.0.1.1, 10.0.2.1 (all physically separated<br>
> from one another)<br>
><br>
<br>
</span>Ok,<br>
<span><br>
> Each internal server also has its own dns name:<br>
><br>
> <a href="http://web1.test.com" rel="noreferrer" target="_blank">web1.test.com</a> -> 10.0.0.1<br>
> <a href="http://web2.test.com" rel="noreferrer" target="_blank">web2.test.com</a> -> 10.0.1.1<br>
> <a href="http://web3.test.com" rel="noreferrer" target="_blank">web3.test.com</a> -> 10.0.2.1<br>
><br>
> Note that these are all public. Using 10. as examples.<br>
<br>
</span>Ok, but dangerous. That allows the frontend to be bypassed whenever a<br>
client wants. So you will need to ensure security to the backend stays<br>
in sync with the frontend. If you don't have to, its best to avoid that<br>
trouble and filter everything consistently through the frontend.<br>
<br>
That also allows the backends to avoid public CAs like LetsEncrypt<br>
entirely. You can use a single custom CA exclusively for the<br>
frontend<->backend traffic and have much better security settings on<br>
those internal links since you no longer have to worry about random<br>
visitors capabilities.<br>
<span><br>
><br>
> I'd like to create a SAN certificate naming the 3 internal systems in<br>
> addition to the public name:<br>
><br>
> <a href="http://test.com" rel="noreferrer" target="_blank">test.com</a>, <a href="http://web1.test.com" rel="noreferrer" target="_blank">web1.test.com</a>, <a href="http://web2.test.com" rel="noreferrer" target="_blank">web2.test.com</a>, and <a href="http://web3.test.com" rel="noreferrer" target="_blank">web3.test.com</a>.<br>
><br>
> On the letsencrypt forum they said that I could do a HTTP 301 redirect from<br>
> the squid servers to the backend letsencrypt server where any match for:<br>
>  /.well-known/acme-challenge/* would redirect with an HTTP 301 to that<br>
> backend letsencrypt server.  I'm not sure how to do this and the squid<br>
> documentation is not easy to comprehend.<br>
><br>
> Let me know if this isn't clear how I've explained this.<br>
><br>
<br>
</span>If LetsEncrypt are contacting web1 for example. They should be going to<br>
the backend directly. Since <a href="http://web1.test." rel="noreferrer" target="_blank">http://web1.test.</a>* is not a frontend request.<br>
<br>
Whatever server is performing the LetsEncrypt for the frontend needs to<br>
know its doing it for the generic domain as well as itself. Squid is not<br>
a web server, so you need to nominate a backend to do that (could be a<br>
new one just of LetsEncrypt stuff).<br>
<br>
For example doing it on web1 would mean fitting these lines into your<br>
existing config (this order, but not necesarily together like this):<br>
<br>
 acl acme urlpath_regex ^/.well-known/acme-challenge<br>
 cache_peer_access web1 allow acme<br>
 cache_peer_access web2 deny acme<br>
 cache_peer_access web3 deny acme<br>
<br>
No "redirect" involved. Just tell Squid that server is where those URL<br>
are handled.<br>
<br>
<br>
Amos<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div><br><br>
</div></div></div></div>