V2: Catch all server with automatic TLS?

1. My Caddy version (caddy -version):

v2.0.0-beta11

2. How I run Caddy:

{
"apps": {
    "tls": {
        "automation": {
            "policies": [{
                "management": {
                    "module": "acme",
                    "ca": "https://acme-staging-v02.api.letsencrypt.org/directory",
                    "on_demand": true
                }
            }],
            "on_demand": {
                "rate_limit": {
                    "interval": "10m",
                    "burst": 2
                }
            } 
        }  
    },
    "http": {
        "servers": {
            "myserver": {
                "listen": [":443"],
                "routes": [
                    {
                        "handle": [
                            {                           
                            "handler": "file_server",
                            "root": "/home/www"
                            }
                        ]
                    }
                ]
            }
        }
    }
}
}

a. System environment:

Linux (x86 64)

3. The problem I’m having:

I am trying to create a V2 config which will automatically setup TLS when a newly setup host is accessed after DNS setup.

The equivalent in V1 works fine:

http://, https:// {
  root  /home/www
  browse
  tls {
    max_certs 10
  }
}

So I am really looking for a V2 equivalent of the above config.

4. Error messages and/or full log output:

I have pointed a couple of sites to the server: s1.example1.com, s2.example2.com but I receive no response with the above V2 config. It works file with the V1 config.

For V2, it works if I add the following in routes:

        "match": [{"host": [
                    "s1.example1.com",
                    "s2.example2.com"
        ]}]

So unless I add the specific hosts, the automatic TLS setup does not work.

5. What I already tried:

  • Use adapt on the V1 working config but get an error:
    adapt: parsing caddyfile tokens for 'root': Caddyfile:2 - Error during parsing: Wrong argument count or unexpected line ending after '/home/www'
  • Instead of rate limiting, used “ask” but the target server does not receive any request for confirming TLS setup.

I am new to Caddy and would appreciate any guidance on this.

For now, you need to enable TLS on your server by specifying at least one TLS connection policy:

"tls_connection_policies": [{}]

I am thinking of making this the default when the server’s only listener is the HTTPS port, so that it’s not necessary to specify a TLS conn policy. What do you think?

Yes- making this the default would be nice and make configuration more obvious.

Thanks for your reply and all the work on Caddy - Automatic TLS is truly magical!

Automatic TLS is what pulled me in - but I am now liking other features like templates too.

1 Like

Good idea, done. Thanks. That improvement will go out with beta 12.

Tangentially: In the future, I’m hoping we’ll be able to enable HTTPS by default for all servers, regardless of their ports (except port 80) or domain names – but this’ll require a good way to manage certificates for non-public hostnames, and to know when the hostnames aren’t public.

Edit: Here’s the commit: http: Enable TLS for servers listening only on HTTPS port · caddyserver/caddy@2b33d9a · GitHub

Awesome!

Looks like for such catchall configs, the logs entry is also needed for http access logs:

            "tls_connection_policies": [{}],
            "logs": {}

Like for “tls_connection_policies”, it would be nice to make this also not required.

Imo for public hostnames it’s already close to perfect.
Extending it to private hostnames - could be good but has the potential to add a lot of complexity. It would be useful for mostly enterprise folks - but most of them like to run their own CA for such internal certificates and like to control this tightly. Could be worth fleshing this out with some motivated potential users.

Determining internal hostnames is tricky but one proxy is to use the Google DNS API to check if a newly encountered hostname has some public record.

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