Manual Wildcard Certs?

Help
1

Is it possible to manually generate wildcard certs or manually handle DNS confirmation to support a wildcard domain without doing a special compile of Caddy?

Is the special compile the only way to do Wildcard certs?

Thanks!

2

Yes, the only way to do it with Caddy is via DNS plugins. Allowing manual steps isn’t really sustainable.

3

I’ve made progress on setting up Caddy to work with Route53 for wildcard certs + the DNS challenge.

Question - Can caddy use the DNS challenge for the wildcard domain, in this case *.webase.com but still use the automatically HTTP challenges for other domains (like www.simplpages.com)??

Asking because the way the configuration looks I’m worried it will try to use DNS for all the domains but I only need that for the wildcard domains.

Thanks for any tips,

–harris

4

Yeah, just make separate site blocks for each, and set up tls dns config only for the wildcard one.

5

How should I connect the two? This is my best guess:

  "apps": {
    "tls": {
      "automation": {
        "policies": [
          {
          "subjects": ["*.example.com"],

… for the DNS policy … and connect to a route like this:

{
              "match": [{
                "host": ["*.example.com"]
              }],
              "handle": [{
                "handler": "reverse_proxy",
                "upstreams": [{
                  "dial": "ip-172-31-4-60.us-west-2.compute.internal:80"
                }]
              }],
              "terminal": true
            },

So the subject and the host values match. Is that what you mean?

Trying this… hopefully it will work!

Thanks,

–harris

6

Something like this (easier to write in Caddyfile first then adapt to JSON):

*.webase.com {
	tls {
		dns route53 <secret>
	}
	reverse_proxy whatever:80
}

www.simplepages.com {
	root * /path/to/site
	file_server
}
7

What will trigger Caddy to do the DNS challenge and generate the wildcard cert?

It feels like this should happen the first time the config loads instead of on-demand. But I am not ever seeing Caddy try to set up the ACME challenge DNS record.

I have everything set up just like the docs are saying but can’t pinpoint where why it is failing? (just getting an NO CERT error).

–harris

8

Please post your full config + logs (obviously omit your route53 secret), otherwise we’d just be postulating and that isn’t very productive.

9

I’ve made some progress at least getting data from the logs. Currently seeing this:

[*.webase.com] [*.webase.com] acme: error presenting token: NoCredentialProviders: no valid providers in chain. Deprecated.
        For verbose messaging see aws.Config.CredentialsChainVerboseErrors
 - retrying in 5m0s (5m26.933906965s/720h0m0s elapsed)...

After searching around for that I am attempting to update my /etc/environment file to include:

AWS_HOSTED_ZONE_ID and AWS_REGION in addition to the required AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

The latest challenge is I don’t know how to get Caddy to recognize updates to the /etc/environment file.

And unfortunately I haven’t found any working examples of how Caddy interacts with Route53.

I can post my caddy.json if that would help but this seems more related to how the Route53 integration works.

How do I get Caddy to see the latest Environment variables? (it can see the Key and Secret, but not the new variables).

–harris

10

You can instead use the --envfile option when running Caddy to provide a file which has key-value pairs of additional env vars for Caddy to load at runtime.

1 Like
11

And you can always double-check the environment that Caddy sees by running caddy environ or caddy run --environ.

12

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