Obtaining on_demand certificate for ipv4 - and other questions

Help
1

1. Caddy version (caddy version):

v2.2.1 Digital Ocean Marketplace

2. How I run Caddy:

Json --config

a. System environment:

DO Ubuntu.

b. Command:

caddy start --config caddy.json --watch

d. My complete Caddyfile or JSON config:

{
  "logging": {
    "logs": {
      "default": {
      	"encoder": {
      		"format": "console"
      	},
        "level": "DEBUG"
      }
    }
  },
	"apps": {
		"http": {
			"servers": {
				"server0": {
					"listen": [":443"],
					"routes": [
						{
	                        "handle": [
	                            {
	                                "handler": "reverse_proxy",
                                    "headers": {
                                        }
                                    }
	                            }
	                        ]
						}
					]			
				}
			}
		}
	}
}

3. The problem I’m having:

I have just configured a reverse_proxy and its working. But after reading a lot and searching there are still some doubts as to how a couple of configuration works.

First:
I am seeing this messages in the log (DEBUG), the ip address is my DO droplet, why is caddy trying to obtain a certificate for my IP address?

1.6256797119846966e+09  info    tls.on_demand   obtaining new certificate       {"server_name": "157.230.3.207"}
1.625679711985022e+09   debug   http.stdlib     http: TLS handshake error from 125.64.94.136:47984: subject does not qualify for a Let's Encrypt certificate: 157.230.3.207
1.6256797876152875e+09  info    tls.on_demand   obtaining new certificate       {"server_name": "157.230.3.207"}
1.6256797876157186e+09  debug   http.stdlib     http: TLS handshake error from 222.77.181.28:46566: subject does not qualify for a Let's Encrypt certificate: 157.230.3.207
1.6256799332693126e+09  debug   http.stdlib     http: TLS handshake error from 222.77.181.28:14004: read tcp 157.230.3.207:443->222.77.181.28:14004: read: connection timed out

Third:
I noticed a matcher option on tls_connection_policies would this matcher prevent the request reaching my on_demand.ask configuration? In order to filter out IP addresses for example and avoid unnecessary load.

Well, after a few days reading and configuring thats about it that was left unanswered. Thanks!

1 Like
2

Are you sure that’s the version of Caddy you have? Run caddy version. The DO image should be using the apt repo for Caddy, so you should have the latest, v2.4.3.

You should never use on_demand without configuring any of the options. Otherwise, you’re at risk of of abuse. A bad actor could point a wildcard domain to your server then make requests like 1.example.com then 2.example.com and so on ad infinitum causing your server to constantly issue certificates. You should configure an ask endpoint to let your backend make the decision of whether a certificate should be issued, based on a whitelist you manage (e.g. customer registered domains in your database).

No, an empty connection policy is necessary as a fallback if you don’t otherwise have one. Connection policies control which certificates are selected, which ECC curves are allowed in the TLS handshake, the TLS protocol versions to support, etc. The defaults are good enough 99% of the time.

That’s the purpose of ask as I wrote above; to avoid performing cert issuance on domains that you don’t know (including IP addresses).

I’m a bit confused by the question, I think there’s two separate things going on here.

No, you can’t send any additional details to the ask endpoint. It’s the job of your backend to determine which account a domain belongs to, by using a database or whatever. Caddy just needs a yes or no answer to know whether it should continue with issuance, or give up fast.

If you need to send up the connecting hostname to your proxy backend, then you can pass it through with a header like "X-Forwarded-Host": "{http.request.host}".

1 Like
3

Hey Francis,

Yes, this is it:

root@caddy-ubuntu-s-1vcpu-1gb-nyc1-01:/home# caddy version
v2.2.1 h1:Q62GWHMtztnvyRU+KPOpw6fNfeCD3SkwH7SfT1Tgt2c=

Regarding ask and avoiding IPv4 asking for certificates. It is pretty clear and I will create an endpoint to authorize domains issuance. The ask configuration is empty because I am just testing.

4

That’s a pretty old version. Please upgrade! Plenty of important fixes and improvements since.

You can get that with the {http.request.host} placeholder

You’ll need to write a custom module for this, if you must do it in Caddy.

I’d recommend just shipping off the hostname to your backend and letting your backend associate the hostname back to the account.

5

Will try to do it both ways, I’m getting the hang of caddy and it is very useful.

Sure, I’m bringing the droplet down and configuring it with docker now, will do with the latest version.

Thanks for your insight Francis, very helpful!

1 Like
6

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