Does a host behind a proxy need to be reachable for LE to assign a certificate?

1. My Caddy version (caddy version):

~ # ./caddy version
v2.0.0-rc.3 h1:z2H/QnaRscip6aZJxwTbghu3zhC88Vo8l/K57WUce4Q=

3. The problem I’m having:

I have hosts which are filtered with remote_ip to be available only to my LAN, while others are available on Internet. All are supposed to be HTTPS.

The ones available on Internet get their certificates from LE fine.

The ones which are filtered for LAN only do not get one. The server logs say (example is actually my domain)

2020/04/26 15:58:20 [INFO] [wg-gen-web.example.eu] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4193569904
2020/04/26 15:58:20 [INFO] [wg-gen-web.example.eu] acme: Could not find solver for: tls-alpn-01
2020/04/26 15:58:20 [INFO] [wg-gen-web.example.eu] acme: use http-01 solver
2020/04/26 15:58:20 [INFO] [wg-gen-web.example.eu] acme: Trying to solve HTTP-01

Since the only difference between these hosts are the remote_ip filtering. I was really hoping that Caddy could answer to LE despite the hosts themselves being filtered. Is that possible?

The documentation is a bit mysterious about that point:

If the CA sees the expected resource, a certificate is issued.

I am not sure what “sees” exactly means, and if LE could be tricked to “see” it.

If there is an order for the matches to be parsed, then maybe sending to the proxy for LAN hosts, and sending back an empty page for 0.0.0.0/0 could be a solution?

(a little background: I am transitioning from Traefik to Caddy for one because Caddy configurations makes much more sense but also because this dual filtering on Traefik is apparently not possible. I was hoping for Caddy to retrieve certificates for all my hosts without having them exposed (but known by caddy))

And yes - it works! :slight_smile:

The following route under subroute does the job. It also means that the order of parsing matters (I initially had the 0.0.0.0/0 part first and always got a “Hello world” reply.

[
                {
                    "handle": [
                        {
                            "handler": "reverse_proxy",
                            "upstreams": [
                                {
                                    "dial": "localhost:8076"
                                }
                            ]
                        }
                    ],
                    "match": [
                        {
                            "remote_ip": {
                                "ranges": [
                                    "192.168.10.0/24",
                                    "192.168.20.0/24"
                                ]
                            }
                        }
                    ]
                },
                {
                    "handle": [
                        {
                            "body": "Hello, world!",
                            "handler": "static_response"
                        }
                    ],
                    "match": [
                        {
                            "remote_ip": {
                                "ranges": [
                                    "0.0.0.0/0"
                                ]
                            }
                        }
                    ]
                },

            ]

Great, glad you got it working!

Yes; since routes are executed in order, if the first route matches a superset of the second route and the first route is terminal, then the second route will never be executed since it will be handled by the first route.

1 Like

For the HTTP challenge, it means that the CA makes an HTTP request to your server and if your server returns the expected response, the CA will validate the request and issue you a cert.

Basically it means that an external client needs to be able to make a (certain) HTTP request to Caddy without obstruction.

1 Like

What does this mean, exactly? (that the routes can be nested, maybe? - I do not have an immediate use in mind, just wildly speculating)

1 Like

Terminal, meaning it terminates the handler chain; i.e. it responds to the request and/or does not call the next handler in the chain. (HTTP routes are ordered lists of handlers.)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.