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