Caddy v1 vs V2: adapt: server listening on [:80] is HTTP, but attempts to configure TLS connection policies

I’m currently running though the process of converting Caddyfile v1 to v2

This obvervation caused me some pain…

Could you clarify if the following error is expected when using a combination of http and https site addresses?

To me it seems wrong, I shouldn’t need to duplicate complex site configurations for both secure and non-secure right?


1. Caddy version (caddy version):

v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

2. How I run Caddy:

a. System environment:

Windows 10

b. Command:

caddy.exe adapt --config C:\projects\server1\etc\caddy\CaddyfileV2 --adapter caddyfile --pretty

d. My complete Caddyfile:

    example.com,
    http://www.example.com {
    
        tls support@example.com
        reverse_proxy http://example.net
    }

4. Error messages and/or full log output:

adapt: server listening on [:80] is HTTP, but attempts to configure TLS connection policies

5. What I already tried:

Tried using the global email, which outputs successfully (without error):

    {
        email support@example.net
    }
    example.com,
    http://www.example.com {
    
        reverse_proxy http://example.net
    }

But what about the case where I don’t want to define a global email for all sites in the Caddyfile?

Also is there really a problem with the following Caddyfile similar to the following?

(global_good_stuff) {
     tls support@example.com
     # some other defaults here, complex redirections, blocking bad actors etc.
}
example.com,
http://www.example.com {
    import global_good_stuff
    reverse_proxy http://example.net
}

http://subsite1.example.com {
    import global_good_stuff
}
http://subsite2.example.com {
    import global_good_stuff
}

This didn’t cause an error in Caddy V1.

Cheers!

There is no need for tls support@example.com on a HTTP-only site.

It is only used for the ACME account that will be used to requisition certificates for that site.

I’d assume it was just kept as some unused variable in a v1 config, but in v2, the Caddyfile is adapted to a JSON structure, and within that JSON structure the ACME account goes inside a TLS automation policy. When the TLS automation policy is configured, a TLS connection policy is also applied. Caddy v2 stops here, because you’re trying to apply HTTPS configuration to a HTTP-only site.

Consider the following:

~/Projects/test
➜ cat Caddyfile
example.com
tls email@example.com

~/Projects/test
➜ caddy2 adapt --pretty
2020/05/11 01:31:31.596	INFO	using adjacent Caddyfile
{
	"apps": {
		"http": {
			"servers": {
				"srv0": {
					"listen": [
						":443"
					],
					"routes": [
						{
							"match": [
								{
									"host": [
										"example.com"
									]
								}
							],
							"terminal": true
						}
					],
					"tls_connection_policies": [
						{
							"match": {
								"sni": [
									"example.com"
								]
							}
						},
						{}
					]
				}
			}
		},
		"tls": {
			"automation": {
				"policies": [
					{
						"subjects": [
							"example.com"
						],
						"issuer": {
							"email": "email@example.com",
							"module": "acme"
						}
					}
				]
			}
		}
	}
}

In short: don’t specify an ACME email address for a site that doesn’t need ACME.

2 Likes

:point_up: Seconding that.

The tls directive always enables TLS, which doesn’t make sense for an HTTP site.

1 Like

Thanks for your replies @Whitestrake and @matt

I guessed as much - but didn’t know if it was supposed to streamline setup in Caddy v1 and if that was meant to be passed over to Caddy v2.

Thanks though.

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